Explicitly assert subClassOf in gist where applicable

[marksem]

Request: Explicitly assert subClassOf in gist where applicable.

Example: gist:Commitment is defined as

  (Requirement or Restriction)
 and (hasGiver some 
    (Organization or Person))
 and (isCategorizedBy some DegreeOfCommitment)

but it is not explicitly defined as subClassOf gist:Intention, even though it must be.
Another example is gist:CoherentUnit (not explicitly declared as subClassOf gist:UnitOfMeasure)

Rationale: We want gist to be as usable as possible. Many more triple stores and visualization tools support class subsumption but do not support OWL to the level where they can "figure out" the subsumption if implied.

[uscholdm]

There are two levels of inference here, to get all of this sort of thing may require going all the way up the sublass hierarchy for all classes. I hope not, but how are you going to get only what you want?

[justin2004]

An option is to run an OWL 2 DL reasoner on gistCore.ttl when we package up a release and make a .ttl file available in the release with all the triples ingistCore.ttl + all of the derivations.

If there is interest in that I can take a crack at it (so it can run it a hands-off manner).

[uscholdm]

A good idea - we might want to have a separate file of just materialized triples, so they can be swapped in a KG more easiliy.

[rjyounes]

Other contexts where this would be helpful: SHACL with RDFS reasoning turned on (turning on OWL reasoning to interpret the intersections results in an untenably large performance hit), RDFox.

IMO the best way to handle this is to add a function to onto_tool to generate the triples and add to a separate file. Rather than just generating it in a release package, it would be helpful to have in the repo for development purposes. The easiest way to manage that is by adding it to the pre-commit hook.

[dylan-sa]

Using onto_tool to generate the subClassOf assertions may still be the best option, but I stumbled upon this feature of ROBOT and thought I'd link it here just in case it's useful.

[rjyounes]

That's very interesting, thanks for pointing it out. It's important to consolidate into onto_tool for the bundling, but we may be able to call this ROBOT function from onto_tool by making appropriate additions to bundle.yaml - see the definition of the serializer tool and the transform action.

Another approach would be to do everything in bundle.yaml itself using a sparql action - see the sparql action for generating rdfs:labels into a new file. This could be done without running a reasoner by querying for an intersection and selecting only non-blank nodes. This would not require a change to onto_tool as my previous suggestion did.

The pre-commit hook could call ROBOT directly or go through onto_tool.

@justin2004 You may want to consider these alternatives to modifying onto_tool itself.

[rjyounes]

@dylan-sa and I are working on this for a client, so we can take this one on too. We'll start with a stand-alone script, then looking into adding to onto_tool.