-
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
SKOS Mappings #22
Comments
We're going to try a SWRL rule for ("occurs in" OR "located in") => |
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. |
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) |
A
This suggest that 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 |
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
<#22 (comment)>,
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:
The text was updated successfully, but these errors were encountered: