Is an object lot a collection or provenance activity?

[Ethan Gruber]

Hey everyone,

I'm making some changes to our collections database to include richer provenance metadata to support some new search and visualization functions.

Our object lot metadata is inputted into CollectiveAccess, but I am looking at exporting this information into Linked Art CIDOC CRM for public display (as much as we are allowed to). I'm reviewing the model but unsure which profile to apply. I believe that an object lot would resemble an auction lot, which is defined as a "Set" under the Collection documentation. Is that interpretation correct? In this case, the object lot also has a provenance activity, where X number of objects were transferred from one entity to us on a particular date or date range. The nature of this activity could be a donation, auction (purchase), or a few other types of acquisition.

For example, we have a lot, 1955.190 (both title and identifier of collection), which has about 50 objects in it. They were all acquired on the same date in 1955 from the same person (donation).

Note that individual objects within the lot may have their own different provenance histories prior to the acquisition of the lot by the American Numismatic Society, which we do try to catalog at the item level (mostly free text and will require its own project to normalize).

Do you think this is generally the correct course, or is there some other representation of an object lot that I'm not seeing in the documentation.

Thanks,

Ethan

[Marcus Smith]

Hi!

After working  on a Linked Art-based project for over a year, I signed up to this group today in order to ask this specific question – and whaddyaknow, Ethan just beat me to it! ;)

Our case is nearly identical: we have a collection of objects – an la:Set – that were accessioned to a museum's collection together. Initially I assumed this would be modelled as a crm:E8_Acquisition activity, or a crm:E10_Transfer_of_Custody. But the ranges of the corresponding properties – crm:P24_transferred_title_of and crm:P30_transferred_custody_of , respectively – apply only to instances of crm:E18_Physical_Thing (and its subclasses – so for Linked Art usually a crm:E22_Human-Made_Object ). la:Set , on the other hand, is a subclass of crm:E72_Legal_Object and E89_Propositional_Object , and is thus not a valid target for those properties.

What's the correct way to describe this, then? We're considering creating an E8 or E10 activity, and then linking each physical member of the Set to it individually… but then the fact that they were accessioned as a group is partly elided. We'd be grateful for suggestions.

(Hi Ethan, by the way! It's been a long time! Sorry to piggy-back on your thread!)

best wishes and thanks in advance,

Marcus

--
Marcus Smith
Verksamhetsutvecklare / Development Officer
Riksantikvarieämbetet / Swedish National Heritage Board

[Robert Sanderson]

Hi Ethan, Marcus,

An excellent question!

Quick answer:

If the 50 objects in 1955.190 and the collection from Marcus have URIs, I think it follows this pattern: https://linked.art/model/provenance/auctions/#purchase-of-lot   

If not, then we should discuss a solution.

Long answer:

There are two similar situations:

1. The purchase of an Auction Lot (per Ethan) where the Provenance Activity used_specific_object of the Set representing the Lot, but transfers ownership of the members of the set individually. When there are identifiers for each member of the set, I think that's the way to go. You don't gain ownership of the Set as a concept, you gain ownership of its members and that's what the individual Acquisition nodes say. The question is at what point this becomes an unreasonable requirement. Maybe 50 objects is reasonable.

2. Another very similar scenario would be the acquisition of an archive. We wouldn't want to enumerate that the transfer of ownership occurred for the first letter, and the second letter, and the ... etc etc etc. Just that this entire hierarchy of sets of sets of sets of objects was acquired. At this scale, requiring every distinct object to have its own Acquisition is completely unreasonable.

But the truckload of boxes of letters and other stuff might never be identified individually in any system. And surely we wouldn't want to wait 30+ years for the cataloging to take place to that level. Marcus is completely correct that Set is not a physical thing, which is what the transferred_title_of relationship has as its range. You can't change the ownership, in CRM, of a non-Physical_Thing.

CRM has the notion of a physical aggregate (E19) such as a kit or chess set, and the curated holding (E78) which we replace with Set because E78 is necessarily physical, and we want to be able to accession or collect things which are not physical such as Performance Art or Digital Art (the work, rather than the storage media). That said, we tossed E78 for good reasons (that I can repeat if needed), and shouldn't bring it back in.

Option 1:

We could create an E19 (or E22) as a stand-in for the Set when it comes to Acquisition, Transfer of Custody and Move.  

Pros: We keep the Provenance fields the same

Cons: Now there are two identities for the same thing; Physical Aggregate is very weird when some or all of the parts are described, and doubly so when they have their own parts. Eg an auction lot has a part of a painting which has a part of a frame. Those are very different partitions but would use the same predicate.

Option 2:

We could create a new class PhysicalSet with parents of Set and E19.

Pros: We keep the membership notion of Set, but it's also an E19 so can have ownership transferred (etc). 

Cons: A new class to deal with a specific issue is a very expensive solution, and hard to know when to use in comparison to a Human Made Object or Set. The chess set ... HMO or PhysicalSet? The dec arts chest of drawers where the drawers are removable? The statue where the arm has been previously broken off and is now fixed in the right place with a gap? The statue where the arm has been reattached. The ship(s) of Theseus. We have repeatedly backed away from defining separability requirements of object identity.

Option 3:

We could create a set of new relationships for Acquisition, Transfer of Custody and Move to shortcut to the members (enumerated or not).

So:

{

  "type": "Acquisition",

  "transferred_title_from": {"id": "some/person"},

  "transferred_title_from": {"id": "some/other-person"},

  "transferred_title_of_members_of": {"id": "some/set/of/objects"}

}

Pros: No new identities or classes, the majority of the use cases are still as today, three new relationships.

Cons: Sets (expands?) a terrible precedent that we discussed at length for members_exemplified_by of multiplying all our relationships by adding _members_of to the end with a range of Set. As sets can have any class as member, almost all relationships could be conceivably applied to the members of a set. 

Of the three, the last option makes me want to cry slightly less than the other two... but not by much.

Rob

--
You received this message because you are subscribed to the Google Groups "Linked Art" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linked-art+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/linked-art/842cbc8b-e653-4c03-a650-7db6de13fe96n%40googlegroups.com.

--

Rob Sanderson

Senior Director for Digital Cultural Heritage

Yale University

[Ethan Gruber]

Hi Rob,

Thanks for the detailed response! The auction lot example seems reasonable enough for small sets, but we have some object lots that consist of tens of thousands of coins. I think our largest one has almost 86,000 coins in it. So it's not really possible to include a reference to each individual HMO URI within the LOD that represents the provenance activity (well, it's technically possible, but not efficient). Ideally we want to link from the individual object up to an umbrella record that represents some kind of set. The lot 1955.190 is really much more of a conceptual collection of objects than a physical set, like a chess set. But the third option in your example could work.

This does seem like an issue that would apply to most museums: provenance metadata is attached to the object lot record rather than 1 to n individual objects in the lot. I'm surprised it hasn't come up in discussion yet.

Thanks,

Ethan

To view this discussion visit https://groups.google.com/d/msgid/linked-art/CABevsUEh6hiFGFnLYC-ebE358f0Ko8xeo89OWORN1hvusBKB%3Dg%40mail.gmail.com.

[Ethan Gruber]

What do you think about this example with a Set with members_exemplified_by:

https://gist.github.com/ewg118/2c104718a5705f455ed92c2d8c4dfe0d

In this case, we have assigned a P2_has_type to the Acquisition event so that we can assign the acquisitions values such as donation, purchase, exchange, etc., all of which can be mapped to AAT URIs for "methods of acquisition".

[Robert Sanderson]

Yes, that's exactly what I was thinking :) To me that's the best route forward, as there are no new classes/relationships/precedents, just reusing what we have already.

Can I just cut and paste that (as JSON) into the ticket (to be created) ?

Rob

[Ethan Gruber]

Yeah, that's fine. There's nothing in the record that can't be public, though some of those URIs don't exist yet.

Ethan

To view this discussion visit https://groups.google.com/d/msgid/linked-art/f12e4fd7-d702-40a2-9696-98e6ee736491n%40googlegroups.com.

[Marcus Smith]

If this is to become the solution (and I agree it's the best option of the four), is it perhaps worth making it clear that this should be the pattern for unenumerated Sets only? Otherwise, where members of the Set are known and provided, they should be individually linked to the Acquisition activity.

My concern is, as mentioned on yesterday's call, that this effectively introduces two parallel patterns for object provenance: one where an object is directly associated with a provenance activity, and one where the object is part of a Set which has an exemplar which is associated with a provenance activity. That makes it a bit of a pain to write queries looking at object provenance. (And imagine if an object has changed hands multiple times, sometimes individually, sometimes as part of a group! Nightmare!)

By restricting this to unenumerated Sets only, the effect of this can be mitigated: an object has it's own provenance, a Set has provenance via an exemplar.

/Marcus

[Marcus Smith]

Hi Rob, thanks for the clarification!

I read that to mean that, without making changes to the Linked Art model (options 1–3), the best solution currently is to have an accession Activity and to link each member of the Set to it individually, right? (In our case, all the members of the Set have their own identifiers, so that could be a viable option for us.)

best wishes,

Marcus

[Robert Sanderson]

Yes, agreed. If the set is enumerated with real identities for the member objects, then we already have good patterns to deal with it.

Tried to document the thinking and solution here:

https://github.com/linked-art/linked.art/issues/780

To view this discussion visit https://groups.google.com/d/msgid/linked-art/83cc107e-c5fc-47a9-97ab-a5e316790fc7n%40googlegroups.com.