Where do we document Adding to / Removing from Collections

[azaroth42]

Normally, the previous decisions about the default direction of a property make it obvious where references between entities should be managed. However in some cases, there are many occurrences on each side and thus no easy way to judge where best to record the knowledge.

In particular, I am updating the woefully out of date page on Collections. At the end is a section about the activities of adding an object to a collection or removing one from it. Should these activities go on:

• The object (and thus there will be lots of adds/removes for each collection it could be part of)
• The collection (and thus there will be lots of adds/removes for each object that is part of it)
• A provenance activity (where there's fewer entities, but this doesn't capture all of the scenarios in which objects are added to collections ... for example a destruction event would surely cause an object to be removed, but doesn't generate a new provenance activity... or does it??)
• A new top level activity (which would be very small and seems to stand too much on its own)

I would suggest the object as a first attempt, as that's where we also have the member_of relationship to the set. Which subsequently means that as any entity can be part of a set, any entity can have the added/removed activity as part of its model.

Thoughts?

[azaroth42]

Similarly, we should discuss the Exhibition specific information for an object.

If it is associated with the Exhibition, then a big exhibition would have MANY attribute assignments for specific labels, descriptions, identifiers and so forth. However if it is associated with the object, then we decrease the ability to have information systems use each others' data directly ... the exhibiting institution cannot update the set of labels used in the owning institution's collection management system.

The same breakdown as above seems to apply:

• The object (lots of specific information in the record if it is in lots of exhibitions)
• The exhibition (lots of objects in the exhibition)
• A Provenance Activity (the transfer of custody to the exhibition, which might not be accurate and complex when the exhibition is carried out by the owning institution)
• The adding/removing of the object to the exhibition's set of objects (see above!!)
• New top level activity (that would be very small and easy to get lost)

For this one, I tend to prefer the object, as the number of exhibitions per object is smaller than the number of objects per exhibition.

[beaudet]

I'm concerned that if we use the object for this purpose, a lot of data will end up missing since institutions might be hesitant to represent themselves as an "authority" for the objects making up the exhibition unless those objects are part of their collection already.

Also, a cross-institutional ID for the exhibition seems important as well although that would probably be some type of activity grouping concept. Would a convention need to be established to defer to the institution where the exhibition first opens to establish that ID or is there a need for some kind of independent authority to track exhibitions so that all of the participating institutions can point back to the same concept, e.g. Getty Exhibitions Authority?

If institutions are free to represent their version of an exhibition which might contain substantial differences from the content of another institution participating in that exhibition, and they can feel confident knowing that the objects appearing under an exhibition are not being rendered as first class objects in their linked art data, they will be more comfortable publishing data about objects loaned to them along with the labels used in those exhibitions. I recently had a discussion with our registrar and legal departments about this very problem in the context of releasing open data as CSV files - they are very hesitant to represent objects of another institution if there's any notion of us behaving as an authority on those objects.

[azaroth42]

Discussed on call 2020-10-21: Should be in the collection, not on the object. See notes for rationale.

[azaroth42]

Pushing add/remove from Set, and join/leave from Group to 1.1

[azaroth42]

Useful for deaccessioned objects.