In a prior blog (SPARQL: Updating the URI of an owl:Class in place) we looked into how to use SPARQL to rename a class in a triple store.  The main steps are below. We showed how to do this for the example of renaming the class veh:Auto to veh:Car.

1. change the instances of the old class to be instances of the new class
2. replace the triples where the class is used in either the subject or object of the triple
3. look around for anywhere else the old class name is used, and change accordingly.

The last step addresses the fact that there are a few other things that you might need to do to address all the consequences of renaming a class.   Today we will see how to handle the situation where your instances use a naming convention that includes the name of the class.  Let’s say the instances of Car (formerly Auto) are all like this:  veh:_Auto_234 and veh:_Auto_12. We will want to change them to be like: veh:_Car_234.

The main steps are:

1. Figure out how you are going to use SPARQL string operations to create the new URI given an old URI.
2. Replace triples using the oldURI in the object of a triple.
   1. Determine where the oldURI is used as the object in a triple, and use CONSTRUCT to preview the new triples using the results of step 1.
   2. Use DELETE and INSERT to swap out the old triples with the new URI in the object.
3. Replace triples using the oldURI in the subject of a triple.
   1. Determine where the oldURI is used as the subject in a triple, and use CONSTRUCT to preview the new triples using the results of step 1.
   2. Use DELETE and INSERT to swap out the old triples with the new URI in the subject

In practice, we do step 1 and step 2a at the same time.  We find a specific instance, and filter on just that one (e.g. veh:_Auto_234) to keep things simple. Because we will be using strings to create URIs, we have to spell the namespaces out in full, or else the URI will incorrectly contain the string “veh:” instead the expanded form, which is: “http://ontologies.myorg.com/vehicles#”.

CONSTRUCT {?s ?p ?newURI}
WHERE {?oldURI rdf:type veh:Car .
       ?s ?p ?oldURI.
       FILTER (?oldURI in (veh:_Auto_234))
       BIND (URI(CONCAT ("http://ontologies.myorg.com/vehicles#_Car_",
                         STRAFTER (STR(?oldURI),"_Auto_")))
             AS ?newURI)
       }

This should return a table something like this:

This tells you there are exactly three triples with veh:_Auto_234 in the object, and shows you what the new triples will be when you replace the old ones.   After this, you might want to remove the FILTER and see a wider range of triples, setting a LIMIT as needed. Now you are ready to do the actual replacement (step 2b).   This is what you do:

1. Add a DELETE statement to remove the triple that will be replaced.
2. Replace the “CONSTRUCT” with “INSERT” leaving alone what is in the brackets.
3. Leave the WHERE clause as it is, except to remove the FILTER statement, if it is still there (or just comment it out).

Sample Graph of Triples

This will do the change in place for all affected triples. Note that we have constructed the URI from scratch, when all we really needed to do was do a string replace.  The latter is simpler and more robust.  Using CONCAT and STRAFTER gives the wrong answer if the string “_Auto_” does not appear in the URI. Here is the query to execute, with the simpler string operation:

DELETE {?s ?p ?oldURI}
INSERT {?s ?p ?newURI }
WHERE {?oldURI rdf:type veh:Car .
       ?s ?p ?oldURI .
       BIND (URI(REPLACE(STR(?oldURI), "_Auto_", "_Car_")) AS ?newURI)
       }

Step 3 is pretty much identical, except flip the subject and object.  In fact, you can combine steps 2 and 3 into a single query.  There are a few things to watch out for:

1. VERY IMPORTANT: make sure you do steps 2 and 3 in order.  If you do step 3 first, you will blow away the rdf:type statements that are needed to do step 2.
2. It is easy to make mistakes, backup the store and work on a copy.
3. When creating URIs from strings, use full namespaces rather than the abbreviated qname format.
4. Check the count of all the triples before and after each time you make a change, track down any differences.

Read Next:

• SPARQL: Updating the URI of an owl:Class in place

Background

We have been developing solutions for our clients lately that involve loading an ontology into a triple store, and building a UI for data entry. One of the challenges is how to handle renaming things.  If you want to change the URI of a class or property in Protégé you load all the ontologies and datasets that use the old URI and use the rename entity command in the Refactor menu.  Like magic, and all references to the URI are changed with the press of the Enter key.   In a triple store, it is not so easy. You have to track down and change all the triples that refer to the old URI. This means writing and executing SPARQL queries using INSERT and DELETE to make changes in place.  Below is an outline of how to rename a class.

Steps of Change

Let ?oldClass and ?newClass be variables bound to the URI for the old and new classes respectively – e.g. ?oldClass might be veh:Auto and ?newClass might be veh:Car.   The class rename operation involves the following steps:

1. Change all instances of ?oldClass to be instances of ?newClass instead. e.g.
   veh:myTeslaS   rdf:type   veh:Auto is replaced with
   veh:myTeslaS   rdf:type   veh:Car
