bfo-mappings / bfo-mappings

PROV & SSN/SOSA mapped to BFO-ISO, RO, & CCO

PROV - BFO, RO, CCO Mappings

PROV Ontology (PROV-O) is a World Wide Web Consortium (W3C) recommended ontology used to structure data about provenance across a wide variety of domains. Basic Formal Ontology (PROV-O) is a top-level ontology ISO/IEC standard used to structure a wide variety of ontologies, including the Relation Ontology (RO) and the Common Core Ontologies (CCO). To enhance interoperability between these ontologies, their extensions, and data organized by them, this repo includes a set of mappings that were created according to a criteria and methodology which prioritizes structural and semantic principles.

Usage

PROV-BFO

• PROV-BFO Release version here. This contains only the mapped and extended terms from BFO. Use this file in production.

PROV-RO

• PROV-RO Release version here. This contains only the mapped and extended terms from RO. Use this file in production.

PROV-CCO

• PROV-CCO Release version here. This contains only the mapped and extended terms from CCO. Use this file in production.

Development

• Editor's development version here. This file is used only for development, not intended for production. It contains imports of BFO, CCO, RO, each and all canonical example instances from the PROV-O docs to test with. Open this file in Protege to view the mapping in full context of each aligned ontology. Test this file to ensure consistency among the extensions.

Scope

• Every class and object property from PROV-O and its extensions is mapped to some class or object property from BFO, RO, or CCO.

• The mappings use subsumption and equivalence relations either directly with RDFS and OWL, or indirectly with SWRL rules and property chain axioms. Additional SKOS mappings are provided for extra commentary.

• The following PROV namespaces have been (1) mapped in the mapping files, (2) imported in the editors file, and (3) all Turtle-serialized examples from each have been loaded as instances in the editors file for testing:

  • PROV-O Ontology
  • PROV Access and Query Ontology & Examples
  • PROV Data Dictionary Ontology & Examples
  • PROV Linking Across Provenance Bundles Ontology & Examples
  • PROV Inverses Ontology
    • Automated entailment of mappings for inverse object properties is supported by OWL-DL and OWL-QL. For example, prov:wasMemberOf may be automatically inferred as a subproperty of BFO "part of" because prov:hadMember is a subproperty of BFO "has part" and these PROV terms are inverses of each other.
  • PROV Dublin Core http://www.w3.org/ns/prov-dc# Ontology & Examples

• Bonus mappings between BFO and the SOSA (Sensor, Observation, Sample, and Actuator) ontology are possible, due to the SOSA-PROV Mapping.

Methods

Development Dependencies

• The version of each PROV-O, BFO, RO, and CCO file is specified in the owl:imports of the editor's file prov-mappings-edit.ttl.

• The following W3C semantic web technologies are used to represent the mappings and the mapping criteria:

  • RDF version 1.1, 25 February 2014
  • RDF Schema version 1.1, 25 February 2014
  • OWL version 2, 11 December 2012
  • RDF Turtle version 1.1, 25 February 2014
  • SPARQL version 1.1, 21 March 2013
  • SWRL version, 21 May 2004

• The following tools are used to develop and evaluate the mappings:

  • Protégé version 5.6.3
  • ROBOT version 1.9.5
  • HermiT Reasoner version 1.4.5.456
  • GNU Make version 3.81

Development Process

1. A separate RDF Turtle file is created to extend each ontology with a set of mappings.

2. All mappings and ontologies are imported into the editor's file prov-mappings-edit.ttl to help visualize the mappings using Protege.

   • For testing and reasoning, only terms that are used in a mapping are extracted from RO -- plus their logical dependencies using the MIREOT strategy.
   • The list of RO terms to import is generated in the imports folder.
   • The subset of extracted terms is stored locally and is imported into the editor's file.

3. A mapping file adds triples which relate terms from each ontology using the following "mapping" predicates: rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass, and owl:equivalentProperty.

   • SWRL rules and property chain axioms are used to represent more complex, indirect relations.
   • SKOS relations are used for extra commentary.
   • OWL annotation axioms encode each mapping with justifications as rdfs:comment and other SSSOM metadata.

4. SPARQL queries are used for finding "unmapped" classes and object properties, and also "candidate" superproperties. The HermiT reasoner is used to check consistency and materialize inferences for various development tasks.

5. Mappings for each ontology are encoded as separate extensions to maximize compatibility and minimize dependencies for users, following conventions from the PROV-DC (Dublin Core) mapping.

Testing

• All example instances from the PROV-O documentation and its extensions are temporarily imported into the extended ontology. The HermiT reasoner is used to check if the example instance data is consistent with the extended ontology.

• ROBOT runs HermiT and also SPARQL queries for evaluating the mappings. A SPARQL query that formalizes the mapping criteria is executed to check whether any mappings are missing.

• How to run tests automatically:

  • Push commits to this Github repo, and the Makefile tests will be triggered in Github Workflow files

• How to run tests manually:

  • Requirements: GNU Make
  • Run make from the src directory, or make -C src from this directory
  • Alternatively, run the commands defined within the Makefile.

Release

• Release files are indicated with -directmappings prefix in the file names. These are edited and annotated directly, and imported in the Editor's file for development and testing.
• Turtle (.ttl) versions of the release are currently not built automatically in order to ensure precise formatting, but RDF/XML versions could be automatically built from the Turtle versions.

Contributors

Tim Prudhomme, Giacomo De Colle, Austin Liebers, Alec Sculley, Karl Xie, Sydney Cohen, and John Beverley

How to cite

Please cite "Mapping PROV-O to BFO" using the GitHub URL https://github.com/BFO-Mappings/PROV-to-BFO or its Zenodo DOI.

bfo-mappings's Issues

prov: hadActivity

It looks like this should be a relation between an Influence and Activity that "has this activity". We are trying to understand whether this is a parthood relation.

"The optional Activity of an Influence, which used, generated, invalidated, or was the responsibility of some Entity. This property is not used by ActivityInfluence (use prov:activity instead)."

Austin raised the issue that if, say, delegation is a parthood relation, and :hadActivity ranges over two processes that occur one after another, then it seems it doesn't make sense.
Example: I delegate to you to do x. Is the prov:hadActivity property ranging between my Influence of delegating and the process of delegating, or does it range between your Activity of executing it and my Influence of delegating? Only in the first case this would be a parthood relation.

Basically, we need to find some examples of use of :hadActivity in the documentation.

@tmprd @avsculley @SydCo99 @tmprd

SWRL Rules

SWRL Rules go here, for complex mappings that don't work with any other predicates.
Here are the current rules we have. These are explained more with OWL annotations in the actual mapping file.

# atLocation -> occurs in
prov:atLocation(?x, ?y) ^ prov:Activity(?x) -> obo:BFO_0000066(?x, ?y)
prov:atLocation(?x, ?y) ^ prov:InstantaneousEvent(?x) -> obo:BFO_0000066(?x, ?y)
# occurs in -> atLocation
obo:BFO_0000066(?x, ?y) ^ prov:Location(?y) -> prov:atLocation(?x, ?y)

# atLocation -> located in
prov:atLocation(?x, ?y) ^ prov:Entity(?x) -> obo:BFO_0000171(?x, ?y)
prov:atLocation(?x, ?y) ^ prov:Agent(?x) -> obo:BFO_0000171(?x, ?y) 
# located in -> atLocation
obo:BFO_0000171(?x, ?y) ^ prov:Location(?y) -> prov:atLocation(?x, ?y)

# hadRole -> process has participant some prov:Role
prov:hadRole(?x, ?y) ^ obo:BFO_0000015(?x) -> obo:BFO_0000057(?x, ?y)

Requirement VI4 (Agent as Activity). prov is to allow agents to be activities.

"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 a material entity, while Activity is classified as a process.
  • Therefore, we can accommodate this by making Agent a disjoint union of material entity (or continuant) and process.

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

Add Agent participates_in Activity

Right now we just have "has characteristic some role" and "has role some agent role" that gets bfo:realized_in an activity
But based on BFO:realized_in, "a relation between a realizable entity and a process, where there is some material entity that is bearer of the realizable entity and participates in the process, and the realizable entity comes to be realized in the course of the process"

So we should add an extra restriction to agent that says "participates in PROV:Activity"

`prov:hadRole`

IRI: http://www.w3.org/ns/prov#hadRole
Domain: (Association or InstantaneousEvent) and Influence
Range: Role

• prov:Influence, prov:Association, and prov:InstantaneousEvent are classified as an occurrents. See #6 for reasons why and please direct your comments about this to that issue.
• prov:Role is classified as a BFO "role"
• BFO's "bearer of" is used to relate roles to their bearers, but its domain is non-spatial-region continuants.
• Therefore we can't subsume prov:hadRole under BFO "bearer of" (or RO "has role" for similar reasons)

Annotations:

This property has multiple RDFS domains to suit multiple OWL Profiles. See PROV-O OWL Profile.

The optional Role that an Entity assumed in the context of an Activity. For example, :baking prov:used :spoon; prov:qualified [ a prov:Usage; prov:entity :spoon; prov:hadRole roles:mixing_implement ].

So, a spoon doesn't have a prov:Role as a mixing implement, but instead its usage "has that role" (in the PROV sense of this expression, not BFO).

prov:hadRole references the Role (i.e. the function of an entity with respect to an activity), in the context of an instantaneous usage, generation, association, start, and end.

