-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding semantic content from the prov-o-edit.ttl file #11
Comments
Do we want, or need, to add mappings to child terms of the classes we have mapped, like for example ActivityInfluence? |
All the direct mappings are spelled in terms of a subclass relation. Shouldn't these be equivalences, in order to allow for direct translation from BFO to PROV? E.g. if something is a BFO:role, then it's also a PROV:role. Otherwise, if we just say that a PROV:role is a subclass of BFO:role, and we have a BFO:role and we want to translate it into a PROV class, it's underdetermined whether it's going to be a PROV:role or some other sibling class. |
Do we need to add a mapping for object properties? |
Why do we want to map a BFO:role to some prov entity? Not very clear about the significance of using equivalence class here... I mean, isn't it enough to claim prov:role to be a subclass of BFO:role? |
We currently have a condition added to Agent which says: "An agent is the bearer of some role that is realized in an activity". This is represented with an anonymous node that which could be called "Agent Role". But now I'm remembering that's what "Role" is for. So we could just change these axioms to say: "A (prov) role is realized in an activity" and "An agent is the bearer of a (prov) role". As for other prov terms like "Location", I don't think we want to make this specific to provenance. It is undetermined whether a prov Location is some more specific class of BFO's "Site". Or rather, if you have some site, I'm not sure what else you could know to infer that it's a prov Location .... Could the same be said for "Plan" and "Influence"? I'm not sure. The object properties related to subclasses of "Influence" are a bit confusing. |
We need to add more conditions to get the sufficient conditions needed for equivalence relations. (Also, I don't think CCO will help us here.)
Proposed sufficient conditions:
Some others:
|
@tmprd are you sure CCo won't help with this? Perhaps, say, an activity ends up being just equivalent to a CCO process, and we don't need to have other conditions on it. Similarly with Agent, etc. |
You're right, I'm remembering that Activity doesn't have to be related to provenance (except that it's modeled by PROVO). So I'll remove its condition related to Agent in #14 . There is also this example of protein digestion as an Activity, so that makes me agree that it could be equivalent to BFO process as opposed to CCO Act (which informally is defined as involving an Agent). As for Entity, this makes me doubt its generality:
|
@tmprd The talk of "lifetime" reminds me of BFO:history. In BFO, there is one-to-one correspondence between each material and its history (namely the sum of all the sum of the totality of processes taking place in the spatiotemporal region occupied by it). This one-to-one correspondence is an important step in the strategy of Temporally Qualified Continunats. So if lifetime is something like history and a lifetime is required for a prov:entity, then it seems to me that prov:entity should be a material entity. |
This is a good point we can mention in our analysis. However, I think we definitely want to include information entities. As for Requirement V2, this isn't reflected in the actual ontology and could be interpreted as not a constraint on all entities but just a comment on the usual kind PROV likes to model. So for now we've decided, during the last meeting, to make prov:entity equivalent to a non-spatial region continuant. |
Adding this here from a PR so I can merge it and other stuff and prevent a messy merge conflict for Austin prov:wasEndedBy rdfs:subPropertyOf cco:is_affected_by ;
rdfs:comment "Ending an activity (which is a process) is a way that an entity (which is an Agent) can affect the activity"@en .
prov:wasStartedBy rdfs:subPropertyOf cco:is_affected_by ;
rdfs:comment "Starting an activity (which is a process) is a way that an entity (which is an Agent) can affect the activity"@en .
Originally posted by @giacomodecolle in #20 (comment) |
The original work on the prov-o-edit.ttl file contained more semantic content than the one we currently have on the direct mappings file. We should add more of that content to the direct mappings file in form of axioms. Example:
Activity in the prov-o-edit.ttl file has definition: "An activity is a process that has some participants that acts upon some continuant". This was axiomatized has Activity being subclass of "has participant at all times" some Agent.
First of all I am wondering whether this should be an equivalence rather than a subclass relation. In any case, the direct mappings file only has
prov:Activity rdfs:subClassOf obo:BFO_0000015 . # process
We should add the aforementioned condition. I will add other comments to this thread with other examples I find.
The text was updated successfully, but these errors were encountered: