Semantic Web and Linked Data. Corrections and additions

I would like to present to the public an excerpt from this recently published book:

Ontological Modeling of Enterprises: Methods and Technologies [Text]: Monograph / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak, et al.; responsible editor S. V. Gorshkov]. — Yekaterinburg: Ural University Publishing House, 2019. — 234 p.: ill., tables; 20 cm. — Authors are listed on the reverse of the title page. — Bibliography at the end of the chapters. — ISBN 978-5-7996-2580-1: 200 copies.

The purpose of sharing this excerpt on Habr is fourfold:

• It is unlikely that anyone will get a chance to hold this book in their hands unless they are a client of the esteemed SergeIndex; it is certainly not available for sale.
• Corrections have been made to the text (they are not highlighted here), and additions have been made that are not entirely compatible with the format of a printed monograph: relevant notes (under spoilers) and hyperlinks.
• I would like to gather questions and comments, to consider them when including this text in a revised form in any other publications.
• Many proponents of Semantic Web and Linked Data still believe that their circle is so narrow mainly because the broader public has not been properly explained how great it is to be a proponent of Semantic Web and Linked Data. The author of this excerpt, while belonging to this circle, does not hold such an opinion. Nevertheless, they feel obliged to make one more attempt.

So,

Semantic Web

The evolution of the Internet can be represented as follows (or speaking of its segments formed in the order indicated below):

1. Documents on the internet. Key technologies — Gopher, FTP, etc.
   The Internet is a global network for exchanging local resources.
2. Internet documents. Key technologies — HTML and HTTP.
   The nature of the exhibited resources takes into account the peculiarities of their transmission environment.
3. Data on the internet. Key technologies — REST and SOAP APIs, XHR, etc.
   The era of internet applications, where not only people become consumers of resources.
4. Internet data. Key technologies — Linked Data technologies.
   This fourth stage, predicted by Berners-Lee, the creator of key technologies of the second stage and director of W3C, is called the Semantic Web; Linked Data technologies are designed to make data on the web not only machine-readable but also 'machine-understandable'.

From the following, the reader will understand the correspondence of the key concepts of the second and fourth stages:

• analogous to URLs are URIs,
• analogous to HTML is RDF,
• HTML hyperlinks are similar to the occurrences of URIs in RDF documents.

The Semantic Web is more of a systemic vision of the future internet than a specific spontaneous or lobby-driven trend, although it can also account for these recent ones. For example, an important characteristic of what is called Web 2.0 is 'user-generated content.' This is intended to be taken into account, in particular, by the W3C recommendation ‘Web Annotation Ontology’ and such an initiative as Solid.

Is the Semantic Web dead?

If we set aside unrealistic expectations,, the situation with the Semantic Web is roughly the same as with communism during the times of mature socialism (and whether the fidelity to the conditional testament of Ilyich will be maintained, everyone can decide for themselves). Search engines fairly successfully force websites to use RDFa and JSON-LD, and themselves use technologies related to those described later (Google Knowledge Graph, Bing Knowledge Graph).

In general terms, the author cannot say what hinders wider adoption, but can express an opinion based on personal experience. The tasks that would be solved 'out of the box' in the context of the arrival of the SW do exist, although they are not very widespread. Consequently, those facing these challenges have no means of coercing those capable of providing a solution, and the independent provision of solutions by the latter contradicts their business models. So we continue to parse HTML and glue together various APIs, each shittier than the last.

However, Linked Data technologies have gained traction beyond the mass web; this book is dedicated to those applications. Currently, the Linked Data community expects that these technologies will see even greater proliferation due to the affirmation (or proclamation, as one prefers) by Gartner of trends such as Knowledge Graphs and Data Fabric. One hopes that it will be the implementations of these concepts that are not 'bicycle' solutions, but rather ones pertaining to the W3C standards discussed below.

Linked Data

Berners-Lee defined Linked Data as a 'well-formed' Semantic Web: a set of approaches and technologies that allow achieving its ultimate goals. The basic principles of Linked Data outlined by Berners-Lee are the following.

Principle 1. Using URI to name entities.

URIs are global identifiers of entities as opposed to local string identifiers of records. This principle is best expressed in the slogan of the Google Knowledge Graph “things, not strings».

Principle 2. Using URI in the HTTP schema so that they can be dereferenced.

By referring to a URI, it should be possible to obtain the meaning behind that signifier (here it's clear to draw an analogy with the name of the operator “*” in C); more precisely, to obtain some representation of that meaning — depending on the value of the HTTP header Accept:. Perhaps with the advent of the AR/VR era it will be possible to obtain the resource itself, but for now, it will likely be an RDF document, resulting from a SPARQL query execution. DESCRIBE.

Principle 3. Using W3C standards — primarily RDF(S) and SPARQL — especially when dereferencing URIs.

These separate “layers” of the Linked Data technology stack, also known as Semantic Web Layer Cake, will be described by us later.

Principle 4. Using links to other URIs when describing entities.

RDF allows for a verbal description of a resource in natural language, and the fourth principle urges not to do so. With the universal compliance with the first principle, it becomes possible to refer to other resources, including 'foreign' ones, when describing a resource, which is why data is called linked. In fact, the use of URIs as defined in the RDFS vocabulary is almost inevitable.

RDF

RDF (Resource Description Framework) — a formalism for describing interconnected entities.

Statements about entities and their relationships are made in the form of 'subject-predicate-object', called triples. In the simplest case, the subject, predicate, and object are all URIs. The same URI can occupy different positions in various triples: it can be both a subject, a predicate, and an object; thus, the triples form a sort of graph known as an RDF graph.

Subjects and objects can be not only URIs but also so-called blank nodes, and objects can also be literals. Literals are instances of primitive types, consisting of a string representation and a type specification.

Examples of literal records (in Turtle syntax, which will be discussed below): "5.0"^^xsd:float and "five"^^xsd:string. Literals of type rdf:langString can also be supplied with a language tag, in Turtle this is written as: "five"@en and "пять"@ru.

Empty nodes—'anonymous' resources without global identifiers, about which assertions can still be made; a kind of existential variables.

So (this is, in fact, the essence of RDF):

• the subject is a URI or an empty node,
• the predicate is a URI,
• the object is a URI, an empty node, or a literal.

Why can't predicates be empty nodes?

The likely reason is the desire to informally understand and translate into first-order predicate logic language the triplet s p o as something like , where — predicate, and — constants. Traces of this understanding can be found in the document "LBase: Semantics for Languages of the Semantic Web", which has the status of a W3C working group note. Under this understanding, the triplet s p [], where [] — empty node, will be translated as , where — variable, but how then to translate s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semantics" offers another way of translation, but the possibility of predicates being empty nodes is still not considered.

However, Manu Sporny allowed.

RDF is an abstract model. RDF can be written (serialized) in various syntaxes: RDF/XML, Turtle (the most human-readable), JSON-LD, HDT (binary).

The same RDF can be serialized in RDF/XML in various ways, therefore, for example, the resulting XML is meaningless to validate using XSD or to attempt to extract data using XPath. Similarly, JSON-LD is unlikely to satisfy the average Javascript developer's desire to work with RDF using dot and square bracket notation in Javascript (although JSON-LD is moving in this direction, providing a framing mechanism. framing).

Most syntaxes offer ways to shorten long URIs. For example, declaring @prefix rdf: in Turtle will then allow writing instead of <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> simply rdf:type.

RDFS

RDFS (RDF Schema) is a basic modeling vocabulary that introduces the concepts of property and class, and such properties as rdf:type, rdfs:subClassOf, rdfs:domain and rdfs:range. Using the RDFS vocabulary, the following valid statements can be recorded, for example:

rdf:type         rdf:type         rdf:Property .
rdf:Property     rdf:type         rdfs:Class .
rdfs:Class       rdfs:subClassOf  rdfs:Resource .
rdfs:subClassOf  rdfs:domain      rdfs:Class .
rdfs:domain      rdfs:domain      rdf:Property .
rdfs:domain      rdfs:range       rdfs:Class .
rdfs:label       rdfs:range       rdfs:Literal .

RDFS is a vocabulary for description and modeling but is not a constraint language (although the official specification leaves the possibility of such usage). The term "Schema" should not be understood in the same sense as in the expression "XML Schema". For example, :author rdfs:range foaf:Person of all values of the property means that rdf:type :author foaf:Person — , but this does not mean that it must be stated in advance.(SPARQL Protocol and RDF Query Language) is a query language for RDF data. In a simple case, a SPARQL query consists of a set of patterns that are matched against the triples of the queried graph. In the patterns, variables can occupy the positions of subjects, predicates, and objects.

SPARQL

SPARQL The query will return such variable values that, when substituted into the patterns, can yield a subgraph of the queried RDF graph (a subset of its triples). Variables with the same name in different triple patterns must have the same values.

For example, with the above set of seven RDFS axioms, the following query will return

as values rdfs:domain and rdfs:range respectively: ?s and ?p SELECT * WHERE { ?s ?p rdfs:Class . ?p ?p rdf:Property . }

It is worth noting that SPARQL is declarative and is not a graph traversal language (although some RDF stores offer ways to optimize the query execution plan). Therefore, some standard graph tasks, such as finding the shortest path, cannot be solved in SPARQL, including through the use of the

property paths (but again, some RDF stores offer special extensions to solve these tasks). SPARQL does not assume an open-world assumption and follows the "negation as failure" approach; thus, it

allows such constructs as FILTER NOT EXISTS {…} . The distribution of data is taken into account through the mechanism offederated queries federal requests.

A SPARQL endpoint — an RDF store capable of processing SPARQL queries — has no direct analogs from the second stage (see the start of this paragraph). It can be likened to a database, on the contents of which HTML pages were generated, but accessible externally. The SPARQL endpoint is more akin to an API endpoint from the third stage, but with two main differences. First, it allows combining several 'atomic' requests into one (which is considered a key feature of GraphQL); second, such an API is fully self-documenting (which is what HATEOAS tried to achieve).

A polemical remark

RDF is a way of publishing data on the web, so RDF stores should be considered document-oriented DBMSs. However, since RDF is a graph and not a tree, they also turned out to be graph-oriented. It's surprisingly that they came to be at all. Who would have thought that there would be smart people who would implement blank nodes? Codd certainly didn't. it didn't work out.

There are also less fully functional ways of organizing access to RDF data, for example, Linked Data Fragments (LDF) and Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) is a formalism for knowledge representation, a syntactical variant of description logic (henceforth, it is more accurate to refer to OWL 2, as the first version of OWL was based on ).

Concepts of description logics in OWL correspond to classes, roles correspond to properties, and individuals retain their original name. Axioms are also called axioms.

For example, in the so-called Manchester syntax for writing OWL, the axiom we are already familiar with will be written as:

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

There are also other syntaxes for writing OWL, for instance, functional syntax, used in the official specification, and OWL/XML.Moreover, OWL can be serialized in the abstract syntax of RDF and subsequently — in any of the concrete syntaxes.

OWL in relation to RDF has a dual nature. On one hand, it can be considered as a kind of dictionary that extends RDFS. On the other hand, it is a more powerful formalism, for which RDF is only a serialization format. Not all elementary OWL constructs can be expressed using a single RDF triple.

Depending on what subset of OWL constructs is allowed, we speak of the so-called OWL profilesStandardized and most well-known are OWL EL, OWL RL, and OWL QL. The choice of profile affects the computational complexity of typical tasks. The complete set of OWL constructs corresponds to OWL DL. Sometimes OWL Full is also mentioned, where OWL constructs are allowed to be used with the full freedom inherent to RDF, without semantic and computational restrictions. For example, something can be both a class and a property. OWL Full is undecidable.

The key principles of inference in OWL are the acceptance of the open world assumption (open world assumption, OWA) and the rejection of the unique name assumption (unique name assumption, UNA). Below we will see what these principles can lead to, and we will get acquainted with some OWL constructs.

Let the ontology contain the following fragment (in Manchester syntax):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human
   Facts: hasChild Alice, hasChild Bob, hasChild Carol

Will it follow from the above that John is a parent of many children? The rejection of UNA will cause the inference engine to answer this question negatively, since Alice and Bob could very well be the same person. For the inference to hold, it will be necessary to add such an axiom:

