Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
k00ni opened this issue Jun 18, 2024 · 4 comments
Open

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

k00ni opened this issue Jun 18, 2024 · 4 comments

Comments

@k00ni
Copy link

k00ni commented Jun 18, 2024

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
Copy link

aabs commented Jun 24, 2024

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
Copy link
Author

k00ni commented Jun 24, 2024

@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
Copy link
Member

TallTed commented Jun 24, 2024

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
Copy link

chiarcos commented Jun 25, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants