Refactored giver, getter and hasParty. Fixes #133 #404

uscholdm · 2020-11-19T21:21:23Z

New property: hasParticipant replaces hasParty
- Range: Person or Organization.
- Domain: includes Event, Agreement, Obligation.
- Has subproperties: toAgent and fromAgent
Use hasParticipant wherever hasParty was used
Use toAgent wherever getter was used
Use fromAgent wherever giver was used
Deprecate: hasParty, getter & giver.

- Use fromAgent wherever giver was used - Use hasParticipant wherever hasParty was used - Deprecate: hasParty, getter & giver. - New property: hasParticipant - Range: Person or Organization. - Domain: includes Event, Agreement, Obligation. - Has subproperties: toAgent and fromAgent

sa-bpelakh

Looks OK, but do we have an issue with consistency of property naming, i.e. fromAgent/toAgent vs hasParticipant (as opposed to hasFromAgent/hasToAgent). When do we prefix properties with has/is, and when do we not?

uscholdm · 2020-11-20T02:21:29Z

we have an issue with consistency of property naming, i.e. fromAgent/toAgent vs hasParticipant (as opposed to hasFromAgent/hasToAgent). When do we prefix properties with has/is, and when do we not?

This is true. There are a lot of inconsistencies like this. That is a separate issue (#188). I think its best to not too too many things at once.

marksem · 2020-11-23T17:27:33Z

I feel like hasParticipant -- as a general property -- can have a broader range. Would not restrict domain to Person or Org.

uscholdm · 2020-11-23T22:52:14Z

@marksem said:

I feel like hasParticipant -- as a general property -- can have a broader range. Would not restrict domain to Person or Org.

Another discussion you missed. I agree with you on this, but the majority felt that 'participate' implied some active intent. So inanimate objects need not apply for this role. There might still be time to file a law suit and overturn the vote result.

marksem · 2020-12-02T19:18:31Z

Regarding active "intent", if I say a process participates in a larger process, I am not implying agency on the process. A chemical participates in a chain reaction. Assuming participatesIn would be the logical inverse of hasParticipant, I again feel that more than Persons and Orgs participate in things. Your honor, I move that Person/Org restrictions be stricken from the record!

uscholdm · 2020-12-02T19:26:02Z

I could not agree more!!! Pity you were not there to make your case when it came up. @rjyounes I suggest we revisit this on a future Thursday session.

rjyounes · 2020-12-02T19:34:48Z

OK, let's put this on hold and move the issue back to in review.

Maybe @marksem's disagreement is only with the wording - that is, I at least still think that there is value to distinguishing the kind of participation agents do as opposed to things, but perhaps we don't have the right term.

mkumba · 2021-01-16T18:03:12Z

Didn’t we decide to deprecate fromAgent and toAgent and redo message to be hasGiver and hasGetter? On Jan 15, 2021, at 5:04 PM, Michael Uschold <notifications@github.com<mailto:notifications@github.com>> wrote: LATEST CHANGE NOTES: Refactored hasParty, giver and getter * 'giver' and 'getter' * Rename to hasGiver and hasGetter * Deprecate * No longer subproperties of hasParty * New property: hasParticipant * No domain or range * Has subproperties: hasGiver, hasGetter, hasParty, fromAgent and toAgent * Added annotations on fromAgent and hasParty — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub<#404 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAGJPWOMIDFFCXUAXNKGNTS2DQZLANCNFSM4T36AKMA>.

uscholdm · 2021-01-18T01:34:23Z

Didn’t we decide to deprecate fromAgent and toAgent and redo message to be hasGiver and hasGetter?

If we did, I don't specifically recall. It was not in the summary notes from @marksem MarkW, or if it was, I missed it. Can others chip in and confirm one way or the other?

rjyounes · 2021-01-18T16:09:45Z

@uscholdm I don't recall that, but rethinking it, as Dave suggests, I don't know why we would need fromAgent and toAgent when we have hasGiver and hasGetter.

uscholdm · 2021-01-18T17:44:19Z

@rjyounes I don't know why we would need fromAgent and toAgent when we have hasGiver and hasGetter.

Its tempting, but I'm not sure it is always correct. Suppose I make a change to the beneficiary on my life insurance policy from person A to person B. If there is an instance of a class called BeneficiaryChange the fromAgent is person A but they are not a giver.

In the case of a package or a message, the fromAgent is the sending agent or the originating agent which might not correspond to 'giving' anything. The sender might be returning a borrowed item to its owner. Both would nicely fit in a totally generic gist:from property, but I am the only proponent of that idea.

rjyounes · 2021-01-18T18:36:17Z

@uscholdm "Give" doesn't have to mean transfer of ownership; we can say "give back" for returning a borrowed item. Anyway, the same argument could be applied to putting money in someone's bank account, which is one of the uses cases for hasGiver; if that were borrowed money, then according to your limited sense of "give," that is not giving either. Even the original sense of giving an obligation is not a transfer of ownership. Or was that going to be fromAgent? I've lost track.

As for the first example, I think you are incorrectly exploiting the multi-faceted meaning of "from" (and most prepositions) to broaden the meaning of "fromAgent" beyond the agreed-upon sense. If "fromAgent" means "the source of something" - I believe we are keeping that part of the definition and simply broadening it to include a wider scope than message or shipment - person A is not the source of the beneficiary change either: you would be the fromAgent (the source of the beneficiary change) and person B would be the toAgent. I think the BeneficiaryChange is a three-way relationship, and we don't have a specific predicate for that happened to A.

rjyounes

Requesting just a couple of tiny changes.

gistCore.ttl

docs/ReleaseNotes.md

rjyounes · 2021-02-15T17:09:26Z

docs/ReleaseNotes.md

+- New property: `hasParticipant`
+  - No domain or range
+  - Has subproperties: `hasGiver`, `hasGetter`, `hasParty`, `fromAgent` and `toAgent`
+- Added annotations on `fromAgent` and `hasParty`


A bit confusing, since when I look at the code I don't know what annotations have been added. Can we just leave this out - or if you want it there just a couple of words to indicate what's changed?

I purposely left out the gory details thinking it's easy enough for people to look to see for themselves. Leaving it out altogether gives no information. At some point (maybe not this one) more detail detracts. I added a scope note to one and an example on the other. I also added one word to the skos:defintion which I chose not to mention. Its a matter of taste, I suppose. Do you prefer this level of detail:

Added the word 'event' to the skos:definition of fromAgent

Added a skos:scopeNote to fromAgent

Added a skos:example to hasParty

gistDeprecated.ttl

docs/ReleaseNotes.md

- Updated release notes - added skos namespace to deprecations file.

gistCore.ttl

rjyounes · 2021-02-25T16:34:44Z

Michael will touch base with Mark to see if his comment has been addressed and the PR can be merged.

marksem

All looks good except for the skos:definitions of fromAgent and toAgent. I find them gramatically incorrect and/or too specific on implying a domain of shipment or message only.

Suggestions to correct this:

fromAgent:
the party that is the source of something (e.g. a message, shipment, etc.)

toAgent:
the party that is the recipient of something (e.g. a message, shipment, etc.)

# Conflicts: # docs/ReleaseNotes.md # gistCore.ttl

- updated definitions for `toAgent` and `fromAgent`

- updated release notes

- updated definitions for `toAgent` and `fromAgent` (again)

sa-bpelakh

Yay, compliant labels :) Are you running a build to verify before pushing?

.gitignore

Co-authored-by: Boris Pelakh <44446537+sa-bpelakh@users.noreply.github.com>

uscholdm · 2021-02-26T03:57:56Z

Yay, compliant labels :) Are you running a build to verify before pushing?

No. I merged develop into the branch first. I also read the manual and acted accordingly.

docs/ReleaseNotes.md

uscholdm added 2 commits November 19, 2020 13:03

- Updating release notes

795d01a

uscholdm requested review from mkumba, scotthenninger, pwin, rjyounes, DanCarey404, marksem, daliadahleh and sa-bpelakh November 19, 2020 21:21

Tweaked wording.

bdb685c

sa-bpelakh reviewed Nov 19, 2020

View reviewed changes

rjyounes requested review from sa-bpelakh and rjyounes and removed request for mkumba, scotthenninger, pwin, rjyounes, DanCarey404, marksem, daliadahleh and sa-bpelakh December 2, 2020 19:30

rjyounes closed this Dec 2, 2020

rjyounes mentioned this pull request Dec 3, 2020

Expand definition of giver and getter #133

Closed

Tweak release notes for giver/getter update

f710c62

rjyounes changed the title ~~Refactored giver, getter and hasParty~~ Refactored giver, getter and hasParty. Fixes #133 Feb 15, 2021

rjyounes requested changes Feb 15, 2021

View reviewed changes

rjyounes reviewed Feb 15, 2021

View reviewed changes

gistDeprecated.ttl Show resolved Hide resolved

rjyounes reviewed Feb 15, 2021

View reviewed changes

docs/ReleaseNotes.md Show resolved Hide resolved

Issue 133

bbc2135

- Updated release notes - added skos namespace to deprecations file.

rjyounes self-requested a review February 25, 2021 15:51

rjyounes approved these changes Feb 25, 2021

View reviewed changes

gistCore.ttl Show resolved Hide resolved

gistCore.ttl Show resolved Hide resolved

marksem requested changes Feb 25, 2021

View reviewed changes

uscholdm added 4 commits February 25, 2021 14:17

Merge branch 'develop' into evolve/issue133_giver_getter

cf459e8

# Conflicts: # docs/ReleaseNotes.md # gistCore.ttl

Addressing issue #133

315cf08

- updated definitions for `toAgent` and `fromAgent`

Addressing issue #133

092ae5a

- updated release notes

Addressing issue #133

ea905a2

- updated definitions for `toAgent` and `fromAgent` (again)

uscholdm requested review from marksem and rjyounes February 25, 2021 22:37

sa-bpelakh reviewed Feb 26, 2021

View reviewed changes

.gitignore Outdated Show resolved Hide resolved

Update .gitignore to ignore all .orig files.

85c569d

Co-authored-by: Boris Pelakh <44446537+sa-bpelakh@users.noreply.github.com>

uscholdm requested a review from sa-bpelakh February 26, 2021 03:58

sa-bpelakh approved these changes Feb 26, 2021

View reviewed changes

Move patch updates below minor updates in release notes

66a569a

rjyounes approved these changes Feb 26, 2021

View reviewed changes

docs/ReleaseNotes.md Show resolved Hide resolved

rjyounes merged commit 54d34c0 into develop Feb 26, 2021

rjyounes deleted the evolve/issue133_giver_getter branch February 26, 2021 16:04

Refactored giver, getter and hasParty. Fixes #133 #404

Refactored giver, getter and hasParty. Fixes #133 #404

Uh oh!

Conversation

uscholdm commented Nov 19, 2020

Uh oh!

sa-bpelakh left a comment

Choose a reason for hiding this comment

Uh oh!

uscholdm commented Nov 20, 2020

Uh oh!

marksem commented Nov 23, 2020

Uh oh!

uscholdm commented Nov 23, 2020

Uh oh!

marksem commented Dec 2, 2020

Uh oh!

uscholdm commented Dec 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rjyounes commented Dec 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mkumba commented Jan 16, 2021 via email

Uh oh!

uscholdm commented Jan 18, 2021

Uh oh!

rjyounes commented Jan 18, 2021

Uh oh!

uscholdm commented Jan 18, 2021

Uh oh!

rjyounes commented Jan 18, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rjyounes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rjyounes Feb 15, 2021

Choose a reason for hiding this comment

Uh oh!

uscholdm Feb 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rjyounes commented Feb 25, 2021

Uh oh!

marksem left a comment

Choose a reason for hiding this comment

Uh oh!

sa-bpelakh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

uscholdm commented Feb 26, 2021

Uh oh!

Uh oh!

Uh oh!

uscholdm commented Dec 2, 2020 •

edited

Loading

rjyounes commented Dec 2, 2020 •

edited

Loading

rjyounes commented Jan 18, 2021 •

edited

Loading

uscholdm Feb 16, 2021 •

edited

Loading