Adding semantic content from the prov-o-edit.ttl file

[giacomodecolle]

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.

[giacomodecolle]

Do we want, or need, to add mappings to child terms of the classes we have mapped, like for example ActivityInfluence?

[giacomodecolle]

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.

[giacomodecolle]

Do we need to add a mapping for object properties?

[peihongx]

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.

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?

[tmprd]

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.

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.

[tmprd]

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.) Current necessary conditions:

• Activity: If something is a provenance Activity, then it's a process that has a participant at all times some provenance Agent.
• Agent: If something is a provenance Agent, then it's a material entity that participates at some time in some provenance Activity and bears a role that's realized in some provenance Activity.
• Entity: If something is a provenance Entity, then it's a non-spatial-region continuant.

Proposed sufficient conditions:

• Agent: If something is a material entity and participates at some time in some provenance Activity, AND bears a role that's realized in some Activity, then it's a provenance Agent.

  • This seems right

• Activity: If something is a process and has a participant at all times some Agent, then it's a provenance Activity.

  • Counterexample: The author of a book runs 10 meters but their running isn't a provenance Activity.
  • Suggestion: the process should involve a relation to something classified as a provenance Entity. I don't know how to represent this in a nice way, other than enumerating all object properties with Entity in the domain or range.

• Entity: If something is a non-spatial-region continuant and _____ then it's a provenance Entity.

  • Counterexample: More obviously lacking conditions... ex. a rock on Mt Everest.
  • Suggestion: same as above, the thing should be either generated or invalidated or the alternateOf or influencedBy or have a qualifiedInfluence from something. I'm remembering now that this will cover Plan too as a subclass.

Some others:

• Influence
  • Generation: Something is a Generation if and only if it's a process that has participant at some time something that wasGeneratedBy something.
  • Counterexample: A data analyst deleting a CSV file.
  • Suggestion: The thing needs to not exist prior to the generation. This might get too complicated.

[giacomodecolle]

@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.

[tmprd]

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:

"Requirement EV2 (Entity Lifetime). prov is to model entities as things that have a lifetime delimited by the entity’s generation and invalidation."

[peihongx]

"Requirement EV2 (Entity Lifetime). prov is to model entities as things that have a lifetime delimited by the entity’s generation and invalidation."

@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.

[tmprd]

"Requirement EV2 (Entity Lifetime). prov is to model entities as things that have a lifetime delimited by the entity’s generation and invalidation."

@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.

[tmprd]

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 .

Seems like they are both is_affected_by with extra conditions: in one case, one of the two processes has first instant the same instant in which the starting activity takes place. In the other, one of the two processes has last instant the same instant in which the activity takes place. These are both CCO relations

_Originally posted by @giacomodecolle in https://github.com/BFO-Mappings/BFO-Mappings/pull/20#discussion_r1349243621_