Remove inverses. Fixes #506.

[dylan-sa]

Fixes #506.

This PR includes changes related to the removal of inverse properties from gist:

• All inverses removed. (Inverse working group has proposed which directions to keep in gist.)
• Relevant axioms have been tweaked to include only the properties that will remain in gist. A common change was to switch out a property restriction with its inverse property. For example:

a owl:Restriction ;
owl:onProperty gist:isBasisFor ;
owl:someValuesFrom gist:Event ;

becomes

a owl:Restriction ;
owl:onProperty [ owl:inverseOf gist:isBasedOn ] ;
owl:someValuesFrom gist:Event ;

• If the direction we are removing contained more information than its inverse, the additional information was maintained in some cases where useful. (See, e.g., isGovernedBy.)

Breakdown (updated after 5/1 working group meeting):

Properties retained in gist	Inverse properties removed from gist
hasDirectPart	isDirectPartOf
hasDirectSubTask	isDirectSubTaskOf
hasDirectSuperCategory	hasDirectSubCategory
hasMember	isMemberOf
hasNavigationalParent	hasNavigationalChild
hasPart	isPartOf
hasSubTask	isSubTaskOf
hasSuperCategory	hasSubCategory
isAbout	isDescribedIn
isAffectedBy	affects
isBasedOn	isBasisFor
isGeographicallyContainedIn	containsGeographically
isGovernedBy	governs
isIdentifiedBy	identifies
isRecognizedBy	recognizes
occupiesGeographically	isGeographicallyOccupiedBy
occupiesGeographicallyPermanently	isGeographicallyPermanentlyOccupiedBy
precedes	follows
precedesDirectly	followsDirectly

Shared spreadsheet with final summary and proposal history. (SA folks can access.)

[rjyounes]

@marksem @uscholdm @dylan-sa On further thought, describes is the proper inverse of isDescribedBy; isAbout means something a bit different. Consider: the anatomy of my foot is described by Gray's Anatomy. We can say that the book describes the bone structure of my foot, but not that it is about my foot. One solution is to replace isDescribedBy with describes (for brevity) and keep isAbout as well.

[uscholdm]

@marksem @uscholdm @dylan-sa On further thought, describes is the proper inverse of isDescribedBy; isAbout means something a bit different. Consider: the anatomy of my foot is described by Gray's Anatomy. We can say that the book describes the bone structure of my foot, but not that it is about my foot. One solution is to replace isDescribedBy with describes (for brevity) and keep isAbout as well.

This is a vaid distinction, but let's treat that as a separate issue "Do we add a gist:descibes property". If there was a demonstrated need for both, maybe. But I'd need some convincing. Is about seems fine for most purposes.

[uscholdm]

Breakdown:

It would be super nice for this table to be alpha sorted so one can look things up.

[rjyounes]

@uscholdm

This is a valid distinction, but let's treat that as a separate issue "Do we add a gist:descibes property".

Normally I like to keep issues atomic, as you suggest, but this one is different. If they are not true inverses, and we remove one of them, we are removing a concept that is no longer expressible in gist. The short-term solution is to keep both and remove the inverse axiom, and consider later whether we can drop one of them.

[uscholdm]

we are removing a concept that is no longer expressible in gist

I do not that is what is happening. We are removing a property whose only meaning ever was to be the inverse of isAbout. It was poorly named.

[rjyounes]

I do not that is what is happening. We are removing a property whose only meaning ever was to be the inverse of isAbout. It was poorly named.

OK, valid point. I withdraw my proposal and have added new issue #814.

[rjyounes]

It looks like the serializer has not run on these commits. @dylan-sa You should check your setup. Did you run tools/setup.cmd after you pulled the latest from develop?

[dylan-sa]

It looks like the serializer has not run on these commits. @dylan-sa You should check your setup. Did you run tools/setup.cmd after you pulled the latest from develop?

You're right--this wasn't set up correctly. Fixed with latest commit.

[dylan-sa]

It would be super nice for this table to be alpha sorted so one can look things up.

Good idea--I have tweaked the ordering. 👍

[dylan-sa]

describes is the proper inverse of isDescribedBy

Agree that this is a better name for the inverse--worth considering in a separate issue.

[Jamie-SA]

I am curious about the decision to keep gist:governs and remove gist:isGovernedBy. I looked at the spreadsheet posted by Dylan on 3/28/2023 and I'm unclear on what the column names really mean (the Group Consensus column contradicts the Recommend Keeping column).

But my main comment is that the implemented choice seems to go against our general rule of thumb of lower cardinality. I would think gist:isGovernedBy is goes from the leafs and points to the root of a tree (hierarchy). But you've chosen the other direction. This seems to be the higher cardinality relation. And it isn't obvious to me that there is a specific semantic or use case benefit to choosing gist:governs instead.

