@Daniel -- this looks really nice. Thanks for the detailed explanation and all of the examples + visualizations, this makes thinking through this really easy. One immediate question -- I know we have some "problem children" or difficult cases in our acquisitions, do we know where those bodies are buried enough to know whether this will support them?

One thing to think about here—would be worth figuring out how to use temporal relationships to order these explicitly, particularly for ones without dates, for instance the Gallery Bernheim one. Likely could be done with a `P182 ends before or with the start of` property between successive entries?

Yes, I had noticed that the starts_after_the_end_of and ends_before_the_start_of properties were missing from the sample Activity document; I have updated this page to reflect their inclusion now. All provenance related Activity entities associated with a given Object record will contain the relevant starts_after_the_end_of and ends_before_the_start_of pointers to the previous or next Activity in the temporal provenance sequence associated with the Object, regardless of if the actual dates for a given provenance entry are known or not. Thank you for the note about it too.

Do we anticipate acquisition events like this being shared between objects, or is there a one-to-one relationship between them? (And, if so, can we treat this as a single document, rather than pointers to many documents?

This is a great question, and one I have thought a lot about during this mapping process. Currently our provenance entries are recorded in TMS in such a way that they are specific to a given Object's previous ownership. TMS provenance metadata is simply an ordered list of otherwise separate join records between Objects and Constituents (Actors) with a few additional provenance specific fields added on top of the join. It is really a function of how this information is recorded and particularly how it is presented that makes it into the nicely formatted and human-readable provenance history that we display currently within Collection Online, but behind the scenes these individual provenance records do not connect to each other (aside from indirectly via their shared Object relationship), nor do they connect to provenance records about other Objects. However, given the desire for various data enrichment and data reconciliation projects, it seems that at least to some extent this lack of current connectivity may be resolved in the future, and if so, it begs the question: Would we want to publish our provenance metadata from the outset in the format needed to support this additional connectivity in the future (that is to publish the Provenance entity records as separate LOD documents, despite the additional dereferencing overhead), or do we wish to publish a given Object's Provenance metadata as a consolidated section of the Object's associated `HumanMadeObject` record for the time-being, and potentially need to republish it as separate documents in the future with the attendant data compatibility issues for clients that such a changeover could cause? While our TMS provenance metadata is generally very well organized and is fairly "clean", there are definitely gaps in the data, and the most detailed part of the provenance entry is generally the provenance statement which is just a free-text field containing a value such as "by inheritance to his wife, Mme. Jacques Doucet, 1929." – clearly there is a quite a lot of information in this one statement – the transfer type is noted ("inheritance"), the recipient is noted ("Mme. Jacques Doucet"), and when the transfer occurred ("1929"), and sometimes other information will be present in the statements too – sadly this information is not fully fielded within the same provenance record so is more difficult to parse and process in a reliably consistent machine-readable way, and there are no current links to other Objects or clearly formatted metadata about sub-activities associated with a given acquisition, such as payments. Luckily a good proportion of the provenance statements do follow provenance style guide recommendations so the potential to parse controlled metadata out of them exists, but the remaining statements would need to be edited for consistency for us to be able to do this consistently across the Collection. If we were able to take advantage of the richness that exists in the various free-text provenance metadata fields, I am sure we could increase the connectivity of the current provenance entries to other records, and as such we would be able to add to the richness of the LOD. As such, does this encourage us towards emitting our current provenance as separate records, or given that these data enrichment projects could potentially still be some years away from fruition, do we consolidate the provenance metadata for now and separate it later? For completeness, I have provided an example of how the consolidated provenance metadata could look at the bottom of this document, and as I imagined the possibility of the modeling going either way, the provenance metadata LOD transform code can produce both the current set of separate but related documents, or at the change of an environment variable, will produce the consolidated provenance metadata block and embed it within the parent Object record. Any feedback with regards to the most optimal outcome would be appreciated, and I would be happy to implement either pattern.

Is this an accurate summary of what you've written? "Provenance entries are specific to a given Object's previous ownership as an ordered list. They're a join between Objects and Constituents with a few additional provenance specific fields. Do we want to future-proof this, to allow for connections in the future, or should we go with simplicity and minimize network requests by including them with the object?"

Yes, I would say it is. We can certainly optimize the LOD output now, and expand it out in the future, if and when enriched source metadata allows us to meaningfully do so.

@Daniel One thing I was thinking about yesterday is how we handle the Nazi Era artwork searches. Would the `classified_by` on the Acquisition or the Activity be how we best map this? Do we need anything else to map that?

Hi Adam, this information is recorded in what is known as the provenance "proofed" field, and with regards to NEPIP, there are two applicable values that are recorded in this field in TMS: "Nazi era gaps" for works where there are gaps in the provenance history between 1933-1945, and "Nazi era restituted" where the work was known to have been confiscated during the period 1933-1945 and restituted to its previous owner before being acquired by the Museum. This information is currently provided in the LOD mapping as a LinguisticObject associated with the Activity, however, rather than have you base your indexing on a string field, which could potentially change format in the future, it makes sense to provide an additional classification for each of these provenance record statuses, as such two local thesaurus statuses will be available under the `classified_as` property of the relevant Activity instances: https://data.getty.edu/local/thesaurus/provenance-nazi-era-gaps and https://data.getty.edu/local/thesaurus/provenance-nazi-era-restituted. Please let me know if this will work for your use case.

Hi Daniel, I talked with David about this, and I think the best thing to do may be to wait a bit and see what the curators want to enable. Your solution definitely would make our life easy to perform the searches, but it may be something worth waiting to do until *after* they've made the decision, to just save you the duplicate effort.

Hi Adam, Thank your update. I will hold-off on adding these classifications for now as requested. We can always add them, or something similar, once we know exactly what the curators want. For now I will go ahead and deploy to staging the updated transformer configured to embed the provenance history within the Object record as previously discussed. Thanks.