Add generically depends on and inverse generic bearer of #233

msinclair2 · 2018-06-25T19:50:20Z

@msinclair2

Adding id range for @msinclair2 See #233

cmungall · 2018-06-25T21:48:45Z

Apologies, I should have pointed you at https://github.com/oborel/obo-relations/blob/master/src/ontology/README-editors.md - the file to edit is ro-edit

Also I assigned you an ID range start with RO_0010001

msinclair2 · 2018-06-25T22:46:26Z

I reverted the ro.owl to the original and added the relations to ro-edit.owl using RO_0010001 and RO_0010002 for generically depends on and generic bearer of respectively. I removed unnecessary Intellij files (.idea folder and the xml catalog) because I originally cloned it using IntelliJ. I then amended the commit and force pushed it. It's failing Travis, however, and I'm not sure why.

didn't check travis

cmungall

Travis/ROBOT is reporting that the ObjectProperty is unsatisfiable, ie equivalent to bottomObjectProperty

LMK if you need help checking this in Protege - you may need to select some defaults, or try creating a statement using the OP. Most likely domain/range errors

msinclair2 · 2018-06-26T00:15:15Z

I removed domains and ranges from the object properties. You're going to have to handle them manually I guess.

Originally, I had:
generically depends on
domain: generically dependent continuant
range: independent continuant

generic bearer of
domain: independent continuant
range: generically dependent continuant

with generic bearer of and generically depends on inverses of each other

I guess that caused a conflict as I put them under bearer of and depends on respectively.

jamesaoverton · 2018-06-26T13:37:02Z

This might be better in RO Core.

cmungall · 2018-06-26T15:21:44Z

@msinclair2 - were you able to obtain a Protege explanation as to where the unsatisfiability arose?

@jamesaoverton - yes, my mistake. I can transfer the axioms rather than having @msinclair2 do the work again

msinclair2 · 2018-06-26T17:58:24Z

