Correct migration scripts for inverse properties

[rjyounes]

Applies to both v13 and v14 migration scripts: they do not handle use of the properties in OWL restrictions. For example:

[
    a owl:Restriction ;
    owl:onProperty gist:hasPart ;
    owl:someValuesFrom ex:myClass ;
]

Has to be changed to:

[
    a owl:Restriction ;
    owl:onProperty [ owl:inverseOf gist:isPartOf ] ;
    owl:someValuesFrom ex:myClass ;
]

@Jamie-SA Do you know whether we are attempting to cover this case? If not we should at least warn users that our scripts will produce the wrong result in these cases.

[rjyounes]

This may warrant a patch release if we can fix it. Can also include #1139.

[Jamie-SA]

It looks like the query for the inverse properties is only a reporting property so they don't actually make any changes. However, there are comments in the query about how to do an update, and yes, as you mention the comments do not address OWL restrictions correctly.

[rjyounes]

All the v13 migration queries have been written as SELECTs, with DELETE/INSERT commented out, presumably to be commented in once the user is satisfied with the results. The v12 inverse migrations are in the actions directory and do the updates.

[philblackwood]

I think this scenario applies mainly to an ontology, which is typically maintained as a file outside the graph and then reloaded whenever the ontology file is modified.

For example, e.g. gist is maintained in gitHub; conversion scripts should not modify it directly in the graph.

Let's update the documentation instead of the queries.

In migration/v13.0/README.md we could add a statement in the "Important Notes" section stating:

If you have used gist:hasPart in a restriction within an ontology, change the restriction to use the inverse of gist:isPartOf as follows:

          owl:onProperty   gist:hasPart 

          should be changed to

          owl:onProperty [owl:inverseOf gist:isPartOf] 

Similarly,

           owl:onProperty gist:hasMember

           should be changed to

           owl:onProperty [owl:inverseOf gist:isMemberOf]

[rjyounes]

DECISION: Add notes to README about manual, file-based steps to update ontologies, taxonomies, data mapping scripts (e.g., TARQL, R2RML, Python), SHACL, and queries.

• Update restrictions with owl:inverseOf
• Update domains and ranges
• Update subproperty assertions

Ontology migration requires manual effort by nature - can't be fully automated. Decisions need to be made about what to do in each case.

Also add to v12 migration README and docs/MajorVersionMigration.md.

[philblackwood]

Going forward, I think we should be able to provide migration scripts to update rdf files with changes that replace a property with its inverse. We don't need to do it for the scripts that update a graph, only the ones that update rdf files.

query: # updates owl:onProperty statements when a property is being deprecated in favor of its inverse # covers the case when the old property is the object of owl:onProperty

# replaces a triple using owl:onProperty with an equivalent statement using the inverse of the object

# preview of new triples construct {?s owl:onProperty [ owl:inverseOf ?inverse ] . }

# update graph # delete { ?s owl:onProperty ?oldProperty . } # insert { ?s owl:onProperty [ owl:inverseOf ?inverse ] . }

where {

# input
values (?oldProperty ?inverse) { (gist:hasPart gist:isPartOf) (gist:hasMember gist:isMemberOf) }

?s owl:onProperty ?oldProperty . }

=========== next query ============ cover the case when the object of owl:onProperty is of the form [ owl:inverse ?oldProperty ]

=========== next ============= should be able to also automate changes to subproperties (the user would need to supply the name of the inverse of the subproperty) Domains and ranges of the subproperty need to be flipped.

[uscholdm]

It might help to make the following more clear.

When updating an ontology that is maintained under source control such as git, it you may find the SPARQL for updating restrictions to be more useful as a specification of what needs to be done rather than a query that you will run on the ontology loaded into a triple store. Why? You would have to know exactly what triples to export from the triple store to as the ontology in an owl file and then make sure it is easily compared with the last version of the ontology under source control. This is doable but may not be as convenient.

[philblackwood]

@uscholdm the proposal is to have the changes done on rdf text files (called local changes in the migration documentation), which I think onto-tools can do.

The script I provided works on Allegrograph, but would need to be tested with onto-tools. My understanding is that onto-tools will update text files, so there is no need for the user to load an ontology or SHACL script into a graph for the changes to be applied to it.

@sa-bpelakh perhaps you can confirm that onto-tools will update rdf text files (ontologies, SHACL, form definitions, etc.).

Also, we did a lot of gist changes related to inverses recently. Are there many users who have still not updated their data? If so, perhaps worth pursuing. If not, perhaps low priority to automate the changes.

[uscholdm]

Also, we did a lot of gist changes related to inverses recently. Are there many users who have still not updated their data? If so, perhaps worth pursuing. If not, perhaps low priority to automate the changes.

I would love to know how to do this - we are currently making these updates to a client ontology. It will be faster at the moment to do it manually, but better in the long term to automate it, especially for collections of importing ontologies.