2. Find and examine all the triples using ?oldClass as the object.  It may occur in triples where the subject is a blank node and the predicate is one of the several used for defining OWL  restrictions. E.g . _:123B456x78  owl:someValuesFrom   veh:Auto
   Replace triples with the old class URI in the object with new triples using the  new URI. Note, you might want to do the first part of the next step before doing the replace.
3. Find and examine all the triples using ?oldClass as the subject. It may occur in triples for declaring subclass relationships, comments as well as the triple creating the class in the first place. e.g. veh:Auto   rdf:type   owl:Class
   Replace triples with the old class URI in the subject with new triples using the  new URI.
4. Look around for anywhere else that the old name may be used.  Possibilities include:
   1. If your instances use a naming convention that includes the name of the class (e.g. veh:Auto_234)then you will have to find all the URIs that start with veh:_Auto and use veh:_Car  instead.  We will look into this in a future blog.
   2. The class name may occur in comment strings and other documentation.
   3. It may also be used in SPARQL queries that are programmatically called.

Here is some SPARQL for how to do to the first step.

# Rename class veh:Auto to veh:Car
# For each ?instance of ?oldClass
# Replace the triple <?instance rdf:type ?oldClass>
#               with <?instance rdf:type ?newClass>
DELETE {?instance rdf:type ?oldClass}
INSERT {?instance rdf:type ?newClass}
WHERE  {BIND (veh:Auto as ?oldClass)
        BIND (veh:Car as  ?newClass)
        ?instance rdf:type ?oldClass . }

Gotchas

There are many ways to make mistakes here. Watch for the following:

• Having the DELETE before the INSERT seems wrong, fear not, it is just an oddity in the SPARQL syntax.
• Save out a copy of the triple store, in case things go wrong that are hard to undo.  One way to do this is to make all the changes to a copy of the triple store before making them in the production one. Do all the steps, make sure things worked.
• Make sure your namespaces are defined.
• Before you make a change in place using INSERT and DELETE, always use CONSTRUCT to see what new triples will be created.
• Think about the order in which you replace triples.  You can easily end up replacing triples in one step, that you needed to find the triples to replace in the next step.
• Always check the total count of triples before and after an operation that replaces triples. Generally it should be the same; track down any exceptions.  The count may be less due to duplicate triples that may occur in different named graphs.
• A cautious approach would be to first insert the new triples and on a second step remove the old ones.  I tried this and it did not work, it seems like a bug.  Throw caution to wind, and do the delete and insert at once. You have a backup, and once you get the hang of it, the extra step will just be extra work.
• It may not be possible to fully automate changes in comments and SPARQL queries that are used programmatically.  Check to see what needs to change, and what doesn’t.

What Next?

After you get step 1 working, try out steps 2 and 3 on your own, all you need to do is some straight-forward modifications to the above example.  Step 4 involves more exploration and custom changes.

In an upcoming blog, we explore one of those changes.  Specifically, if your naming convention for instances uses the class name in the URI then those instance URIs will have to change (e.g. from veh:_Auto_2421 to veh:_Car_2421).

Read Next:

• SPARQL: Changing Instance URIs

We’ve found ourselves working with D3(d3js.org) more and more lately, both for clients and for our own projects. So far we’ve really just begun to scratch the surface of what it can do (if you’re unfamiliar, take a moment to browse the examples). Despite our relative lack of experience with the library, we’ve been able to crank out demos at a wonderfully satisfying pace thanks to our decision early on to focus on creating high-level, DRY abstractions. Though there is a ton of flexibility and extensibility, D3 does seem to have a few broad categories of visualizations based around the shape of input data. The one we’re going to focus on here is the flare.js format, which looks roughly like this:

This format seems to be the basis of a large number of useful visualizations dealing with nested, tree-shaped data. The challenge is that in semantic systems it’s just not possible to construct a SPARQL query that returns data in a format anywhere near the “flare” example above. What you’re more likely to see something structurally very similar to this:

So what to do? One path we could take is to write a server-side endpoint that returns data in the right structure, but this has the disadvantage of being less flexible, not to mention it spreads out concerns of the visualization layer wider than they need to be. The other option is to do the conversion on the front end. Rather than dive into writing a bespoke method to covert the specific data on hand to a format tailored to the visualization we want, why not take a step back and write a reusable abstraction layer? The end result, without giving too much away, looks roughly like this:

The advantage of this over D3’s built-in nest() method is that it will recursively construct n-depth trees from flat data, as long as the relationships are consistently expressed. This eliminates one of the major time-consumers in creating these visualizations–the data conversion in a reusable and flexible way. But why stop there? We created abstractions for various visualizations as well. Now, creating an icicle graph (like the one above) is as simple as:

This is still in the early stages of development so it’ll be some time before we release it to the public, but stay tuned.

Gist is based on something we call “concrete abstractions”

Most upper level ontologies are based on “abstract abstractions” that is, they are based on philosophical ideas that might be correct but are counter productive to try to convince business people and IT people what they are and what they mean.

We have taken the same posture as Google has with schema.org, most of our classes are classes of “concrete” objects. Watch the video to get an idea what we’re talking about.