Closed azaroth42 closed 5 months ago
There's a json-ld issue with member_of
for people and groups, in that we already map the participation in a group as member_of
(P107) :( An ideal world would have the group member_of
go away in favor of the more general one, and Group be a subclass of Set ... but that's not what we have.
Forgive me I cannot find where we explain what problem Set
solves. It would be useful to document the benefits of using member_of
and Set
as opposed to the existing CRM properties for partitive relationships. Is this the relevant section? If it is, perhaps the example about the retired members of a group in there is not representative since the cardinality of P107 has current or former member
is "many to many (0,n:0,n)" which indicates that an E74 Group
may have no members so P107
could be used instead. But this seems to be the concern raised by Rob in the last comment about confusing the two member_of
.
If I remember correctly, we discussed Sets
in relation to auctions which include physical and conceptual things in one lot and we had no other way of grouping them. Generalising it to include anything makes the property rather weak. What is the meaning of a place being in the same group with a concept? I wonder if we are always grouping concepts (e.g. the identifier of the place, not the place itself) and therefore all we need is P148
.
We have used Sets for:
I think the what it /can/ be used for an what it /should/ be used for is the distinction you're drawing. I agree that an arbitrary set of a Type and a Place is not meaningful without a lot more context, but ruling out at the ontology level that Types and Places cannot be grouped together seems equally arbitrary and unnecessary. In the profile, we can enumerate and describe the scenarios in which this would be useful.
Really what would be the best is for Set (or Temporary Aggregate as Martin calls it) to be a super-class of Group, and for Group to use member_of from Set. But that's for another SIG meeting :)
Further Use Cases from discussion: Use Case: Things /related/ to objects, including ideas or other non object entities. Use Case: Sets of Types, representing keywords or classifications
Discussion on call of 2020-07-01: Useful from a practical perspective for covering use cases, if not for reasoning or strong semantics. Should use for "real" sets that are grounded in data, not as a stand-in for a relationship. Need docs and examples to demonstrate the usage.
Closing, done -- all entities in API can be member_of a Set, and documented in the Collections/Sets model page.
In starting to document the set of properties that can be expected in a response, I ran into
member_of
... e.g. that any entity can be a member of aSet
. As we go from the many to the few (e.g. pages in a book, paintings in a collection), that means thatmember_of
should be possible for any primary entity.Thus, a
Place
should be able to bemember_of
aSet
as well aspart_of
another (larger)Place
.Agree?