[dylan-sa]

I looked at the spreadsheet posted by Dylan on 3/28/2023 and I'm unclear on what the column names really mean (the Group Consensus column contradicts the Recommend Keeping column).

Sorry for confusion on the spreadsheet--Group Consensus indicates what the working group settled on keeping, whereas Recommend Keeping is from an earlier version of the spreadsheet. The table at the top of the PR is a better source for the working group proposal.

[rjyounes]

@Jamie-SA We brought other considerations to bear on the decision. In this case, due to the verbosity of isGovernedBy, we opted for governs. It's more a matter of balancing criteria than having hard-and-fast rules. In this particular case I could personally go either way.

[dylan-sa]

@rjyounes @Jamie-SA @hmoore-sa - After some more adjustments, this one is ready for review. Would appreciate everyone's thoughts when you get a chance to look.

[rjyounes]

Good work - it looks like you caught everything.

[uscholdm]

While looking at this I see that the choice was made to keep containsGeographically and remove isGeographicallyContainedIn. I would like to suggest a couple of reasons why the opposite choice might makes sense.

containsGeographically means the same thing as hasPart between georegions and may be short lived. For now, we don't want have isGeographicallyContainedIn which means isPartOf. So Im in favor of having it as it is for now.
THere was a special reason for occupiesGeographically going the other way, I do not recall.

[uscholdm]

While looking at this I see that the choice was made to keep containsGeographically and remove isGeographicallyContainedIn. I would like to suggest a couple of reasons why the opposite choice might makes sense.

containsGeographically means the same thing as hasPart between georegions and may be short lived because it is not adding anything much. In any event, we don't want to have isGeographicallyContainedIn which means isPartOf. So Im in favor of having it as it is for now. THere was a special reason for occupiesGeographically going the other way, I do not recall.

[Jamie-SA]

Approved, but with comments.

[Jamie-SA]

Wondering if this should list the removed properties? Yes, there is a link to the issue, but if someone just scans the release notes it might be nice for them to be here.

[uscholdm]

Wondering if this should list the removed properties? Yes, there is a link to the issue, but if someone just scans the release notes it might be nice for them to be here.

Yes, I strongly agree

[rjyounes]

Agreed.

[Jamie-SA]

I don't see the removal of hasDirectSubCategory in the table in the issue or PR discussions. It's removal should be documented.

[dylan-sa]

Yes, good point. I'll add that to the release notes.

[rjyounes]

Just follow Jamie's suggestion of adding the list to the release note. Then it's good to go.

[dylan-sa]

I can get behind Jamie's suggestion to go with isGeographicallyContainedIn.

Michael does make a fair point that it's similar in meaning to isPartOf, which we are dropping; but relating regions using the smaller-to-larger direction has proved useful for regions hierarchies.

[uscholdm]

I can get behind Jamie's suggestion to go with isGeographicallyContainedIn.

Michael does make a fair point that it's similar in meaning to isPartOf, which we are dropping; but relating regions using the smaller-to-larger direction has proved useful for regions hierarchies.

I think we should get consensus before making yet another flip/flop.

M.

[rjyounes]

I agree. I’d like to reconvene our small group. It’s important to get these right so we don’t regret it later. Is that OK with everyone? From: Michael Uschold ***@***.***> Date: Thursday, April 27, 2023 at 9:40 PM To: semanticarts/gist ***@***.***> Cc: Rebecca Younes ***@***.***>, Mention ***@***.***> Subject: Re: [semanticarts/gist] Remove inverses. Fixes #506. (PR #813) I can get behind Jamie's suggestion to go with isGeographicallyContainedIn. Michael does make a fair point that it's similar in meaning to isPartOf, which we are dropping; but relating regions using the smaller-to-larger direction has proved useful for regions hierarchies. I think we should get consensus before making yet another flip/flop. M. — Reply to this email directly, view it on GitHub<#813 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAM5PZGRSHKWGGJVAQL5SQDXDMNXVANCNFSM6AAAAAAWNVYA5Q>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dylan-sa]

Decision after 5/1 working group meeting is to go w/ isGeographicallyContainedIn over containsGeographically, for reasons Jamie has described. I've pushed a commit to make the switch. If I could get one last look at the latest commit from @hmoore-sa , @Jamie-SA, or @rjyounes, I believe this one is ready to go.

[hmoore-sa]

Hi Dylan, Took a look, mostly focusing on the isGeographicallyContainedIn changes, and looks like you got everything as far as I can see. Continuing to be signed off!