Some Provenance Notes

notes.txt

@chrpr:

* We need field-instance level provenance for properties in an RDF model. 
* We want to manage access controls based on this.
* This would allow us to have, for example, a batch-loaded dcterms:subject that is not editable, and have it co-exist on the same record with a manually created & fully editable dcterms:subject.
* I feel there should be a way to do this with activetriples, but in reviewing the repo & the gist, I'm not sure what would be best.
* I was considering an OAC inspired design, but don't like how that spec handles structured data in an annotation body (they basically say to record a bunch of extra serialized RDF as if it's a literal as the object of the oac:body tag...)
* I know this is possible with PROV-O, but figuring out how is proving painful.
* I thought about named graphs a bit, and am concerned about the number of different combinations we'd need & the complexity of the underlying graphs.


----


@no_reply:

* Do you need field-instance level provenance, or workflow/event-driven provenance?
* What are the provenance operations you need to support?
  * Audit/Verification -- Given a statement, identify which agent or agents have made the assertion.
  * Forward Tracing -- Given an agent, identify statements it is responsible for.
  * Recomputation -- Reverse changes associated with an event/source/etc... and propagate the updated data.
  * Others?
* What are the advantages of the PROV-O only or OAC approaches, other than that they seem less daunting than doing named graphs without tool support?
* If the named graph approach is best, what are the patterns you would need to support?  What should ActiveTriples support explicitly?