ProvRecord validate method to assert required attributes

[bruth]

Most of the PROV concepts have at least one attribute required for it to be considered valid. Is there any desire to integrate a method like this?

[bruth]

This could be implemented easily using the JSON Schema document defined in the spec: http://www.w3.org/Submission/2013/SUBM-prov-json-20130424/#validation

[krischer]

I guess this would also be easy to implement programmatically and then it can work on the internal graph structure.

Why is this closed?

[bruth]

I closed it because it is simple enough to do outside of this library, however if it's built-in that would be great as well. Reopened for discussion.

[trungdong]

I think this validation should be optional. It was desired to support both well-formed provenance and scruffy provenance in the W3C Provenance working group (this is an example or these).

A practical example would be:

1. An application asserted a record at time t in a bundle b1.
2. At t + x, after running some code, it then asserted some properties of the record in another bundle b2.

The record in b1 and b2 might not be valid, but when merged will be.

I'm inclined to have the prov package more accommodating than restrictive, unless it breaks some fundamental requirements.

Having said that, I think a function that validates a record or a bundle can be useful in some cases.
@bruth, could you defined exactly what you mean by a valid record?

[bruth]

Validation definitely needs to be optional to support your example. The idea is to simply have a validate method on ProvRecord, ProvBundle, or ProvDocument which, when called on an instance, will raise an exception if the instance is not valid. I think it would complement the cases where you are iteratively building a document and needing/wanting to validate it at the end before you store it or process it further.

[bruth]

could you defined exactly what you mean by a valid record?

I realized I still didn't answer your question. The spec defines which attributes are required and optional. For example, a generation event needs to reference the entity that was generated. However the time is not required. If you have a generation record, it would check whether it defines an entity and if it is available in the same scope (bundle of document).

[bruth]

Using the PROV-JSON schema, the structure can be validated, i.e. whether the attributes are satisfied with the correct types, however there needs to be a second step of ensuring the references are valid (the entity foo exists in the document that the generation event is referencing).