Drop isAssignedBy and use hasGiver for Assignments?

[rjyounes]

Note: gist:isAssignedBy is being added in gist14, so no consequences to removing it now.

[dylan-sa]

I second this. isAssignedBy was intended to represent the assigner for Assignment objects, but hasGiver can play this role.

[rjyounes]

gist dev team meeting 6/26:

Michael: agree

No one disagrees.

David Baker: Should hasRecipient also replace isAssignmentTo?
Nothing in gist precludes this.
Jamie and David will look at Spark usage for next time.

[dbsemantic]

Currently in Spark we only use gist:Assignment as a superclass for 3 things: TaskAssignments, PositionAssignments, and WorksFor (precursor to LaborAgreements which are being phased out).

Of these three, the only one that uses hasGiver/hasRecipient is WorksFor, which relates the Assignment to the Employee. PositionAssignments do not currently have an "assignee", instead we connect them to the employee's labor agreement through an "isSpecifiedBy".

Lastly, TaskAssignments are the trickiest. They are related to the employee using an "assignmentOf" predicate, and related to the task itself using the "assignmentTo" predicate. These are the outdated forms of the current isAssignmentOf/To (migrating to the gist13 predicates is on the backlog somewhere I'm sure).

While the definitions for both predicates could use some refinement, they indicate that isAssignmentOf is for non-agentic things while isAssignmentTo is for agentic things. Dropping one or both in place of hasRecipient would create even more ambiguity, and I'm therefore no longer in favor.

There should be no issue in using hasGiver for assignments though, and as we see with WorksFor the dev team has already taken to using this convention.

[rjyounes]

There is no hard-and-fast rule for which is the object of to and which the object of of, and in some cases both are agentic or both are non-agentic. The ambiguity is unfortunate and makes for a high degree of cognitive load. But I agree with your general point that replacing either with hasRecipient won't work for the reason you state.

[rjyounes]

@dbsemantic Can I assign the original part of this issue to you: removal of isAssignedBy and replacement with hasGiver?

[dbsemantic]

@rjyounes Sure thing.