Create PROV metadata graph describing operation flow for robot commands

[cmungall]

Example of properties to go in header
https://docs.google.com/spreadsheets/d/1pTdRsCM9terVYS7biAw5mvdNwKBKONa4dro2ry_wCqI/edit#gid=0

It's hard for some ontologies to provide this in the header (e.g. the source is .obo). It would be useful to have an easy feature to bring this in from another file. This may be as trivial as a simple merge operation.

The release process could also provide friendly warnings if some fields (e.g. 'tracker') and not filled in the release version.

[cmungall]

Consider using PROV here

[cmungall]

When ontologies are merged, should be possible to see original IRIs (but in a less hacky way than OWLTools - OBOFoundry/OBOFoundry.github.io#424 )

We really need standard URIs for the properties, as well as for ontology IRIs. Coordinate with ontobee. E.g. things are merged into a named graph e.g..

http://purl.obolibrary.org/obo/cl.owl --> http://purl.obolibrary.org/obo/merged/CL

[cmungall]

This would be particularly useful for ontology annotations for import modules - need to at least know the versionIRI of the source ontology

[jamesaoverton]

Assigning @rctauber. Order of operations is important, so we should probably use an RDF List, but I'm a little worried that will confuse tools.

[cmungall]

Not really in favor of RDF lists. Hard to work with in OWL for one thing. I think we should stick to standards, and PROV is a good standard here. Some thoughts:

https://docs.google.com/document/d/1dchZkhqOCBgZJJ0UVkWON9y9xibXVXkqJFc0ceidbOc/edit

Swe should probably only have minimal info in the header and a seeAlso triple or similar pointing to the PROV graph

[jamesaoverton]

Ok, but do we only care about the last ROBOT operation, and not chains of operations?

[cmungall]

OK, how about something like this we don't necessarily want to enforce people to do everything in one chained command What if for every robot command executed, there was either an optional parameter pointing to a PROV rdf file and/or there is an ontology header pointing to a prov file. The command will 'append' its operation onto the graph, and save it. I don't think this should require changing every Operation class. I think this could be done generically, maybe in the command layer. We'd also need a command to initiate a new PROV graph.

[jamesaoverton]

That Google Doc isn't public.

I'm fine with PROV, I just haven't used it much yet.

I thought the goal was to keep this information in the OWL file. I'd prefer not to use an external file. Maybe we need to specify the use cases. If we don't need a lot of detail, that's fine, but if it's all being done automatically then more detail shouldn't hurt.

I still think it's important to maintain sequence. I'd be happy with a timestamp, so that consumers can sort the operations.

[jamesaoverton]

In the OWL/ZIP issue @cmungall linked to this example of a JSON-LD PROV file: https://github.com/ResearchObject/bagit-ro/blob/master/example1/metadata/provenance/results.prov.jsonld

[cmungall]

doc public now

I think it's definitely generally very useful to have at least prov:wasDerivedFrom for import modules and the results of merges directly in the ontology.

I'm also OK including the full graph but this may be perceived as too much clutter/overhead for a level of detail rarely required. But don't have such strong opinions. In the past we avoided administrative instances in the ontology since it causes HermiT to trigger a slower inference algorithm but don't think that's an issue now.

[cmungall]

mail list convo: https://lists.w3.org/Archives/Public/semantic-web/2017Nov/0099.html

[cmungall]

OK I managed to make this ticket quite complicated...

I retitled it to reflect scope and split out a separate simpler ticket here: #655