| SEP | |
|---|---|
| Title | Any cardinality for Identified.wasDerivedFrom |
| Authors | Jacob Beal ([email protected]) |
| Editor | |
| Type | Data Model |
| SBOL Version | 2.1 |
| Replaces | n/a |
| Status | Accepted |
| Created | 14-Dec-2016 |
| Last modified | First submission |
| Issue | #27 |
We have imported the Identified.wasDerivedFrom relation directly from the PROV-O provenance ontology (https://www.w3.org/TR/prov-o/) There, it has cardinality 0..n, but we allow it only 0..1. This SEP generalizes its usage in SBOL to 0..n as well.
There are two motivations for this change:
- New data objects are often created as a merger of two existing data objects. Allowing multiple wasDerivedFrom relations allows this to be expressed.
- It is unusual that we restrict the usage of a relation that we are importing, and likely goes against its original sense and developed use cases. We shouldn’t do this unless we have a good reason, which we do not seem to have had.
Change cardinality of Identified.wasDerivedFrom from 0..1 to 0..n
In addition to changing the prose description, rule sbol-10208 will need to change to allow a set.
Consider merging several poorly curated SBOL databases in order to create a new database with improved curation. Part X is found, with different annotations, in more than one of the source databases. When it is imported into the new curated database, it is marked with a wasDerivedFrom indicating all of its sources.
As this expands cardinality, all prior SBOL files remain valid.
New SBOL files with multiple wasDerivedFrom relations, however, will not be able to be consumed by older version, as they will trigger sbol-10208.
None.
None.
To the extent possible under law,
SBOL developers
has waived all copyright and related or neighboring rights to
SEP 012.
This work is published from:
United States.