The problem is ‘bearer of’. That entire tree disappears when reasoned even without any of my additions. From: Chris Mungall <notifications@github.com> Sent: Tuesday, June 26, 2018 9:22 AM To: oborel/obo-relations <obo-relations@noreply.github.com> Cc: Michael Sinclair <Michael.Sinclair@utah.edu>; Mention <mention@noreply.github.com> Subject: Re: [oborel/obo-relations] Add generically depends on and inverse generic bearer of (#233) @msinclair2<https://github.com/msinclair2> - were you able to obtain a Protege explanation as to where the unsatisfiability arose? @jamesaoverton<https://github.com/jamesaoverton> - yes, my mistake. I can transfer the axioms rather than having @msinclair2<https://github.com/msinclair2> do the work again — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#233 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ATWldj10xMC8urht9Eh67L-yRXbVpNsrks5uAlGNgaJpZM4U2wE_>.

msinclair2 · 2018-07-12T21:37:49Z

Sorry it took me so long to get back to this.

I found out the problem. I made the "generic bearer of" with a range of "generically dependent continuant" as a sub-property of "bearer of" which has a range of "specifically dependent continuant". The disjoint-ness between GDC and SDC in the ranges was what was unsatisfiable.

How would you like to resolve this? I notice most properties in RO don't have domains and ranges specified, so we could just leave them out which the current pull request does.

cmungall · 2018-07-13T15:33:05Z

If you see any missing domain/range constraints can you add a ticket? We want these to be complete. Remember we don't assert what can be inferred. Also some like part_of are deliberately loose and follow a homeomorphism patterns for constraints, e.g. C part-of only C.

In this case leaving out the D/R is not a good solution, we're just hiding the inconsistency.

According to BFO, GBO can't be a subproperty of BO. IMO this is terminologically confusing, names should follow certain principles, but that's consistent with BFO (although I think the references is worded confusingly)

3.7.1	The inheres_in and bearer_of relations
DEFINITION: b inheres_in c at t =Def. b is a dependent continuant & c is an independent continuant that is not a spatial region & b s-depends_on c at t. [051-002]
DOMAIN: specifically dependent continuant 
RANGE: independent continuant that is not a spatial region

The definition makes it sounds like the domain is broader than it actually is.

BFO does not explicitly name a relation that could group BO and GBO

You might want to open something on the BFO tracker for clarification

msinclair2 · 2018-07-13T23:56:54Z

According to BFO, GBO can't be a subproperty of BO. IMO this is terminologically confusing, names should follow certain principles, but that's consistent with BFO (although I think the references is worded confusingly)

3.7.1 The inheres_in and bearer_of relations
DEFINITION: b inheres_in c at t =Def. b is a dependent continuant & c is an independent continuant that is not a spatial region & b s-depends_on c at t. [051-002]
DOMAIN: specifically dependent continuant
RANGE: independent continuant that is not a spatial region
The definition makes it sounds like the domain is broader than it actually is.

BFO does not explicitly name a relation that could group BO and GBO

You might want to open something on the BFO tracker for clarification

Is there a reason that on p. 25 of the BFO specification it says that GDCs can s-depend_on an IC:

The entities that s-depends_on something include
 specifically and generically dependent continuants, which s-depends_on in every case on one or
more independent continuants which are their bearers, and which may in addition stand in s-depends_on
relations among themselves;

Since the definition for inheres_in only specifies "dependent continuant", there is no logical exclusion of GDCs except by fiat in the domain, it seems to me.

There is also no mention of "generic_bearer_of". I just assumed there would be, so it looks like I made that up. Although, since there is a definition of g-depends_on [072-002], logically there must be an inverse.

My feeling is that we should drop "generic bearer of" until the BFO team decides to add this into the specification, and we'll just add generically_depends_on for now, which is all that currently exists in the spec.

The specification also does not have an equivalent to "inheres_in" for g-depends_on which excludes spatial regions.

Also why is RO_0002502 labeled "depends on" when it should be "specifically depends on"? The specification does not declare a "depends on" relation of which "specifically depends on" and "generically depends on" are children. Should there be? If not, I'll relabel "depends on" to "specifically depends on" and place "generically depends on" at the root.

As an aside, we are correct that concretization is NOT an intermediate for generic dependence, because the definition requires both specific dependence of the quality and generic dependence of the GDC in the same IC in parallel [075-002].

msinclair2 · 2018-07-20T23:15:08Z

Hi Chris,

I removed "generic bearer of", moved "generically depends on" to the root of the object properties, specified domains and ranges and annotations appropriately taken from the specifications.

Travis build is passing.

Please consider this my final commit for the pull request and consider a merge to finally incorporate generically depends on in RO.

Thanks,
Michael

cmungall · 2018-07-26T03:53:20Z

apologies for not getting to this - looks good, @dosumis @balhoff @jamesaoverton can you give a quick look over?

cmungall · 2018-07-26T16:22:46Z

I think we also need a property chain (or SWRL rule)

msinclair2 · 2018-08-06T20:46:43Z

I'm bumping this. What kind of property chain are you suggesting? (is_concretized_by some (inheres_in some IC)) to represent g-depends_on as a "shortcut"?

I wonder if this is what is holding up the merge?

Thank you.

cmungall · 2018-08-25T01:19:30Z

Looks like we have conflicts

Property chain: do we not want to infer GBO if BO and CB is asserted?

msinclair2 · 2018-08-25T07:25:52Z

What conflicts do you see? Travis/ROBOT build is passing and this pull request is only adding a single object property in the ID range you assigned me and which does not conflict with any other property and is logically satisfiable. So I wonder why it can't be merged?

Question: What does "CB" stand for?

As for generic bearer of, I removed it because it is not in the BFO specification, though I think it should be. There are issues with adding the inverse right now, due to the current BFO spec, as follows:

s-depends_on can depend on any independent continuant, including spatial boundaries.

The subproperty of s-depends_on is 'inheres in', which excludes spatial boundaries from s-depends_on.

The inverse of 'inheres in' is 'bearer of', which is an independent continuant excluding spatial boundaries on which a specifically dependent continuant depends.

When it comes to g-depends_on, there are no equivalents to 'inheres in' and 'bearer of' in the restricted sense of not depending on a spatial boundary, and the inverse, in the BFO spec, and I don't know how they want to handle it or what they want to call it. I raised this issue at BFO-ontology/BFO#220.

Can we not just merge this one relation for now into RO?

phismith · 2018-08-25T16:47:19Z

Inverses for all relations used in BFO have been defined in the on-going work on updating BFO for the purposes of validating BFO as an ISO standard. More details will be released soon.
Barry

phismith · 2018-08-27T14:34:03Z

On Sat, Aug 25, 2018 at 3:25 AM Michael Sinclair ***@***.***> wrote: What conflicts do you see? Travis/ROBOT build is passing and this pull request is only adding a single object property in the ID range you assigned me and which does not conflict with any other property and is logically satisfiable. So I wonder why it can't be merged? Question: What does "CB" stand for? As for generic bearer of, I removed it because it is not in the BFO specification, though I think it should be. There are issues with adding the inverse right now, due to the current BFO spec, as follows: s-depends_on can depend on any independent continuant, including spatial boundaries. The subproperty of s-depends_on is 'inheres in', which excludes spatial boundaries from s-depends_on. The inverse of 'inheres in' is 'bearer of', which is an independent continuant excluding spatial boundaries on which a specifically dependent continuant depends. When it comes to g-depends_on, there are no equivalents to 'inheres in' and 'bearer of' in the restricted sense of not depending on a spatial boundary, and the inverse, in the BFO spec, and I don't know how they want to handle it or what they want to call it. I raised this issue at BFO-ontology/BFO#220 <BFO-ontology/BFO#220>.

This is being added to the ISO version of BFO: is carrier of at Elucidation: *b* *is carrier of **c **at* *t *if and only if *c **g-depends* *on* *b **at **t* [072-XXX] Domain: *independent continuant *that is not a spatial region Range: *generically dependent continuant* Examples: this hard drive is carrier of these data items, this copy of *War and Peace *concretizes the novel written by Tolstoy, molecules of DNA are carriers of genetic information BS

…

Can we not just merge this one relation for now into RO? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#233 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH6qN6dMfCQZJZOk8QJ_LmnTIr1cdupdks5uUPwCgaJpZM4U2wE_> .

msinclair2 · 2018-08-27T14:42:30Z

@phismith Thank you, that is very helpful! Do we have something to call g-depends_on whose range is 'independent continuant that is not a spatial region' (i.e. the inverse of 'carrier of')?

This is being added to the ISO version of BFO:
is carrier of at

Elucidation: b *is carrier of **c *at *t *if and only if *c *g-depends
on *b **at *t [072-XXX]

Domain: *independent continuant *that is not a spatial region

Range: generically dependent continuant
Examples: this hard drive is carrier of these data items, this copy of *War
and Peace *concretizes the novel written by Tolstoy, molecules of DNA are
carriers of genetic information

phismith · 2018-08-27T14:49:32Z

Voila (Note that, apart from defining a complete set of inverses and paying more careful attention to time, the new BFO-ISO relations are taken over from the old BFO 2 relations) generically depends on at Synonym: *g-depends on* Elucidation: a *g-dependent continuant* *b **g-depends on *an *independent continuant* *c **at **t* means: there *inheres* in *c *an *s-dependent continuant* which *concretizes* *b **at **t* [072-ISO] Domain: *generically dependent continuant* Range: *independent continuant *that is not a *spatial region* Examples: the pattern shared by chess boards g-depends on any chess board; the score of a symphony g-depends on a copy of the score, ]the novel *War and Peace *generically depends on this copy of the novel; this pdf file generically depends on this server

…

On Mon, Aug 27, 2018 at 10:42 AM Michael Sinclair ***@***.***> wrote: @phismith <https://github.com/phismith> Thank you, that is very helpful! Do we have something to call g-depends_on whose range is 'independent continuant that is not a spatial region' (i.e. the inverse of 'carrier of')? This is being added to the ISO version of BFO: is carrier of at Elucidation: *b* *is carrier of **c **at* *t *if and only if *c * *g-depends* *on* *b **at **t* [072-XXX] Domain: *independent continuant *that is not a spatial region Range: *generically dependent continuant* Examples: this hard drive is carrier of these data items, this copy of *War and Peace *concretizes the novel written by Tolstoy, molecules of DNA are carriers of genetic information — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#233 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH6qN-qS_vWu6ODvcbsKRImiUIBWi_Aoks5uVAVdgaJpZM4U2wE_> .

msinclair2 · 2018-08-27T15:00:19Z

@phismith I appreciate the preview, it's immediately useful.

@cmungall I'll add in 'carrier of' and amend the pull request soon.

msinclair2 · 2018-08-27T15:11:33Z

So it looks like 'generically depends on' truly is a shortcut now that can be defined as a property chain of the sort: (is_concretized_by some (inheres_in some IC)) and should not be directly asserted?

Elucidation: a g-dependent continuant *b **g-depends on *an independent
continuant *c **at *t means: there inheres in *c *an s-dependent
continuant which concretizes *b **at *t [072-ISO]

cmungall · 2018-08-27T15:30:46Z

Barry can you post a link to the iso relations?