DifferentIndividuals: Alice, Bob, Carol, John

Now let the fragment of the ontology have the following form (John declared as a parent of many children, but only two children are specified):

Class: manyChildren
   EquivalentTo: Human that hasChild min 3
Individual: John
   Types: Human, manyChildren
   Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, John

Will this ontology be contradictory (which can be interpreted as evidence of data invalidity)? Acceptance of OWA will lead the inference engine to answer negatively: "somewhere" else (in another ontology) it could very well be stated that Carol is also a child of John.

To exclude this possibility, let’s add a new fact about John:

Individual: John
   Facts: hasChild Alice, hasChild Bob, not hasChild Carol

To exclude the possibility of other children appearing, let’s state that all values of the property "hasChild" are people, of which we have only four:

ObjectProperty: hasChild
   Domain: Human
   Characteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }

Now the ontology will become contradictory, which the inference engine will not hesitate to report. With the last of the axioms, we have in a sense "closed" the world, and note how the possibility that John is a child to himself has been excluded.

Linking Enterprise Data

The set of approaches and technologies of Linked Data was initially intended for publishing data on the web. Their use in a corporate environment faces a number of challenges.

For example, in a closed corporate environment, the deductive power of OWL, which is based on the acceptance of OWA and the rejection of UNA — decisions influenced by the open and distributed nature of the web — turns out to be too weak. Here, the following solutions are possible.

• Endowing OWL with semantics implies rejecting OWA and accepting UNA, and implementing a corresponding inference engine. — This is one possible path to take. It leads to the RDF storage Stardog.
• Rejecting the deductive capabilities of OWL in favor of rule engines. — Stardog supports SWRL; Jena and GraphDB offer their own rule languages.
• Rejecting the deductive capabilities of OWL and using it to model a specific subset close to RDFS. — More on this later.

Another issue is the greater attention that can be paid to data quality problems in the corporate world, and the lack of validation tools in the Linked Data stack. The following solutions are available.

• Again, using OWL constructs with closed world semantics and unique name assumption for validation if there is a corresponding inference engine.
• Using SHACL, standardized after the Semantic Web Layer Cake was established (however, it can also serve as a rule engine), or ShEx.
• Realizing that everything ultimately relies on SPARQL queries, creating a simple custom data validation mechanism using them.

However, even a complete rejection of deductive capabilities and validation tools leaves the Linked Data stack unrivaled in tasks landscape-wise similar to those of the open and distributed web — in data integration tasks.

What about a typical corporate information system?

This is possible, but one should of course realize which specific problems the corresponding technologies will need to solve. Here I will describe a typical response from development participants to illustrate what this technological stack looks like from the perspective of conventional IT. It somewhat resembles the parable of the elephant:

• Business analyst: RDF is something like a directly stored logical model.
• System analyst: RDF is like EAV, but with a bunch of indexes and a user-friendly query language.
• Developer: well, it's all in the spirit of rich model and low code concepts, I read about it recently.
• Project Manager: isn't it collapsing the stack!

Practice shows that the stack is most often used in tasks related to the distribution and heterogeneity of data, for instance, in building MDM (Master Data Management) or DWH (Data Warehouse) systems. Such tasks exist in any industry.

As for applications with industry specificity, Linked Data technologies are currently most popular in the following sectors.

• biomedical technologies (where their popularity seems to be connected to the complexity of the subject area);

current

Recently, a conference titled "Ontology Integration: From Theory to Practical Application" organized by the National Medical Knowledge Base Association was held at the 'Point of Boiling'.».

• manufacturing and operation of complex products (large machinery, oil and gas extraction; it often concerns the standard ISO 15926);

current

Here, too, the complexity of the subject area is the reason, when, for instance, in the upstream stage, if we talk about the oil and gas industry, a simple accounting system needs to have some CAD functions.

In 2008, a representative setup conference organized by Chevron took place. conference.

ISO 15926 ultimately seemed a bit too heavy for the oil and gas industry (and found application mainly in machinery). Only Statoil (Equinor) seriously engaged with it, creating a whole ecosystem. Others are trying to do something of their own. For instance, it is rumored that the domestic Ministry of Energy intends to create a 'conceptual ontological model of the fuel and energy complex', similar to that apparently created for the electricity sector..

• financial organizations (even XBRL can be considered a kind of hybrid of SDMX and RDF Data Cube ontology);

current

LinkedIn actively spammed the author with job offers from almost all the giants of the financial industry known from the series 'Suits': Goldman Sachs, JPMorgan Chase and/or Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, the Federal Reserve, Deutsche Bank... They were probably all looking for someone to send to the Knowledge Graph Conference. Many were able to find someone: financial organizations filled the morning of the first day..

On HeadHunter, something interesting was found only at Sberbank, where it was about an "EAV storage with an RDF-like data model."

Probably, the difference in the level of affection towards relevant technologies between domestic and Western financial institutions is due to the transnational nature of the latter's activities. Apparently, integrations across national borders require fundamentally different organizational and technical solutions.

• question-and-answer systems with commercial applications (IBM Watson, Apple Siri, Google Knowledge Graph);

current

By the way, the creator of Siri, Thomas Gruber, is the author of that very definition of ontology (in the IT sense) as "specification of conceptualization." In my opinion, the rearrangement of words in this definition does not change its meaning, which possibly indicates that it is, in fact, meaningless.

• publication of structured data (this can be justifiably attributed to Linked Open Data).

current

Big enthusiasts of Linked Data are the so-called GLAM: Galleries, Libraries, Archives, and Museums. It is sufficient to say that in place of MARC21, the Library of Congress is promoting BIBFRAME, which provides a foundation for the future of bibliographic description and, of course, is based on RDF.

Often, Wikidata is cited as an example of a successful project in the area of Linked Open Data — a kind of machine-readable version of Wikipedia, the content of which, unlike DBPedia, is not generated by importing from article infoboxes, but is created more or less manually (and subsequently becomes a source of information for the same infoboxes).

We also recommend checking out list Stardog RDF repository users on the Stardog website in the "Customers" section.

Nevertheless, in Gartner's "Hype Cycle for Emerging Technologies" of 2016 "Enterprise Taxonomy and Ontology Management" is placed in the middle of the descent into the trough of disillusionment with the prospect of reaching the "productivity plateau" not earlier than in 10 years.

Connecting Enterprise Data

Predictions, predictions, predictions…

Out of historical interest, I compiled the table below of Gartner's forecasts from various years regarding the technologies of interest to us.

However, already in "Hype Cycle…" of 2018 A new emerging trend has appeared — Knowledge Graphs. There has been a sort of reincarnation: graph databases, which have gained the attention of users and the efforts of developers, are starting to take shape and position themselves like their predecessor competitors under the influence of the former's queries and the latter's habits.

Virtually every graph database now claims to be a suitable platform for building a corporate 'knowledge graph' (with 'linked data' sometimes replaced by 'connected data'), but how justified are these claims?

Graph databases remain semantically void; the data within a graph database represents the same old data silo. String identifiers instead of URIs make the task of integrating two graph databases the same integration challenge, while the integration of two RDF stores often simply comes down to merging two RDF graphs. Another aspect of the semantic void is the non-reflexivity of the LPG graph model, making metadata management using the same platform difficult.

Finally, graph databases lack inference engines and rule engines. The results produced by such engines can be replicated by complicating queries, but that is also possible in SQL.

However, leading RDF stores face no difficulties in supporting the LPG model. The most robust approach is considered to be the one proposed in Blazegraph: the RDF* model that combines RDF and LPG.

Learn more

More about RDF stores supporting the LPG model can be read in the previous article on Habr: ‘What is happening with RDF stores right now’. A separate article on Knowledge Graphs and Data Fabric will hopefully be written one day. The concluding section, as one can easily understand, was hurriedly added, though even six months later, these concepts are not much clearer.

Literature

1. Halpin, H., Monnin, A. (eds.) (2014). Philosophical Engineering: Toward a Philosophy of the Web
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2nd ed.)
3. Staab, S., Studer, R. (eds.) (2009) Handbook on Ontologies (2nd ed.)
4. Wood, D. (ed.). (2011) Linking Enterprise Data
5. Keet, M. (2018) An Introduction to Ontology Engineering

Source: habr.com