-
Notifications
You must be signed in to change notification settings - Fork 2
Description
It is strange that ORE defines ore:lineage as a very specific kind of provenance of an aggregation.
While I think it is important that we specify the meaning of provenance of proxies - such as its creator means who added the resource to the aggregation - I think ore:lineage should be hidden a bit more as it is just one particular form of provenance:
ore:lineage is, thus, a relationship between two Proxy objects, both of which MUST have the same Resource for which they are proxies. The meaning is that the Resource for which the subject of the relationship is a Proxy was discovered in the Aggregation in which the object Proxy's resource is aggregated.
There are many other reasons behind a proxy being related to a different proxy, for instance membership of a more generic aggregation (managers of a company) is implied by membership in a specific aggregation (executive managers) - expressed using prov:specializationOf or prov:wasDerivedFrom
{ "@id": "http://example.com/executives/member3",
"@type": "Proxy",
"proxyIn": "http://example.com/executives/",
"prov:specializationOf" {
"@id": "http://example.com/managers/member5",
"proxyIn": "http://example.com/managers/"
}
}Or a membership was attributed to someone adding them to the collection:
{ "@id": "http://example.com/executives/member3",
"@type": "Proxy",
"proxyIn": "http://example.com/executives/",
"prov:wasAttributedTo" {
"foaf:name": "Stian"
}
}(Here you might want to use pav:createdBy to indicate the secretary who technically created the ORE membership, and pav:authoredBy to the director who authorized the new executive member. - but let's not get carried away!)
What I am trying to say is that ore:lineage is defined very specifically to "was discovered in another aggregation", and there are many other forms of provenance of a proxy (e.g. of a membership of an aggregation), and therefore we should downplay it, perhaps both here and in the ORE Vocabulary.