ontodev / robot

ROBOT is an OBO Tool
http://robot.obolibrary.org
BSD 3-Clause "New" or "Revised" License
261 stars 74 forks source link

support for quads #238

Open wdduncan opened 6 years ago

wdduncan commented 6 years ago

Can you add support for ontologies with named graphs (e.g., TriG files)?

e.g., robot reason --input data.trig

jamesaoverton commented 6 years ago

As you know, OWL is focused on triples and does not support quads. If ROBOT were to support TriG, we'd have to figure out the appropriate behaviour.

What would you expect robot reason --input data.trig to do?

cmungall commented 6 years ago

I'm not sure how good the OWLAPI support is.

Looking in my inbox I sent an email to owlapi-developer on April 14 2017 but looks like the email did not go through. Maybe we should file an owlapi ticket? This was the content:

Is there a formal mapping from OWL to Trig?

It seems that desirable behavior in using the OWLAPI to write Trig might be to write an entire import chain into a single Trig document, with each ontology in its own named graph.

However, the current behavior seems to be to create a blank node graph for each collections of axioms about an OWL entity. This is based on empirical observation, I'm not sure if this is documented anywhere.

The W3 spec maps individual ontologies to RDF graphs https://www.w3.org/TR/owl2-mapping-to-rdf/

But is silent on things such as what the name for the graph is.

wdduncan commented 6 years ago

Perhaps describing my use case will help ...

I am integrating data (stored in a relational database) from 99 dental practices into a triple store. In the triple store, each practice in a separate graph. This allows us to more easily analyze a single practices data or compare across practices.

For each practice, The translation process produces 43 separate TriG files ( a file for patient demographics, a file for fillings, a file for crowns, etc.). It would be helpful to be able to:

  1. merge all the TriG files for a single practice into a single file
  2. merge files from multiple practices into a single file
  3. convert TriG file into a turtle file
  4. run reasoner on a TriG file
jamesaoverton commented 6 years ago

Thanks for the details. Do these TriG files contain OWL logical axioms? In other words, are they TBox/ontologies or ABox/data?

If you don't need OWL features then rapper or riot will be faster and more efficient than OWLAPI/ROBOT. They should be able to merge TriG files (your 1 and 2).

For 3 do you want to put all the triples into a single graph? That should also be possible with rapper or riot.

I still don't understand the behaviour you want for 4. Do you want to: reason over one graph (the default graph?); reason over each named graph separately; treat all triples as belonging to the same graph, then reason over them all? Something else? If you want to reason over all the triples together, then you could merge to Turtle using rapper or riot and then run ROBOT.

cmungall commented 6 years ago

Yes, robot is best as an ontology (TBox) release tool

You may be interested in @balhoff's https://github.com/balhoff/blazegraph-runner

even if not using BG, the patterns may apply

I also attempted to put together a proposal for how triplestores of multiple graphs each with potentially separate reasoning requirements should be named and annotated, comments welcome: https://docs.google.com/document/d/1sQnNoCmneLjZPsUc6iBgbEkuqhxihFn09u9RrpHcUc8/edit

balhoff commented 6 years ago

You may be interested in @balhoff's https://github.com/balhoff/blazegraph-runner

Which is remarkably undocumented... but I think what @cmungall is thinking of is that given a tbox ontology, it can apply reasoning (using arachne) separately to each graph in the database and then store the inferences in another graph for each input, using a naming pattern.

wdduncan commented 6 years ago

Thanks for link to the tools. I was not aware of them.

To answer James: The individual practices data is ABox. E.g. (in pseudo syntax):

graph :practice 1 
{
  :patient#1 a :Patient .
  :tooth#5 a :Tooth; :part_of :patient#1 .
  :amalgam#1 a :Amalgam; :part_of #tooth_1 .
}

We load the practice ABox data into our GraphDB instance, and then we load Oral Health and Disease ontology (TBox) into the triple store. The ontology has rules such as:

:Restored_Tooth equivalent_to :Tooth and :has_part some :Amalgam 

So, in the above example, tooth#1 is inferred to be a restored tooth. We can then run queries for all restored teeth.

This is what I meant by using the reasoner on TriG files. Does that help?

jamesaoverton commented 6 years ago

I see. ROBOT is focused on TBox stuff, just like OWLAPI and Protege. Most people use triplestores with inference for ABox stuff. If we changed ROBOT to reason over each graph in a TriG file, I think you would still want to load the results into a triplestore.

Both this issue and #237 are about processing sets of files with ROBOT. Most of us are using make for this kind of job. This example from OBI's Makefile defines one ROBOT template command and runs it on seven different files (only when they need to be updated): https://github.com/obi-ontology/obi/blob/master/Makefile#L67. A few lines earlier there's an example of a wildcard that we use for OntoFox inputs: https://github.com/obi-ontology/obi/blob/master/Makefile#L61. You could do something similar to run a ROBOT reasoning command on each Turtle file in your set, then load the results into a triplestore. So #237 and #238 are already possible with the right combination of tricks -- not easy but possible.

I'm fine with working toward TriG support in ROBOT if we can be completely clear about what the feature is supposed to do. We've been talking about the reason command, but there are about 16 other commands that also need to be considered. Chris' linked document is a step toward that.

wdduncan commented 6 years ago

Ok ... I'm not sure what other commands would be of interest. My immediate needs were merging and reasoning with TriG files.

jamesaoverton commented 6 years ago

I'm going to label this as "enhancement". It would be nice to have, but we need to get clear on some big picture stuff.