-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create PROV metadata graph describing operation flow for robot commands #6
Comments
Consider using PROV here |
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 |
This would be particularly useful for ontology annotations for import modules - need to at least know the versionIRI of the source ontology |
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. |
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 |
Ok, but do we only care about the last ROBOT operation, and not chains of operations? |
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.
|
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. |
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 |
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. |
mail list convo: https://lists.w3.org/Archives/Public/semantic-web/2017Nov/0099.html |
This can be used for injecting ontology header axioms in tools such as ROBOT, see ontodev/robot#6 This is also useful for the atomic module proposal see INCATools/ontology-development-kit#50 Unclear if IAO is the best home for this, see information-artifact-ontology#35
OK I managed to make this ticket quite complicated... I retitled it to reflect scope and split out a separate simpler ticket here: #655 |
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.
The text was updated successfully, but these errors were encountered: