I asked ChatGPT and Copilot to parse my two favorite home-grown OWL examples, do the appropriate inferencing, and show me the results, and I was impressed.

First of all, you probably don’t need OWL, but I have one example about querying furniture inventory and another about querying people that I think nicely demonstrate the value of OWL for certain use cases. The first, which I created when Trying out Blazegraph and have used for other demos since, has triples that identify some chairs and desks and say what rooms they are each in. It also says which rooms are in which buildings. These triples aren’t enough to tell a SPARQL processor which furniture is in building 101, but if we have a triple saying that dm:locatedIn is a transitive property, and we have two more triples telling us that dm:Chair and dm:Desk are both subclasses of dm:Furniture, then an OWL processor can tell us which furniture is in which building. Blazegraph did it fine at the time and GraphDB and several other processors have done fine with it since.

ChatGPT and Copilot both did this quite well. It was especially nice to see how they could both explain the implications of the distinction between a regular SPARQL processor and one that uses inferencing.

Understanding the OWL properties used to describe my data

Below is an edited version of my interaction with ChatGPT about the furniture example:

Here is some RDF data in the turtle syntax that uses RDFS and OWL to define a data model. The RDF data also includes some instance data. I am going to ask you some questions about it:

I then pasted the furniture data mentioned above; here is the response:

Thanks for sharing the RDF data. It defines a simple ontology involving buildings, rooms, and furniture, and models where each item is located using a transitive property dm:locatedIn.

I’m ready for your questions—what would you like to ask about this data?

List any furniture in building 200.

Furniture and Their Locations:

d:chair35 → locatedIn d:room202 → locatedIn d:building200

d:desk59 → locatedIn d:room202 → locatedIn d:building200

ChatGPT also explained its logic for getting that answer, which I won’t reproduce here to get to the interesting part faster. In an earlier version of this exchange, at this point I asked:

Can you show me a SPARQL query that is the equivalent of my question about which chairs are in building 200?

It responded with this and some additional explanation:

PREFIX d: 
PREFIX dm: 
PREFIX rdf: 

SELECT ?chair
WHERE {
  ?chair rdf:type dm:Chair .
  ?chair dm:locatedIn+ d:building200 .
}

(Good SPARQL habit to have the first triple pattern specify the class of the returned data!) I then asked

How would that return any results if the input data didn’t have any triples of the form ?chair dm:locatedIn+ d:building200 ?

Awesome question — and you’re absolutely right to question that!

You’re pointing out something subtle but important: SPARQL doesn’t do OWL reasoning (like transitive inference) by default unless you either:

Use a triplestore or reasoner that supports OWL inference (like Apache Jena/Fuseki with reasoning enabled, or GraphDB, Stardog, etc.).

Explicitly model the transitive paths in the data using property paths (as in dm:locatedIn+) — but only if those intermediate triples exist in the data.

And then the explanations continued. I was happy to see it spell out the distinction between SPARQL querying that takes advantage of inferencing and SPARQL querying that doesn’t, because this is an important point when learning about RDF technology. I was also happy to see it mention GraphDB (the product that I spend most of my professional time documenting or making videos about) as one of the main tools that can do SPARQL querying with inferencing.

Trying all of this out with Copilot gave me roughly the same results.

Inferring class membership

A very old-school use of OWL is to declare classes and then, instead of listing which instances belong to which classes (which is what most systems with any notion of classes and instances do), to list conditions for membership in each class and then query to see what their instances are.

OWL classes that are defined by describing which instances meet which conditions are known as restriction classes. In some cases, these conditions may be so complex that the calculations must run overnight. This led to various OWL profiles that standardized on specific subsets of inferencing capabilities so that implementations optimized for certain inferencing tasks wouldn’t necessarily take so long to run.

Example ex424.ttl from my book Learning SPARQL demonstrates the use of restriction classes by listing several musicians, where they are from, and what instruments they play, with no explicit indication of any of them being members of classes. The dataset includes a dm:Guitarist class defined as someone who plays the guitar and a dm:Texan class defined as someone who has “TX” as their dm:stateOfBirth value. A third class, dm:TexasGuitarPlayer, is defined as the intersection of the first two classes. (Set operations are a popular tool for defining OWL restriction classes.)

I told Copilot the following:

The following is an RDF OWL model with some instance data, written in the Turtle syntax. Perform any necessary inferencing with this as input and then I will ask you some questions about the resulting triples.

I’d be happy to help with RDF OWL inferencing! Please provide the Turtle syntax model, and I’ll process it accordingly. Once I’ve performed the necessary inferencing, you can ask me questions about the resulting triples.

I then pasted the ex424.ttl content. Here is how it responded:

[Copilot result of OWL inferencing]

I had one more request for it:

List the instances of http://learningsparql.com/ns/demo#TexasGuitarPlayer.

We’ve already seen the answer above, but I wanted to see if it understood that http://learningsparql.com/ns/demo#TexasGuitarPlayer was the full URI version of dm:TexasGuitarPlayer. It did:

Based on the inferencing we performed, the instances of dm:TexasGuitarPlayer (http://learningsparql.com/ns/demo#TexasGuitarPlayer) are:

d:m2 (Charlie Christian)

d:m6 (Roky Erickson)

These musicians are both born in Texas (d:TX) and play guitar (d:Guitar), fulfilling the criteria for being classified as dm:TexasGuitarPlayer. Let me know if you’d like to explore further details or additional queries!

(As a tech writer, it was nice to see it put the prefixed names in a monospaced font.) With the same input, ChatGPT inferred the dm:TexasGuitarPlayer class membership just fine.

If you’re a really big OWL fan, it would be interesting to push the boundaries of some of those OWL profiles that I described above by trying out the most sophisticated features of the different OWL profiles with ChatGPT, Copilot, and other LLM-based chat tools.


Comments? Reply to my Mastodon or Bluesky posts announcing this blog entry.