Requirement VI4 (Agent as Activity). prov is to allow agents to be activities.
Closed this issue · 4 comments
"The rationale of PROV" states:
Requirement GE1 Class Disjointness: prov is to minimize class disjointness constraints and to use strong rationale when defining such constraints.
Requirement GE2 Mirror: prov is to include the mirror of each concept, where relevant.
Surprisingly, a consequence of Requirement GE1 and Requirement GE2 is that there was no obvious rationale to disallow agents from being activities.
Requirement VI4 Agent as Activity: prov is to allow agents to be activities.
As a result, being an agent is not an intrinsic characteristic of an entity or activity. Instead, it is the very presence of responsibility relations that implies that some entities or activities are also agents.
-
Proposed solution:
- Currently
Agent
is classified as amaterial entity
, whileActivity
is classified as aprocess
. - Therefore, we can accommodate this by making
Agent
a disjoint union ofmaterial entity
(orcontinuant
) andprocess
.
- Currently
-
Comments:
- It's worth noting that there are no example instances of agents asserted or implied to be activities or vice versa.
- It's included as a possibility but it doesn't follow from anything else in the "rationale" or the documentation that it's necessary.
The possibility of Activities that are Agents conflicts with the axiom we added about agent roles, represented here with an anonymous node:
# Other property restrictions
prov:Agent rdfs:subClassOf [ rdf:type owl:Restriction ;
owl:onProperty obo:RO_0000087 ; # has role
owl:someValuesFrom [ # anonymous "agent role"
a owl:Class ;
owl:intersectionOf (
obo:BFO_0000023 # role
[
a owl:Restriction ;
owl:onProperty obo:BFO_0000054 ; # has realization
owl:someValuesFrom prov:Activity ;
]
)
] ;
] ;
rdfs:comment "An agent is something that plays a role, that, if realized, is realized in an activity taking place"@en .
I don't fully understand why, but this contradicts many of the PROVO examples - here's one withe the role axiom simplified:
Fixed by restricting the role axiom to material entity versions of Agents
We are reconsidering this, since it seems to go against the spirit of BFO. If we remove Activity
as a possible Agent
, Sydney suggested offering a reminder (in our documentation/explanation) to users how to translate their "activity-agents" into agents which are related to their activites.
The article says there was no "obvious rationale" for disjointedness, but this is a failure on their part.
It seems one could provide two mappings. One that preserves the spirit of PROV and cobble the relevant disjunctions (Mat Entity or Process), and another mapping that gives the rationale that they were missing and simply fix it.
In other words, if you give the rationale, then give cases where they would have need to thinkin two faces/"mirrors" (output of one process, input of next process; termination of entity, creation of entity; etc.) and then show that it works with disjointness axioms AND show how some clear documented use cases for legitimate inferences are allowed on one model and cannot-be-soundly-inferred on the other model.
Two mappings could have different annotations, to easily modularize the two strategies.