Are prov:wasDerivedFrom and prov:wasGeneratedBy association properties?

[Jake Beal]

Hi, folks:

I ran into a minor contradiction around provenance in the spec today, and have opened an issue on the spec to discuss it: https://github.com/SynBioDex/SBOL-specification/issues/435

The specification is currently contradictory about whether prov:wasDerivedFrom and prov:wasGeneratedBy are association or non-association properties.

• Figure 5 for Identified shows that prov:wasDerivedFrom and prov:wasGeneratedBy are non-association properties with URI values.
• The text writeup of the properties on page 14 and 15 indicates that they are association properties with Identified and prov:Activity objects respectively.
• Figure 27 for prov classes shows that prov:wasDerivedFrom is a non-association property, while prov:wasGeneratedBy is an association property.

We need to decide which it actually is and to fix the specification. This doesn't affect any of the serializations, since it's a URI in every case, but it affects how we choose to handle these properties in libraries and tooling.

I believe that the key question here is whether a prov:wasDerivedFrom can ever point to anything other than an Identified object and if a prov:wasGeneratedBy can ever point to anything other than a prov:Activity.

Based on the usages to date, I believe that the answer may be:

• prov:wasDerivedFrom is a non-association property: it sometimes gets used very broadly, to point to things like vendors and publications.
• prov:wasGeneratedBy is an association property: it has a stricter requirement on machine-interpretability and can only be pointed at prov:Activity

What do others think?

Thanks,

-Jake

[Chris Myers]

Hi Jake,

I agree on your assessment for prov:wasDerivedFrom.

I agree that prov:wasGeneratedBy MUST refer to prov:Activity objects.  However, if by association property you mean that deleting the parent would delete the child.  I disagree.  We are actually generating for the Excel2SBOL project libraries of prov:Activity objects to refer to, so the reference should be non-association (unless I’m missing something here).

Cheers,

Chris

--
You received this message because you are subscribed to the Google Groups "SBOL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbol-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbol-dev/49f113b9-b334-4bef-b035-8df2fc8b5b44n%40googlegroups.com.

[Jake Beal]

Hi, Chris:

Per the spec:

>  Classes can be connected to other classes by association properties, which are represented in UML diagrams as arrows. 

> ... The remaining (non-association) properties of a class are listed below its name.

Thus, association properties are ones that refer to class objects, as opposed to data values.

It's the difference between saying: "prov:wasGeneratedBy is a URI" and "prov:wasGeneratedBy is a URI that points to a prov:Activity"

Thanks,

-Jake

[Chris Myers]

Hi Jake,

Ok, however, you do not know if a URI points to a class object or not unless you can dereference that URI.  The only time you are sure you can dereference is when the object is a child object.  So, the distinction for prov:wasDerivedFrom and prov:wasGeneratedBy is not 100% checkable.  Also, it is not 100% true that prov:wasDerivedFrom does not point to another object.  We sometimes will say a Component wasDerivedFrom another Component.

Cheers,

Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/sbol-dev/f21021a5-0795-4a76-b0dc-d1c3621c74a3n%40googlegroups.com.

[Bryan Bartley]

Hi,

By my interpretation of the formal PROV-O spec, these usage patterns of `wasDerivedFrom` that Jake noted are technically incorrect:

• prov:wasDerivedFrom is a non-association property: it sometimes gets used very broadly, to point to things like vendors and publications.

`wasDerivedFrom` is clearly an association property (with range prov:Entity).  In order to reference things like publications, I think that it would be more appropriate to use something like Dublin core, e.g. dc:bibliographicCitation

Thanks

Bryan

To view this discussion on the web visit https://groups.google.com/d/msgid/sbol-dev/E0A8C145-49F1-466C-B568-B32D3E9F1F37%40colorado.edu.

[Jake Beal]

> So, the distinction for prov:wasDerivedFrom and prov:wasGeneratedBy is not 100% checkable.

That's not a problem. Right now, however, the specification is self-contradictory about whether we should even *try* to check it.

What I'm taking away, however, is that `prov:wasGeneratedBy` should indeed be clarified as being an association property. 

Thanks,

-Jake

[Jake Beal]

Bryan: does this mean that we need to declare that an sbol:Identified is a prov:Entity?

Alternatively, since we are disjoint from prov:Entity, maybe we can just define our own relation?

Thanks,

-Jake

[Bryan Bartley]

Hi Jake,

Bryan: does this mean that we need to declare that an sbol:Identified is a prov:Entity?

I think that might be the formally correct thing to do.  Good news, I don't think it affects our library implementations in any way, because Entity has no properties and is simply used to denote the domain and range of certain prov relationships.  It would basically mean our spec should include a UML diagram that shows that sbol:Identified extends prov:Entity.  Take this all with a grain of salt, as it's just one man's opinion, and could use a sanity check from anybody else familiar with the PROV-O spec.

Thanks

Bryan

To view this discussion on the web visit https://groups.google.com/d/msgid/sbol-dev/023527d5-e715-4ec4-8431-6311be795bb1n%40googlegroups.com.