'Unique' type family to express objects that are pointed at only once

[matko]

There are cases where it's convenient to assert that a particular predicate-value pair is only used with one subject. Right now our cardinality constraints can only work the other way - we can only assert that a particular subject-predicate pair is only used with one object.

One case where this comes up is in task scheduling. Suppose you have a database of Tasks, that you wish to assign to Workers. On first insert into the database, the Tasks will not yet have a link to worker but exist independently. Then, as part of iterative refinement, further modifications will assign tasks to workers.
Each task should only be pointed at by one worker. However, the worker cannot 'own' the task in the sense of a subdocument, because Task has an independent existence. A task starts out without any worker points at it, and during its life it may be handled by various different workers without fundamentally changing identity. We currently have no way to model this, and therefore, we have no way to ensure that a task isn't accidentally picked up by multiple workers at once.

I propose we introduce a new type family, 'Unique', which expresses exactly this constraint:

{ "@id" : "Worker",
  "@type": "Class",
  "task" : { "@type": "Unique",
             "@class": "Task" }
}

This should enforce that only one worker can have its task property point at a particular task.

Since workers can have more than one task, we may want to introduce family combinations here:

{ "@id" : "Worker",
  "@type": "Class", 
  "task" : { "@type": "Unique",
             "@class": {"@type": "Set",
                        "@class": "Task"}}}
}

This would express that a worker has a set of tasks, each of which can only be pointed at once by the 'task' property of a particular worker.

Or maybe we wish to opt for a more ergonomic style of type family combinations:

{ "@id" : "Worker",
  "@type": "Class",
  "task" : { "@type": "Unique(Set)",
             "@class": "Task" }
}

But maybe actually this reverses the order of things, and it should be Set(Unique). I am not sure here.
The reason why in my mind Unique may need to be the outer qualifier is that in case of arrays and lists, this constraint should ensure that the task only appears once in the array/list. We should be ensuring not just that only one worker points at a particular task, but also that that worker only points at it once from an array or a list.