Membership in arbitrary Sets

[azaroth42]

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 a Set. As we go from the many to the few (e.g. pages in a book, paintings in a collection), that means that member_of should be possible for any primary entity.

Thus, a Place should be able to be member_of a Set as well as part_of another (larger) Place.

Agree?

[azaroth42]

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.

[natuk]

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.

[azaroth42]

We have used Sets for:

• Collection of Physical and non-Physical things (e.g. a museum collection, auction lot or exhibition). This is the main use case, I think.
• Sets of digital things -- I think this will come up more and more.
• Arbitrary sets of entities such as "favorite" pick lists.
• Any set of entities that is not partitive. The set of concepts that can be applied to a Statement is a Set, for example, as they're not all narrower than a single broader concept.

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 :)

[azaroth42]

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.

[azaroth42]

Closing, done -- all entities in API can be member_of a Set, and documented in the Collections/Sets model page.