{"id":2867,"date":"2025-09-30T11:42:07","date_gmt":"2025-09-30T11:42:07","guid":{"rendered":"https:\/\/www.strategicstructures.com\/?p=2867"},"modified":"2025-10-01T18:27:51","modified_gmt":"2025-10-01T18:27:51","slug":"liberating-cohesion-rdf","status":"publish","type":"post","link":"https:\/\/www.strategicstructures.com\/?p=2867","title":{"rendered":"Liberating Cohesion: RDF"},"content":{"rendered":"

What do empathy, common enemies, and small talk have in common? They are all\u00a0cohesion mechanisms<\/a>. And so are calendars, clocks, protocols, plans, meetings, and memes. Cohesion mechanisms make elements be a whole or work as a whole. They do so by imposing constraints. Constraints reduce freedom and, in the case of agents, decrease autonomy and agency.<\/p>\n

All socio-technical systems need to\u00a0balance autonomy and cohesion<\/a>\u00a0to remain viable. There is then the need for a separate action or technology to enable autonomy. For instance, in organizations, cohesion brought by a goal can be balanced by autonomy via delegation of operational decision-making. More generally, cohesion brought by\u00a0why<\/em>\u00a0has to be balanced by autonomy of\u00a0what<\/em>, and cohesion of\u00a0what<\/em>\u00a0needs to be balanced by autonomy on\u00a0how<\/em>.<\/p>\n

There are, however, cohesion technologies that provide1<\/a><\/sup>The use of verbs like bring, provide, reduce, increase, enable, support and so on should not be taken to imply that standards of this kind have some kind of agency. The cohesion or autonomy is not the result of an action from their side but a consequence of their use.<\/span>\u00a0both cohesion and autonomy. Like other cohesion mechanisms, they apply constraints. Constraints reduce autonomy. At the same time, through their use, these special kinds of technologies increase the overall autonomy and agency of their users. Standards and protocols have the potential to be such a kind of technologies. Two popular examples, reviewed briefly in the\u00a0previous post<\/a>, are HTML and HTTP.<\/p>\n

This special quality of bringing both autonomy and cohesion distinguishes the cohesion mechanisms in the Interoperability area of the\u00a0CABIN spectrum<\/a>\u00a0from those in the other areas. I call this quality\u00a0liberating cohesion<\/em>.<\/p>\n

The present essay, part of the\u00a0Autonomy and Cohesion series<\/a>, will dive deeper into another standard that has this capability: RDF. Like HTML, RDF is an open standard maintained by W3C. While HTML is for representing content for human readers, RDF is for representing structured data, but for both humans and machines. Unlike HTML, RDF is not just a language; it is a whole framework.<\/p>\n

Let’s first see what RDF is and where it can be found, and then discuss how using it brings cohesion and autonomy at the same time.<\/p>\n

What is RDF?<\/strong><\/h2>\n

RDF stands for Resource Description Framework<\/em>.\u00a0Resource<\/em> is any entity2<\/a><\/sup>In the context of RDF, resource and entity are synonyms, and the latter is used in the RDF semantics specification.<\/span> such as person,3<\/a><\/sup>Regarding persons as resources is common but highly problematic, as I discussed\u00a0elsewhere<\/a>. That doesn\u2019t affect the value of RDF. It\u2019s simply a reminder that also here, an alternative, such as\u00a0entity<\/em>, would\u2019ve been more appropriate.<\/span>\u00a0place and just any thing, concrete or abstract, existing or imaginary. RDF provides a means to\u00a0describe<\/em>\u00a0resources using uniquely identifiable relations. These relations represent both characteristics of and relationships between resources. Lastly, it is a\u00a0framework<\/em>\u00a0that includes a conceptual model, semantics, vocabulary, and a set of serialization formats.<\/p>\n

RDF is a\u00a0data<\/em>\u00a0model, but the smallest element that can be considered RDF is the triple, which is already information.<\/p>\n

RDF provides a single model for all kinds of data structures. Everything in RDF is expressed by triples: instance data, metadata, semantics, data transformation, validation, and rules. The basic elements of the query language SPARQL are also triple patterns.<\/p>\n

RDF is a graph model, but its unit, the triple, is not just a node-edge-node construct. It is a logical statement.<\/p>\n

Let’s go through an example. In natural English, we can say:<\/p>\n

A cat named Pat sat on a mat.<\/p>\n

\n
\n
\n\"\"<\/picture>\n
\n
\n
An RDF triple has the form subject-predicate-object. Subject and predicates must be uniform resource identifiers.4<\/a><\/sup>A few clarifications. All URIs today are IRIs since they can accept international characters, while the original URIs were restricted only to ASCII characters. But I\u2019ll keep calling the URIs. The second clarification is that apart from the URIs, RDF1.1 allows to have also blank nodes. Blank nodes are nodes that serve as placeholders for resources without assigning them a URI. They are usually used for grouping triples where their common subject is not supposed to be referred from other resources so it doesn\u2019t need to have a global identifier. The last clarification is that, from RDF1.2, still a draft, subjects and objects of an RDF triple can also be triple terms, in other words, nested triples.<\/span> In other words, subjects always denote entities such as people, places and things. Objects can be URIs or literals, expressing numbers, dates and strings. When objects are URIs, they can be subjects of other triples. When objects are literals, they can have a datatype such as string, integer, date, and boolean. Triples, the objects of which are URIs, state the relationship between two entities, such as a cat and a mat, identified by the subject and object URI. Triples in which objects are literals describe some characteristic of the subject, for instance, cat-hasColor-white and cat-hasName-Pat.<\/span><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n

We need three things to express in RDF the cat statements above: a namespace,5<\/a><\/sup>That\u2019s only the case for HTTP URIs. DID URIs are domain-independent.<\/span> a convention for constructing identifiers, and a vocabulary6<\/a><\/sup>I use vocabulary and ontology interchangeably in this essay. In the context of semantic web ontologies, lightweight ontologies containing only definitions of properties and classes and RDFS-level axioms are usually referred to as vocabularies. There is also the term\u00a0controlled vocabulary,<\/em> which encompasses reference datasets such as taxonomies, thesauri, code lists and authority tables.<\/span> for the concepts. Let’s take the classic\u00a0example.org <\/strong>as a namespace. The convention for URI construction for instances of things will be: a mnemonic string denoting their type, suffixed by a number. Applying these conventions to our two concrete entities, cat and mat, we get http:\/\/example.org\/data\/cat1 <\/strong>and http:\/\/example.org\/data\/mat1 <\/strong>as their identifiers. Although we have chosen a convention to suggest the nature of these two things, for machines these identifiers are just strings. We need then some terms to make this meaning7<\/a><\/sup>That something is meaningful for machines is a shorthand to point to an important utility but taken literally can lead to dangerous anthropomorphizing.<\/span> explicit, and they should have URIs too. These terms will represent the nouns and verbs from the natural language but will be formally defined to remove ambiguity for non-human readers. Since such abstract concepts are also resources, just as the instances they describe, they need prefixes and a convention for the construction of their identifiers. Let’s use the domain http:\/\/example.org\/ <\/strong>again but separate the abstract concepts in another branch \/ontology <\/strong>and use # <\/strong>as a delimiter instead of \/<\/strong>. The naming convention for the unique part of the URI will be to use the respective noun for the types of things in\u00a0PascalCase<\/a>\u00a0and the respective verb for the relationship type in\u00a0camelCase<\/a>. Using these conventions, an RDF representation of the cat sentence, expressed in Turtle notation, will look like this:<\/p>\n

@prefix d: <http:\/\/example.org\/data\/> . \n@prefix o: <http:\/\/example.org\/ontology#> . \n\nd:cat1 rdf:type o:Cat . \nd:cat1 o:hasName \"Pat\" . \nd:cat1 o:sat d:mat1 . \nd:mat1 rdf:type o:Mat .<\/pre>\n
The Turtle (Terse RDF Triple Language) notation, one of the many ways RDF can be serialized (more on that later), is easy to read. By declaring prefixes, the identifiers can be written as compact URIs. When a machine reads them, it will concatenate the common and unique parts of the URI so that d:cat1<\/strong> will become http:\/\/example.org\/data\/cat1<\/strong>. In addition, Turtle includes some syntactic sugar. For example “a” stands for rdf:type<\/strong> and is read “is a” making it sound like the natural statement it formally represents. To resemble written natural language even more, each Turtle statement ends with a full stop. Another element of syntactic sugar is using semicolons in a way again similar to regular punctuation to enable the listing of statements for the same subject without the need to repeat the subject. Applying these two conventions, we can replace the Turtle snippet above with this equivalent:<\/p>\n
@prefix d: <http:\/\/example.org\/data\/> .\n@prefix o: <http:\/\/example.org\/ontology#> .\n\nd:cat1  a o:Cat ;\n        o:hasName \"Pat\" ;\n        o:sat d:mat1 .\nd:mat1  a o:Mat .\n<\/pre>\n
Easy to read, neat and elegant.<\/p>\n
\u0415very set of RDF triples is a graph by virtue of having only triples and the fact that the same URIs in different triples represent the same resources. You can find them referred to as\u00a0semantic<\/em>\u00a0knowledge graphs since they are knowledge graphs with explicit semantics, in other words, self-describing knowledge graphs. In graph-theoretic terms, they are directed labelled graphs:\u00a0directed,<\/em>\u00a0because the meaning of \u0430 predicate is valid only in the direction from \u0430 subject node to an object node, and\u00a0labeled<\/em>, since the edges have labels which are the URIs of the predicates.<\/p>\n
“Pat” is a literal value node, and this is where the graph ends. A literal cannot be the subject of a triple. d:mat1<\/strong> is a URI, so the graph can grow from that node on by describing the entity it represents and its relations with other entities. For example, we can add a triple about the color of the mat:<\/p>\n
@prefix d: <http:\/\/example.org\/data\/> .\n@prefix o: <http:\/\/example.org\/ontology#> .\n\nd:cat1  a o:Cat ;\n        o:hasName \"Pat\" ;\n        o:sat d:mat1 .\nd:mat1  a o:Mat ;\n        o:hasColor \"brown\".\n<\/pre>\n
Visually, the graph will look like this:<\/p>\n
\n
\n
\n\"\"<\/picture>\n
\n
\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
Relationships in RDF are first-class citizens with the same capabilities as entities. For example, unlike property graphs, where edges cannot be linked to other edges, in RDF it is common to have edges (RDF properties) linked to other edges or nodes. What’s more, such constructs enhance the expressivity and the deductive power of the RDF graphs. To illustrate this, let’s extend our ontology with the following statements:<\/p>\n
@prefix rdf: <http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#> .\n@prefix rdfs: <http:\/\/www.w3.org\/2000\/01\/rdf-schema#> .\n@prefix o: <http:\/\/example.org\/ontology#> .\n\no:perched  a rdf:Property ;\n        rdfs:subPropertyOf o:sat .\n\no:sat a rdf:Property .\n\no:hasName a rdf:Property.\no:hasNickName a rdf:Property;\n        rdfs:subPropertyOf o:hasName .\n<\/pre>\n
Then, if we have more information, say:<\/p>\n
A bird, nicknamed Nerd, perched on a birch,<\/p>\n
in RDF, it will look like this:<\/p>\n
@prefix d: <http:\/\/example.org\/data\/> .\n@prefix o: <http:\/\/example.org\/ontology#> .\n\nd:bird1  a o:Bird ;\n        o:hasNickName \"Nerd\" ;\n        o:perched d:tree123\nd:tree123  a o:Birch .\n<\/pre>\n
Then, if we ask, running a logical reasoner or a SPARQL query, who sat and on what, the answer would be the cat Pat sat on a mat (as stated) and the bird Nerd sat on a Birch (inferred), even though there are different relationships (RDF properties) linking the two animals with how they are called and on where they happen to be situated.<\/p>\n
Where can one find RDF?<\/strong><\/h2>\n
\n
\n
RDF is not used as much as its maturity and the benefits it brings would suggest. At the same time, it is spread wider than most people suspect. One manifestation of RDF is as Linked Open Data (LOD). Many organizations from the public sector, life sciences, cultural heritage and media publish RDF datasets using shared vocabularies and semantic links to other LOD datasets. Some public knowledge graphs contain general knowledge (cross-domain) and others domain-specific knowledge. <\/span>Wikidata<\/a>,\u00a0<\/span>DBpedia<\/a>\u00a0and\u00a0<\/span>YAGO<\/a>\u00a0are prominent examples of general knowledge LOD graphs. Of them, Wikidata is the biggest, with close to 16 billion triples today and growing fast. If you run\u00a0<\/span>this query<\/a>, it will generate a small subset of the Wikidata graph, showing the influences in the Age of Enlightenment. The relations are of the type\u00a0<\/span>influenced by<\/em>. If you click on a node, it will show first-degree connections.<\/span><\/p>\n<\/div>\n<\/div>\n
\n
\n
\n\"\"<\/picture>\n
<\/div>\n<\/div>
Wikidata graph rendition of a query to get the influences in the age of Enlightenment, in state after clicking on the node representing Gottfried Wilhelm Leibniz.<\/figcaption><\/figure>\n<\/div>\n
Examples of domain-specific knowledge graphs are\u00a0UniProt<\/a>\u00a0for protein data and\u00a0Cellar<\/a>\u00a0for the EU legislation. UniProt is currently the biggest open knowledge graph with 112 billion triples.<\/p>\n
There are several ways to interact with LOD publications. They usually offer keyword search, faceted browsing or some other way to explore the graph by clicking, and a SPARQL endpoint.<\/p>\n
LOD publications are not the only Linked Data accessible on the open web. There is a lot of Linked Data embedded in web pages, and their number increases significantly each year. The common crawl corpus counted close to 139 billion schema.org triples in December 2023, while there were 106 billion in 2022, 94 billion in 2021, and only 20 billion in 2018. As expected, the biggest number and increase are related to products.<\/p>\n
\n
\n
\n
\"\"
Source: https:\/\/webdatacommons.org\/structureddata\/schemaorg\/<\/p><\/div>\n
Apart from Linked Data available in RDF stores behind <\/span>open SPARQL endpoints<\/a>\u00a0or embedded in web pages as RDFa or JSON-LD, there is also Linked Enterprise Data (LED), available as closed enterprise knowledge graphs in corporate networks. It is used as a semantic layer to unify and integrate the data fragmented in silo applications or as operational knowledge graphs, in other words, as a generic backend and not just as an analytical read-only layer. Well-known companies such as Bosch, IKEA, UBS, BASF, Morgan Stanley, Wells Fargo, Schneider Electric, BMW, Astra Zeneca, Pfizer, and Roche use RDF in various degrees. There are also some less known names but prominent in their industry. For example, you probably haven’t heard of Grundfos, but they are the largest pump manufacturer in the world, and they use RDF extensively.<\/span><\/p>\n<\/div>\n<\/figure>\n<\/div>\n
How does RDF bring autonomy and cohesion?<\/strong><\/h2>\n
\n
\n
RDF combines universal ways to name, structure and give meaning to data using only open standards. Naming is done with URIs; the structure is always the subject-predicate-object triple, and the meaning is provided by extending RDF with shared vocabularies. These three ways, individually and in combination, enable autonomy and cohesion. Let’s see how.<\/span><\/p>\n<\/div>\n<\/div>\n
Naming (Identifiers)<\/strong><\/h3>\n
URIs provide an efficient and effective solution to the problem of relating names and things. They are\u00a0proper names<\/a>.<\/p>\n
[T]he architects of the Web have taken hold of the idea of proper names, and without purposefully altering its definition, have made naming the first supporting pillar of the Web, thus formulating an answer to the ages-old question of the relationship between words and things by combining in an original\u2014and unintentional!\u2014fashion the thoughts of Frege, Russell, Wittgenstein, and Kripke.8<\/a><\/sup>That something is meaningful for machines is a shorthand to point to an important utility but taken literally can lead to dangerous anthropomorphizing.<\/span><\/blockquote>\n
One thing can be identified by multiple URIs (more on that aspect of autonomy later), but one URI uniquely identifies one referent (cohesion). At the same time, there can be many human-readable labels associated with a URI elegantly solving multilingualism and various UI and text-search problems. Labels are decoupled from the identifiers (autonomy).<\/p>\n
Labels are typically linked with rdfs:label <\/strong>but there can be more sophisticated relations, such as those given by skos:prefLabel<\/strong>, skos:altLabel<\/strong>, and skos:hiddenLabel<\/strong>. And yet, that higher expressivity doesn’t cost any cohesion since all three of them are rdfs:subProperty <\/strong>of rdfs:label<\/strong>. When labels need lifecycle data and other metadata, that is just a modeling problem, elegantly solved by the popular extension of SKOS,\u00a0SKOS-XL<\/a>.<\/p>\n
URIs are global. They are not coupled to a particular data store. Such a\u00a0decoupling<\/a>\u00a0gives autonomy: all things represented with URIs are not dependent on a particular database. At the same time URIs bring interoperability and respectively cohesion: URIs can be resolved across different data stores. In comparison, identifiers in SQL databases are unique only within a table or a database instance. Likewise in labeled property graphs, the identifiers are database-specific.<\/p>\n
HTTP URIs are resolvable. That allows you to perform an exploratory search.9<\/a><\/sup>Watch this 18 min. lecture<\/a> by Prof. Harald Sack if you want to learn more about exploratory search with RDF.<\/span>\n
or browse the RDF graph in any direction you want using the so-called follow-your-nose approach. Every hop in the graph is not simply a navigation step like with the regular hyperlinks. All nodes are linked in a meaningful way, always a part of a bigger story. The extra benefit is finding new things and associations serendipitously.<\/p>\n
HTTP URIs have a small drawback when it comes to autonomy. They are coupled with a host. But that’s not a limitation for RDF. URIs in RDF can be host-independent, as is the case with\u00a0decentralized ID (DID)<\/a>, another open standard maintained by the W3C.<\/p>\n
URIs are globally unique identifiers, but one URI is not a unique way to identify one particular thing. That would be a case of an extreme centralization. On the contrary, every organization (or every person if need be) is free to identify resources independently. That autonomy is balanced with cohesion. Two URIs that identify the same thing can be linked with owl:sameAs<\/strong>. Such linking is\u00a0one of the Linked Data principles<\/a>\u00a0and is the criterion for\u00a05 stars<\/a> open data publishing. That’s also applicable in the enterprise context where along with owl:sameAs<\/strong>, there are alternative approaches applied. One such approach is using the property gist:IndetifiedBy<\/strong> and the class gist:ID<\/strong>.10<\/a><\/sup>The approach is well explained in this video<\/a>.<\/span>\n
Structure (Triple)<\/strong><\/h3>\n
\n
\n
In most data management approaches, you need to know the structure to query and use the data. Meaning is tightly coupled with structure.<\/span><\/p>\n
Even in simple cases, like having two slightly different tables, and even when they are created with the same tool, if you paste one of the tables below or next to the other, you won\u2019t get a coherent combined table. In RDF, meaning and structure are decoupled. The structure is always a triple and can express anything. If you bring two different RDF graphs together, created in different contexts and using different tools, they become one valid RDF graph. If you have two N-triples files and copy and paste one inside the other, that will make a valid and coherent RDF graph.<\/span><\/p>\n<\/div>\n<\/div>\n
RDF has one structure, triple, used for everything. The instance data is RDF triples, which get meaning from ontologies, and ontologies are RDF triples too. The typical way of transforming non-RDF to RDF is by creating RML mapping which are also RDF triples, and so are the validation (SHACL) and the business rules.11<\/a><\/sup>There are different standards for expressing business rules in RDF: SHACL, SPIN, SWRL, and RIF.<\/span>\n
It’s triples all the way down.<\/p>\n
RDF is a conceptual model. You have the autonomy to serialize it and store it the way you want.<\/p>\n
\n
\n
\n\"\"<\/picture>\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
That’s about files, but of course, quite often RDF is stored in databases. And while the typical RDF store is a triples store (or quadstore), RDF can be stored in SQL,12<\/a><\/sup>See https:\/\/timbr.ai<\/span> graph DBs,13<\/a><\/sup>For example, one of the most popular graph DBs, neo4j can become an RDF store using the neosemantics plugin<\/a>.<\/span>\u00a0document databases, or key-value stores\u00a0Oxigraph<\/a>.14<\/a><\/sup>Oxigraph is an RDF store based on the RocksDB<\/a> key-value store.<\/span>\n
Semantics (Logic)<\/strong><\/h3>\n
\n
\n
Decoupling structure and semantics, combined with the RDF feature that data and metadata are expressed in one and the same structure, gives the freedom to postpone schema definition. This makes RDF-based systems future-proof since the cost of change is very low.<\/span><\/p>\n<\/div>\n<\/div>\n
If, in the description of Pat the cat, we add just another triple:<\/p>\n
dcat1 a wd:Q146<\/pre>\n
where wd:Q146 <\/strong>represents the class of cats in Wikidata, we get:<\/p>\n
@prefix d: <http:\/\/example.org\/data\/> .\n@prefix o: <http:\/\/example.org\/ontology#> .\n@prefix wd: <http:\/\/www.wikidata.org\/entity\/> .\n\nd:cat1  a o:Cat, wd:Q146 ; \n        o:hasName \"Pat\" ;\n        o:sat d:mat1 .\nd:mat1  a o:Mat ;\n        o:hasColor \"brown\".\n<\/pre>\n
Using a shared vocabulary brings semantic cohesion. Now, we can ask, for instance, what the name of the oldest known animal of Pat’s kind is, and we get the answer “Creme Puff,” together with other data such as birth and death dates. The node wd:Q146 <\/strong>makes one coherent graph.<\/p>\n
\n
\n
\n\"\"<\/picture>\n
\n
\n
<\/div>\n<\/div>\n<\/div>\n<\/div>
Note: the edges are labeled with Wikidata property labels, not with their URIs, to be easier to read.<\/figcaption><\/figure>\n<\/div>\n
Using a shared vocabulary is a powerful way to bring cohesion, but it also creates a dependency. Such a dependency, however, can be avoided while keeping the benefits of the relationships. Here’s an example. The\u00a0Software Description Ontology<\/a>(SDO) provides a way to describe software components. If you use this ontology, you will declare the applications you want to describe as sd:Software<\/strong>. This will also make them instances of the class schema:SoftwareApplication<\/strong>, because\u00a0sd:Software <\/strong>is a subclass of\u00a0schema:SoftwareApplication<\/strong>.<\/p>\n
The interoperability of your data will be increased since schema.org is widely used. The cohesion achieved this way, however, will not create dependency as would have been the case if\u00a0schema:SoftwareApplication<\/strong> was directly re-used in SDO.<\/p>\n
If, for some reason, schema.org is gone tomorrow, nothing in your statements will break. And if another ontology, with its own class\u00a0ex:Application<\/strong>, uses the same relationship, its designers have the autonomy to have their own probably slightly different notion of what a software application is. Every instance of sd:Software\u00a0<\/strong>and\u00a0ex:Application\u00a0<\/strong>is a\u00a0schema:SoftwareApplication <\/strong>but not vice versa.<\/p>\n
\n
\n
\n\"\"<\/picture>\n
\n
\n
<\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
And this was just using one property rdfs:subClassOf<\/strong>. RDF can be further extended to express complex relations using all axioms of first-order logic or a subset of it. This expressive power comes with two additional benefits: logical inconsistencies can be avoided, and inferencing over the graph can generate new statements (triples), which are the logical consequences of the asserted statements. We learn more from what we know already.<\/p>\n
Conclusion<\/h2>\n
\n
\n
RDF is one of those standards that brings both autonomy and cohesion. It provides interoperability, which results in cohesion between heterogeneous data sources, and flexibility, which results in increased autonomy of its users. The balance between autonomy and cohesion is achieved through standardizing identification, structure and semantics.<\/span><\/p>\n<\/div>\n<\/div>\n
First published on\u00a0<\/em>Link & Think<\/em><\/a>.<\/em><\/p>\n