Everything you need is a web browser

A web browser is a universal tool allowing to navigate the World Wide Web. The “universality” of that tool is somewhat “regulated”, among others, by the World Wide Web Consortium via publication of standards and best practices. From time to time there could be certain features supported by one web browser, but missing is some others.

W3Schools.com publishes web browser usage statistics based on their monthly visits. According to that source, the most popular browser for 2017 was Chrome, which was steadily increasing its share from 73,7% in January till 77% in December. These numbers may differ depending on the source one looks at. While Chrome still holds the leadership, W3Counter.com shows 58,8% for it in December of 2017.  It could be speculated here that W3Schools.com that holds many great tutorials on web standards and technologies is visited primarily by people interested in those, e.g. (beginning) web developers, who may particularly value Chrome versus other browsers.

The Chrome web browser (like also some others) gives a possibility to add extensions, tools or apps to the web browser. One of those, for example, is Advanced REST Client (ARC) app. Thanks to the standardized interfaces (standard protocols), using the ARC one could generate a request to check, for instance, a temperature in a particular place of the world using, for example, the API provided by openweathermap.org.

The very same app can be used to interface industrial equipment. For example, the simulator of the oil lubrication system located is here. (Actual systems are usually put to the protected, private networks that are not accessible on the global network). In order to check a value of the flow meter device one could following the instructions make the request:

The extensions of a web browser can give the end user a powerful tools framework to develop applications. In some cases, one even does not need to preinstall any so-called development tools or IDE on his/her PC, as these can be provided to the end user also through the web browser. For example, the Cloud9 IDE that can run on Raspberry PI device makes it possible to develop and run programs via a web browser. For the industrial controllers, one example, where the development environment is integrated into the same device, is S1000 device by Inico Technologies Ltd. Taking such devices out of box, powering them up, and connecting the Ethernet cable… could be only basic steps needed to start developing an application for those.

After all, having a web browser, you may start checking available services building your web application using a set of tools and apps delivered to you via or integrated with the web browser. Although one should always take precautions about authentification and security ensuring that mission-critical application, in particular, controller devices integrated and affecting the physical world, will not become vulnerable if and as these get exposed to the global network.

However, independently if one builds her/his application on the global or local/private network still the very same tools are available to the developer.  Thus the overall costs could drop for maintaining applications in your domain. Also, the ability to find the right expertise increases.  At the end, everything you may need is a web browser that already has all the right tools to build your next application.

Five schools of thought to build knowledge-driven systems?

Professor Pedro Domingos in his book entitled “The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World” addressed a question how to build the master algorithm by combining different schools of thought for machine learning. According to Domingos, the quest starts with a combination of best practices developed by Symbolists, Connectionists, Evolutionaries,  Bayesians and Analogizers. The book provides insights into methods for each school of thought, their development history and relationships between the schools.

From W3C-KiSS community group perspective, understanding of those schools and how these can complement each other can be an important mission to build knowledge-driven systems.

In fact, the knowledge itself can be seen having various representation languages if one takes different viewpoint based on the school of thought. The figure below suggests a refined view on the five – symbolists, connectionists, statisticians, evolutionaries and interactionists.

As one builds the knowledge-driven system, the knowledge can be expressed using Web Ontology Language (OWL), which can be attributed to the symbolists. In general, each concrete node in the RDF graph is a concept that may be linked to other concepts-nodes on the graph. The reasoning for such structures can be seen just as a manipulation of symbols to derive new possible combination, which may not be stated explicitly in the beginning. This new combination can be seen a new knowledge we have got after the manipulation of symbols. Though, it is also important that the combination would have also some practical meaning from the application viewpoint.

Connectionists see a concept manifesting itself not as a particular node in a graph, but rather as a collection of engaged nodes or simultaneously activated connections between the nodes. As for the analogy, neural networks can be mentioned. However, also connectionistic grid approach was developed and demonstrated with a control application for a production line. In those cases, a concept can be seen as a simultaneous activation of the nodes that can make one to speak about active patterns. The reasoning process can be seen as a sequence of changing patterns that can sometimes arrive to the “new” knowledge, e.g. a new pattern for which the system would develop (train) new useful behaviour.

Knowledge of statisticians in comparison to symbolists (symbols/nodes) and connectionists (connections/patterns) can be seen in populations. Yet another word, but it highlights some important differences, as concepts for statisticians can be seen emerging as a result of processing all (or large amount) of nodes for the population and the properties attributed to the individuals. The relationship between the properties can be derived depending on how many nodes in the population share same properties (at the same time).

One of the aims that in our context can be attributed to evolutionaries is to allow systems adapting dynamically, at run time to the changes in the environment. Learning from the nature, the vocabulary of evolutionaries may include such things as “chromosomes” to represent their knowledge. The nature gave us the method what to do with such representation. For example, a chromosome could be a production schedule – a list of workstations a product must visit at the production line to get assembled.   Crossing over between a number of chromosomes / solutions can bring us to an optimal schedule. Mutations can increase our chances to find actual optimum rather than staying in some local optimum.

Interactions between the nodes, the particular patters for the interactions could be seen as one of the main focuses for the interactionists. The knowledge of a system in this case could be embedded, for example, into Multi Agent System (MAS), where an agent can be seen as autonomous entity capable of complex interaction behaviour. The MAS can be solving dynamically problems occurring, for instance, at the production line having to decide the flow of a workpiece in the production system.

As can be seen, each school of thought, or approaches to build knowledge-driven systems may propose own vocabulary, languages, tools and methods to build corresponding solutions. An open question could be, if the World Wide Web Consortium can be one of the prominent actors for providing the languages (standards) to support all the approaches and to help developing knowledge-driven systems managing different vocabularies?

Climbing the DIKW pyramid – do we have everything we need?

The ‘divide and conquer’ principle or the ‘separation of concerns’ design principle have served well engineers for many centuries. A system viewed as a collection of interconnected modules (sub-systems) each assigned a dedicated function is a good way to focus on each issue in its turn, to solve different problems one after another.

Service-oriented Architecture, a simple triangle, that can be imagined in general to be composed of 3 vertices: i) service provider, ii) service requester and iii) register, give a possibility to build complex and scalable systems, where service requesters with the help from known and (hopefully) trusted registers can discover and engage with the service providers.

Building loosely-coupled systems, where the links between service requestors and providers dynamically change as the overall goal or goals the entire system follows change as well, make it possible for system, in general, to provide a better service as, for example, to cope with some unforeseen conditions at system design time. In order words, a system can do things, which its creators were not foreseeing the system should or could be doing.

Another viewpoint on systems we develop could be through DIKW (Data / Information / Knowledge / Wisdom) pyramid. Such viewpoint could help us to go from abstract services that can be dynamically invoked to serve some abstract changing needs of abstract system to arrive to the point, where we can formulate the goals and purpose for those actual systems.

At the bottom of the DIKW pyramid, one can imagine data or sensor readings. As such, those without context provide little value. For example, a temperature of 233 °C may tell us a little. However, as we start to develop a context or information, linking the temperature with the material exposed to that temperature, we can start to “see” that at given temperature paper catches the fire. However, in a different “context” of Aluminium, you will need to rise the temperature about 3 times more, for the metal to start melt.

Still, we usually try to climb that pyramid to make something useful, which could be interaction with the environment. So, for example, we may wish that, for example, a furnace we made to melt metals would maintain the right temperature to melt given metal. We could make an application that will use information about the melting temperatures and will keep right levels at operation time. The operational knowledge can be hardcoded in the application.

However, if we wish to build truly intelligent systems, we may want to push the limits and make those rules also to change dynamically. Not that we will be able to change some “constants” for metals, but to at least allow systems to learn how to treat yet unseen situations and update its experience. For that purpose, we may need to learn how to represent Wisdom from the above-mentioned pyramid.

Are available knowledge representation standards all that we need to build systems having “Wisdom” or we miss some languages and standards to grasp essentials of learning process, to express the emergence of intelligence?

A device to support Industrial IoT applications

With this post, we would like to open a tradition of regular postings at our community group web-site to tell about different developments and products that could support the mission of the group for building knowledge-driven service oriented systems. Such posts should appear regularly. You can also propose topics for future posts for the group by using the feedback form (https://www.w3.org/community/kiss/feedback/) and/or #W3C_KiSS hashtag on the Twitter.

We would like to start by the following subject.

Monarco HAT: A device to support Industrial IoT applications

The Manarco HAT device has been developed and is sold worldwide by REX Controls, a company from the Czech Republic. The REX Controls main business applications are based on the REX software system and focus on advanced real-time control systems of various processes, machines, test stands, prototypes and physical models for education.

Structure of the Monarco HAT

One of the particularity of the device is its ability to support REST interface for web services. Milos Schlegel, the CEO of REX Controls, told us on the implementation of REST interface in their solution the following: “REST web interface and RESTful web services are logical choices for building web applications. It makes it possible to interconnect together very heterogeneous software tools and they have big potential for IIoT and Industry 4.0”.

Following of web standards increase chances for solutions to reduce maintenance costs and to find the right expertise as there are many users and tools already built to work within an ecosystem created by web standards.

Check the links below for more details on Monarco HAT:

• Lightweight I/O for the Raspberry Pi minicomputer, 
  http://www.monarco.io/
• Monarco HAT: Industrial interface for Raspberry Pi,
  https://www.indiegogo.com/projects/monarco-hat-industrial-interface-for-raspberry-pi–2#/

Also you can check the following video:

• https://youtu.be/A1VEbMzM1Pg