BFO-Mappings / PROV-to-BFO

PROV & SSN/SOSA mapped to BFO-ISO, RO, & CCO
Creative Commons Zero v1.0 Universal
8 stars 4 forks source link

SKOS Mappings #22

Open tmprd opened 9 months ago

tmprd commented 9 months ago

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:

tmprd commented 9 months ago

We're going to try a SWRL rule for ("occurs in" OR "located in") => prov:atLocation

tmprd commented 9 months ago

We're going to try a SWRL rule for ("occurs in" OR "located in") => prov:atLocation

This doesn't work as a rule or even just subproperty axioms.

Adding these axioms means:

But something could occur or be located in something that isn't a site, because the range of "occurs in" and "is located in" includes material entities.

tmprd commented 9 months ago

These work:

# 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)
tmprd commented 8 months ago

prov:describesService (from PROV-AQ) has no domain or range, but is commented:

relates a generic provenance query service resource (type prov:ServiceDescription) to a specific query service description (e.g. a prov:DirectQueryService or a sd:Service).

A prov:ServiceDescription is a prov:SoftwareAgent, and it's defined:

Type for a generic provenance query service. Mainly for use in RDF provenance query service descriptions, to facilitate discovery in linked data environments.

This suggest that prov:ServiceDescription is ambiguous and can either be interpreted as an agent or information. We can say it has a skos:relatedMatch to cco:is_about or cco:describes.

The way to represent this in CCO is something like this invalid SWRL rule:

# A ServiceDescription is a carrier of some Information Content Entity which is about some (BFO) Entity
prov:describesService(?a, ?c) -> obo:BFO_0000101(?a, ?b) ^ cco:InformationContentEntity(?b) ^ cco:is_about(?b, ?c) ^ obo:BFO_0000001(?c)
tmprd commented 7 months ago

prov:Person and cco:Person could be relatedMatch or closeMatch because prov:Person is a subclass of prov:Agent, while cco:Person is not a subclass of cco:Agent.

jonathanvajda commented 7 months ago

Good point. I'll add some:

cco:Person will be a cco:Agent whenever that cco:Person is agent_in some process, I believe.

But also many prov:Person will never be cco:Agent, because the prov:Person in question is fictional. So, 'Harry Potter' will never be agent_in some 'Act of Communication' that occurs_at some theater facility; he will only be represented as doing activities (all fictional events are relegated to "information land").

All the best, Jonathan Vajda /dʒɒnɑθɑn vaɪdɑ/

On Fri, Nov 24, 2023 at 11:54 AM Tim Prudhomme @.***> wrote:

prov:Person and cco:Person could be relatedMatch or closeMatch because prov:Person is a subclass of prov:Agent, while cco:Person is not a subclass of cco:Agent.

— Reply to this email directly, view it on GitHub https://github.com/BFO-Mappings/BFO-Mappings/issues/22#issuecomment-1825917507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIW242CRFZPCDB4EBQV5NILYGDGOBAVCNFSM6AAAAAA5XE3DNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRVHEYTONJQG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>