cmungall · 2018-08-27T15:31:44Z

Michael, PR can't be merged until conflicts resolved. Also no reason not to assert.

msinclair2 · 2018-08-27T15:43:50Z

@cmungall I'm sorry that I am so new to this, but I don't see what the conflicts are except that the ro-edit.owl file I've edited contains a property that is not in the current ro-edit.owl file, and that needs to be merged by a collaborator to resolve. This seems true for all pull requests. What am I missing?

cmungall · 2018-08-27T15:50:06Z

No worries. See the top of the web page. Conflicts at git level. Needs manual resolution

dosumis · 2018-08-27T16:52:44Z

You can manually reconcile through the web interface here: https://github.com/oborel/obo-relations/pull/233/conflicts

…O spec

msinclair2 · 2018-08-27T21:18:33Z

After a thorough tutorial from on office mate on git conflict resolution, I finally understood what I needed to do, and resolved the conflict :). So this pull request still just has the addition of generically depends on. Could you merge it ASAP so that no new conflicts arise in the meantime? And then I can add the new 'carrier of' inverse as a direct assertion, unless you still want to use a property chain (which I don't know how to do yet).

Thank you for your patience.

cmungall · 2018-08-27T22:33:52Z

Thanks for your patience! Do you think you could also add the property chain axiom?

msinclair2 · 2018-08-28T02:36:38Z

I'd be happy to learn how to make property chains, but first I'm not entirely clear what the chain would be.

Is it a chain for inferring GDO in terms of s-depends_on and concretization?

Or a chain for inferring the inverse of GDO, which Barry has given us a formal definition and a name for, "carrier of"?

Or am I totally off the mark?

Thanks for your patience with a neophyte.

cmungall · 2018-08-28T06:17:40Z

See

https://www.w3.org/TR/owl2-primer/#Property_Chains
https://github.com/oborel/obo-relations/wiki/PropertyChain

so we'd have something like: gdo <- is_concretized_by o inheres_in

msinclair2 · 2018-10-09T19:46:14Z

@cmungall Has generically depends on been incorporated into ro yet? I can't find it and I'd like to update SO from using a locally created ad hoc relation with an SO prefix to using the one from RO. Thanks.

mark-jensen · 2019-03-13T16:11:53Z

@cmungall @jamesaoverton I see generically depends on and is carrier of were added, but not to RO Core. In a comment above it was suggested they should be, which makes sense considering their place in the BFO-ISO spec. Was there a reason for not including in Core?

cmungall · 2019-03-13T18:45:27Z

I think the intent was to add them to core, but it brings up a question, what's the reference for BFO? The existing Word doc we have been using, or the (currently non-public) ISO spec?

…

On Wed, Mar 13, 2019 at 12:11 PM Mark Jensen ***@***.***> wrote: @cmungall <https://github.com/cmungall> @jamesaoverton <https://github.com/jamesaoverton> I see generically depends on and is carrier of were added, but not to RO Core. In a comment above it was suggested they should be, which makes sense considering their place in the BFO-ISO spec. Was there a reason for not including in Core? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#233 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADGOY2rabQg6VswERqQnwxOOjT_HgWoks5vWSNKgaJpZM4U2wE_> .

msinclair2 mentioned this pull request Jun 25, 2018

go-plus equates ChEBI independent continuants and SO generically dependent continuants geneontology/go-ontology#15894

Closed

cmungall added a commit that referenced this pull request Jun 25, 2018

Update ro-idranges.owl

976634c

Adding id range for @msinclair2 See #233

cmungall mentioned this pull request Jun 25, 2018

Update ro-idranges.owl #234

Merged

msinclair2 force-pushed the master branch from bcfecf9 to 2c330b4 Compare June 25, 2018 22:40

cmungall previously approved these changes Jun 25, 2018

View reviewed changes

cmungall requested changes Jun 25, 2018

View reviewed changes

msinclair2 force-pushed the master branch from 2c330b4 to 63e7269 Compare June 26, 2018 00:10

cmungall mentioned this pull request Jul 26, 2018

subproperty of inverse object property expression triggers HermiT bug #242

Closed

cmungall mentioned this pull request Jul 26, 2018

Revise ROCore_Continuants.jpg? #241

Closed

msinclair2 mentioned this pull request Aug 25, 2018

Timeline and migration plan for MSO release? The-Sequence-Ontology/MSO#5

Open

Michael Sinclair added 2 commits August 27, 2018 15:05

Add generically depends on and inverse generic bearer of

e3f5f5a

removed generic bearer of, include only generically depends on per BF…

06a6e4f

…O spec

msinclair2 force-pushed the master branch from d59ec91 to 06a6e4f Compare August 27, 2018 21:13

create property chain with gdo and add is carrier of

ef15212

cmungall approved these changes Aug 30, 2018

View reviewed changes

cmungall merged commit 1c82785 into oborel:master Aug 30, 2018

cmungall mentioned this pull request Nov 3, 2018

soil injection is not a method AgriculturalSemantics/agro#40

Closed

cmungall mentioned this pull request Mar 4, 2019

Document an SOP for external users to make a PR The-Sequence-Ontology/SO-Ontologies#463

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add generically depends on and inverse generic bearer of #233

Add generically depends on and inverse generic bearer of #233

msinclair2 commented Jun 25, 2018

cmungall commented Jun 25, 2018

msinclair2 commented Jun 25, 2018

cmungall left a comment

msinclair2 commented Jun 26, 2018 •

edited

Loading

jamesaoverton commented Jun 26, 2018

cmungall commented Jun 26, 2018

msinclair2 commented Jun 26, 2018 via email

msinclair2 commented Jul 12, 2018 •

edited

Loading

cmungall commented Jul 13, 2018

msinclair2 commented Jul 13, 2018 •

edited

Loading

msinclair2 commented Jul 20, 2018

cmungall commented Jul 26, 2018

cmungall commented Jul 26, 2018

msinclair2 commented Aug 6, 2018

cmungall commented Aug 25, 2018

msinclair2 commented Aug 25, 2018

phismith commented Aug 25, 2018

phismith commented Aug 27, 2018 via email

msinclair2 commented Aug 27, 2018

phismith commented Aug 27, 2018 via email

msinclair2 commented Aug 27, 2018

msinclair2 commented Aug 27, 2018

cmungall commented Aug 27, 2018

cmungall commented Aug 27, 2018 •

edited

Loading

msinclair2 commented Aug 27, 2018

cmungall commented Aug 27, 2018

dosumis commented Aug 27, 2018

msinclair2 commented Aug 27, 2018

cmungall commented Aug 27, 2018

msinclair2 commented Aug 28, 2018

cmungall commented Aug 28, 2018

msinclair2 commented Oct 9, 2018

mark-jensen commented Mar 13, 2019

cmungall commented Mar 13, 2019 via email

Add generically depends on and inverse generic bearer of #233

Add generically depends on and inverse generic bearer of #233

Conversation

msinclair2 commented Jun 25, 2018

cmungall commented Jun 25, 2018

msinclair2 commented Jun 25, 2018

cmungall left a comment

Choose a reason for hiding this comment

msinclair2 commented Jun 26, 2018 • edited Loading

jamesaoverton commented Jun 26, 2018

cmungall commented Jun 26, 2018

msinclair2 commented Jun 26, 2018 via email

msinclair2 commented Jul 12, 2018 • edited Loading

cmungall commented Jul 13, 2018

msinclair2 commented Jul 13, 2018 • edited Loading

msinclair2 commented Jul 20, 2018

cmungall commented Jul 26, 2018

cmungall commented Jul 26, 2018

msinclair2 commented Aug 6, 2018

cmungall commented Aug 25, 2018

msinclair2 commented Aug 25, 2018

phismith commented Aug 25, 2018

phismith commented Aug 27, 2018 via email

msinclair2 commented Aug 27, 2018

phismith commented Aug 27, 2018 via email

msinclair2 commented Aug 27, 2018

msinclair2 commented Aug 27, 2018

cmungall commented Aug 27, 2018

cmungall commented Aug 27, 2018 • edited Loading

msinclair2 commented Aug 27, 2018

cmungall commented Aug 27, 2018

dosumis commented Aug 27, 2018

msinclair2 commented Aug 27, 2018

cmungall commented Aug 27, 2018

msinclair2 commented Aug 28, 2018

cmungall commented Aug 28, 2018

msinclair2 commented Oct 9, 2018

mark-jensen commented Mar 13, 2019

cmungall commented Mar 13, 2019 via email

msinclair2 commented Jun 26, 2018 •

edited

Loading

msinclair2 commented Jul 12, 2018 •

edited

Loading

msinclair2 commented Jul 13, 2018 •

edited

Loading

cmungall commented Aug 27, 2018 •

edited

Loading