Which real use cases are there for RDF/OWL ontologies?

[k00ni]

Which real use cases are there for RDF/OWL ontologies?

That's not a trick-question and I am very interested in any feedback. I am asking it myself lately, after all the years I become more and more unsure, why someone should bother with all the headaches, overhead etc. to run a RDF stack (technologies, languages, specs, ...). If you take into consideration the amount of available systems, services and languages to handle a certain use case (e.g. writing a service), its hard to provide a certain set of "parameters" for which most of the developers would say, "yes, RDF-based ontologies make sense here".

---

I revised this post multiple times, because this is a difficult topic. RDF/OWL ontologies are related to at least the fields of Computer Science (Logics, Software Engineering, Data Structures, Databases, ...) and Knowledge Engineering/Organization (e.g. terminlogies, taxonomies, open- vs. closed world approaches). Because of the complexity, which is also mentioned in other issues here, its often more than just a RDF file downloaded from the web and used inside a program. People need to know a lot about RDF technologies to get something out of it.

Before I continue, here is what I mean with an RDF/OWL ontology: Basically a document which is written in any OWL 1/2 variant (such as OWL 2 EL) or is a RDF file (in a common serialization) containing a few class/property definitions. Commonly known are FOAF or SKOS, but this also includes very specialized ontologies such as https://bioportal.bioontology.org/ontologies/PDRO. In addition, I refer to the "Informal Definition 1" on page 2 of the following publication of Fabian Neuhaus: What is an Ontology? (2018).

Here are the use cases I've gathered so far over the years:

1. Establish/Increase Interoperability: e.g. create a terminology for a domain which a team (of experts) has to use
2. Data integration: use ontology to map two or more data "worlds", which have different meaning/terminology
3. Allow machines to "understand" data and services (whatever that means)
4. Information exchange: improves information exchange between systems by providing a standardized terminology/vocabulary/....
5. Data Analysis: enrich data with more data to get deeper insights into your data
6. Reuse information/knowledge: use the same "knowledge" in a web service as well in an app (here is a paper about this topic, "Developing Consistent and Modular Software Models with Ontologies", https://www.researchgate.net/publication/221026467_Developing_Consistent_and_Modular_Software_Models_with_Ontologies)
   ...

I am pretty sure, there are plenty more to add. Reading these and others, I sometimes feel like reading the latest whitepaper of some company trying to sell me something. "Ontologies can be used for everything!", is what I understand. Writing domain knowledge or facts as source code/database models seems weird/contrary at first, but its common practise and works to some degree. To give this up (at least partly) and switch to a RDF ontology there must be big benefit in the end.

[aabs]

If developer tooling for RDF were more user-friendly, discussions about its adoption might be less necessary. When a technology is easy to use, its value is rarely debated. Take JSON and RDF for example. While RDF arguably offers superior capabilities, on the surface their data formats (JSON and Turtle) are quite similar.

The real difference lies in usability. JSON is widely adopted because it has simple tools that seamlessly integrate with common developer toolsets. In contrast, RDF suffers from a mismatch between its underlying data model (e.g. dependent types in OWL) and the (v-table derived) object-oriented model most developers are familiar with. This incompatibility prevents existing tools (like Object-Relational Mappers) from working well with RDF data. This is just one example, but it highlights a key challenge: modern development environments don't offer good support for bridging the gap between these two models, requiring significant expertise from developers to overcome.

[k00ni]

@aabs I am not sure if I get your point.

My question was for which use cases are RDF/OWL ontologies (+ tooling, languages, ...) most suited for? User-friendliness (Usability) can play an important role for (major) adaptions of certain tooling, yes, but its also the knowledge/skills required to puzzle everything together. Why using RDF to formulate a taxonomy if I could use YAML/JSON/...? Why bother with an OWL 2 dialect when I instead use an object relational mapper (e.g. Doctrine) or write some source code? We might all agree that RDF is providing further advantages, but are they "enough" to worth the additional amount of work in comparison?

[TallTed]

While RDF arguably offers superior capabilities, on the surface their data formats (JSON and Turtle) are quite similar.

RDF is a data model.

JSON (including JSON-LD) and Turtle are serializations a/k/a formats.

JSON relies on simple strings as keys, which are only expected to identify the same thing within a single JSON document, and that identification is typically communicated out-of-band.

JSON-LD uses a feature of JSON, the @context, to translate those simple string keys to URIs, which are expected to identify the same thing -- and be dereferenceable! -- worldwide.

An RDF ontology is not terribly different from a SQL schema, except that the SQL schema is (again) expected to be valid within a single SCHEMA or CATALOG hosted by a single logical DBMS instance, and the RDF ontology is expected to be valid worldwide.

All that said...

Horses for courses. Use the right tool for the right job. Tabular relational (a/k/a SQL) DBMS are very well suited for densely populated data, where nearly every cell is populated with a value. Directed graph (including RDF) DBMS are very well suited for sparsely populated data, where you may not know the value for every attribute of every entity of a given class, but you can easily store the values you do know, and add an attribute (that applies to every member of the class) at any time, without needing to change the whole schema definition.

And so on.

[chiarcos]

*Which real use cases are there for RDF/OWL ontologies?*

I am somewhat biased, of course, because my insight in the industry is partial, at best, but it seems to me that RDF/OWL ontologies are used quite substantially for managing domain terminologies, and I primarily mean as a central hub for hierarchically organized terms. Not sure I ever saw a very convincing industry case for reasoning that wasn't sufficiently dealt with with RDFS semantics and/or SPARQL search. The other major application of OWL is for data modelling for RDF data. In that regard, it is quite widely used (to the extent that RDF data is used in the first place), and reasoning has been (historically) used for validation. Other than that, I there are, of course, applications of RDF data for data modelling and exchange, where the ontology component is not so actively used. I think a number of Linux file indexing engines operate in that way, for example, at least Baloo and Tracker. Because of all of that, I personally tend to emphasize the Linked Data aspect of Semantic Web technologies rather than the reasoning aspect, but, as I said, I might be biased. I am much more convinced of the usefulness of RDF in establishing interoperability across heterogeneous data, databases and tools than I am of the reasoning aspect, and the ever-increasing popularity of graph databases confirms that point to some extent. Non-RDF graph DBs lack RDF federation, and thus, a key benefit of the technology, but they are otherwise equivalent to RDF databases -- except that they come without the theoretical overhead of ontologies. It's a bit of an oversimplification, but it almost seems as if the *advantage* (?) of not being backed by ontologies outweighs the *disadvantage* (!) of not having cross-platform federation. I'd be happy to be proven wrong, though.

…

Message ID: ***@***.***>

[Somaya-Assaker]

Hello everyone, Please add my name to the list so I can join your group exercise session.

[namedgraph]

Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix

[nicobrb]

None. It's just a hustle for researcher that have to show that the argument they spent most of their life researching has relevance.