Suggestion: subsume prov:hadRole under BFO's "has participant at some time" which has "process" as its domain and non-spatial region continuant as its range, which includes roles. In the spoon example, that means the spoon's usage has its prov:Role as a participant. edit: this doesn't work because InstantaneousEvent is a "process boundary". This would work with RO's "has participant" because its domain is occurrent.

Alternatively (?) we could try to create some kind of property chain which expands this relationship in the way BFO understands it. I don't think this is doable as long only processes can have participants.

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

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.

prov:Influences: continuants or occurrents?

• The definition of Influence suggests it's some kind of dependent continuant.

"Influence is the capacity of an entity, activity, or agent to have an effect on the character, development, or behavior of another by means of usage, start, end, generation, invalidation, communication, derivation, attribution, association, or delegation."

• However, some subclasses of Influence, such as Generation, are also subclasses of InstantaneousEvent, which in turn we have classified as a process boundary (an Occurrent).

• Other subclasses of Influence, such as Communication and Derivation, could be interpreted as happening over time, so we've tried classified those as a process.

  • But Since process and process boundary are disjoint, that means Influence would need to be a disjoint union of these (either but not both).

• However, one example asserts that an instance of prov:Entity, which we've classified as a continuant, is implied to also be an instance of EntityInfluence, in virtue of being the domain of a prov:entity relation (not to be confused with the prov:Entity class). Again, suggesting that influences are continuants. Here is the example:

:digestedProteinSample1
   a prov:Entity;
   prov:wasDerivedFrom :proteinSample;
   prov:qualifiedDerivation [
      a prov:Derivation;
      prov:hadUsage [
         a prov:Usage;
         prov:entity :Trypsin;
        prov:hadRole :treatmentEnzyme;
      ];
   ];
   prov:entity :proteinSample;
.
:proteinSample a prov:Entity .

Conclusion: There are many confusing aspects of these classifications, but fundamentally to make the alignment consistent with PROVO's example data, we need to split up some subclasses of Influence as either continuant or occurrent but not both. Could Influence be disjoint union between these (maybe, e.g. process boundary and disposition)? Any problems with that?

SKOS Mappings

Some PROV terms have no mappings to BFO or CCO or RO terms, and some mappings almost work except for some edge cases. It would be nice to include our explanations of the close-but-not-quite mappings in the ontology.

In the context of mapping large ontologies, often semi-automatically with statistical matching, SSSOM recommends uses SKOS predicates like broadMatch, narrowMatch, relatedMatch, closeMatch, & exactMatch. Exact matches are transitive. Exact, close, and related matches are symmetric. Broad and narrow matches can be made transitive with broaderTransitive and narrowerTransitive.

I think we can often use skos:broadMatch in place of rdfs:subPropertyOf or rdfs:subClassOf.

Examples:

[]  rdf:type owl:Axiom ;
     owl:annotatedSource   prov:hadRole ;
     owl:annotatedProperty skos:broadMatch ;
     owl:annotatedTarget   obo:BFO_0000057 ;
     sssom:object_label    "has participant (at some time)" ;
     sssom:mapping_justification "If a prov:Influence had role some prov:Role, then this is similar to that prov:Influence having that prov:Role as a participant as a kind of broader relation. However, only processes can have participants, but some prov:Influences are process boundaries, such as prov:Generation, which is a prov:InstantaneousEvent."@en .

[]  rdf:type owl:Axiom ;
     owl:annotatedSource   prov:atLocation ;
     owl:annotatedProperty skos:broadMatch ;
     owl:annotatedTarget   obo:BFO_0000171 ;
     sssom:object_label    "located in at some time" ;
     sssom:mapping_justification "If a prov Activity or Agent or Entity or InstantaneousEvent is at some prov:Location then this is similar to the broader relation of BFO 'located in at some time'. However, only continuants can be located in something, while prov:Activities are occurents. "@en .

[]  rdf:type owl:Axiom ;
     owl:annotatedSource   prov:atLocation ;
     owl:annotatedProperty skos:broadMatch ;
     owl:annotatedTarget   obo:BFO_0000066 ;
     sssom:object_label    "occurs in" ;
     sssom:mapping_justification "If a prov Activity or Agent or Entity or InstantaneousEvent is at some prov:Location then this is similar to the broader relation of BFO 'occurs in'. However, only occurents can occur in something, while prov:Agents and prov:Entities are continuants. "@en .

With the last two I'm not sure if either is broader than the other, so skos:relatedMatch may be more appropriate...

Links:

• Some unmapped terms (others are temporarily commented out here)
• https://www.w3.org/TR/skos-primer/#secmapping
• https://www.w3.org/TR/skos-reference/#mapping
• http://www.w3.org/TR/skos-reference/skos.rdf