Skip to toolbar

Community & Business Groups

Open knowledge-driven service-oriented system architectures and APIs (KiSS) Community Group

W3C provide a great variety of standards that can be used to build applications that use the Internet as a platform for communication and integration. The open Knowledge-driven Service-oriented System architectures and APIs (KiSS) community group is created for sharing, elaborating and evolving knowledge-driven approaches for system integration. The KiSS community group takes service-oriented architecture as a main paradigm for application creation. However, it is not enough to say that there is a set of some services that can be integrated according to the application needs. The integration is facilitated with semantic descriptions of the services. Furthermore, the special support components are required at system run time in order to allow dynamic composition of the services accordingly semantic representation of adjusted or new system goals. Thus, the community aims to categorise different possible architectures to allow knowledge-driven approach for system integration; it provides reference architectures that also point out possible technologies for the solution implementation. The community targets different application domains and industries in order to benefit from cross-domain vision on development of knowledge-driven systems. The abbreviation of the community group highlights the integrative nature of the group (small i among K (knowledge), S (service) and S (system)). The group is managed by 6 re-electable chairs. The roles and responsibilities of the chairs go as follows:
  • General chair: Ideologist. Overall synchronization between different pillars of the KiSS. PR with other groups and external stakeholders. Member attraction, community group development.
  • Chair for integration: Integration technologies, web service composition.
  • Chair for knowledge: Knowledge representation and reasoning standards and methodologies.
  • Chair for devices: Embedded devices, their adoption for KiSS.
  • Chair for services: Web services, standards, methodologies for service definition.
  • Chair for application domains: KiSS in different application domains. Cross-domain learning and development. Benchmarking.

Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.

drafts / licensing info

name
Recipes for building service-oriented knowledge-driven systems

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

Publish Reports

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 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.

SOA triangle

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.

DIKW pyramid

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:

Also you can check the following video:

Starting to work on the recipes for service-oriented knowledge-driven systems

The community group has defined first targets. Among them is developing the recipe(s) – a document outlining how to build service-oriented knowledge-driven system. In the first iteration we investigate what standards, platforms and APIs are already available. The problem is addressed from different levels, e.g. from embedded devices till service composition.

The group aims to have the first draft by the end of April 2016.

You are welcome to join the group if you are not yet the member!

(Note for the group members: Next group meeting of the participants is scheduled for Wed. 27.04.2016. Please check communications on the internal mailing list.)

Call for Participation in Open knowledge-driven service-oriented system architectures and APIs (KiSS) Community Group

The Open knowledge-driven service-oriented system architectures and APIs (KiSS) Community Group has been launched:


W3C provide a great variety of standards that can be used to build applications that use the Internet as a platform for communication and integration. The open Knowledge-driven Service-oriented System architectures and APIs (KiSS) community group is created for sharing, elaborating and evolving knowledge-driven approaches for system integration. The KiSS community group takes service-oriented architecture as a main paradigm for application creation. However, it is not enough to say that there is a set of some services that can be integrated according to the application needs. The integration is facilitated with semantic descriptions of the services. Furthermore, the special support components are required at system run time in order to allow dynamic composition of the services accordingly semantic representation of adjusted or new system goals.

Thus, the community aims to categorise different possible architectures to allow knowledge-driven approach for system integration; it provides reference architectures that also point out possible technologies for the solution implementation. The community targets different application domains and industries in order to benefit from cross-domain vision on development of knowledge-driven systems.

The abbreviation of the community group highlights the integrative nature of the group (small i among K (knowledge), S (service) and S (system)).

The group is managed by 6 re-electable chairs. The roles and responsibilities of the chairs go as follows:
* General chair: Ideologist. Overall synchronization between different pillars of the KiSS. PR with other groups and external stakeholders. Member attraction, community group development.
* Chair for integration: Integration technologies, web service composition.
* Chair for knowledge: Knowledge representation and reasoning standards and methodologies.
* Chair for devices: Embedded devices, their adoption for KiSS.
* Chair for services: Web services, standards, methodologies for service definition.
* Chair for application domains: KiSS in different application domains. Cross-domain learning and development. Benchmarking.


In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. This group was originally proposed on 2015-11-17 by Andrei Lobov. The following people supported its creation: Andrei Lobov, Wael Mohammed, Sergii Iarovyi, Borja Ramis Ferrer, Michael Petychakis. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group in social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at site-comments@w3.org

Thank you,
W3C Community Development Team