Open tmprd opened 9 months ago
We're going to try a SWRL rule for ("occurs in" OR "located in") => prov:atLocation
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.
atLocation
domain is Activity or Agent or Entity or InstantaneousEvent
Activity
is equivalent to process
and InstantaneousEvent
is equivalent to process boundary
Entity
is a subclass of non-spatial region continuantatLocation
range is Location
Location
is equivalent to site
Adding these axioms means:
prov:Activity
or prov:InstantaneousEvent
and B must be a "site".prov:Agent
or prov:Entity
and D must be a "site".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.
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)
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)
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.
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: @.***>
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 withbroaderTransitive
andnarrowerTransitive
.I think we can often use
skos:broadMatch
in place ofrdfs:subPropertyOf
orrdfs:subClassOf
.Examples:
With the last two I'm not sure if either is broader than the other, so
skos:relatedMatch
may be more appropriate...Links: