How to create a metatype for artist assigned inventory numbers

[beaudet]

We have a large collection of Stieglitz prints. The artist created a Key Set (la:Set) and assigned numbers to each work specific to that Key Set. We refer to these alternative identifiers as "Key Set Numbers".

When creating a metatype to represent the Key Set Numbers concept so that it can be included as an Identifier, it seems to me like the best equivalent classification for a custom minted concept would be AAT's "creation numbers" https://vocab.getty.edu/aat/300404622 but the custom term would also need to be further classified with some type of association with the "Key Set" set but that's a Set not a Type.

How do you recommend I proceed?

For example, is there a way to specify identifiers that are directly related to the membership in a Set? That would preclude the use of a metatype because the Set would already be available in that case, so only Creation Numbers would be needed.

For now, I'm going to mint a custom Type that represents this specific Key Set so I can move forward, but hopefully there's a better option.

Thanks.

[azaroth42]

Two options:

1. The easier route is to mint a custom type. Then you're on the hook to describe that concept, give it a persistent identifier and so on. Easy enough for a few, but not great if you need dozens or more.

2. You could describe the assigning of the identifier with an AttributeAssignment. The type of identifier is just a regular number, and then associate the Set or assigning entity with it via the AA. We do this in LUX a lot to distinguish between the accession numbers, call numbers, or other identifiers of different organizations. For example: https://lux.collections.yale.edu/data/object/4a3d1b7d-9657-46dc-8363-18866dc4a6ed has two sets of identifiers as it is jointly owned by the art gallery and the YCBA

[azaroth42]

docs-needed or close?

[cbutcosk]

I work with a dataset that’s got a few AS Key Set nums in it, and we’re trying to understand what our users want in hopefully-useful Catalogue Raissone numbers for O’Keeffe herself, some brief thoughts:

• +1 to aat:creation_numbers as a good meta-type with a custom (documented!) URI and an Identifier primitive
• Two use cases we’ve discussed around these kinds of numbers are “other instances of this creation number”, especially for reproductive works on paper, or from a satellite dataset to an authority dataset like the NGA’s AS Key Set nums. Another use case I’ve had frequently is to see the set of all such identifiers / key nums (in an often-not-lexicographical order) — sometimes those are different than the set of all such numbered works and the access patterns may be different.
• Consider how / whether to emit identifier lifecycle events? It looks like the model allows used_specific_object and motivated_by for Identifiers, though I’m not sure how some of these access patterns translate to the API (eg, you wanted to treat the Identifier as having identity which endpoint would one use to POST changes?). The thinking here is that some of these kinds of id nums can be struck / replaced / etc but the identifier itself isn’t removed (because it shows a definitive not-this-artist assertion now, etc).

[azaroth42]

• Creation numbers: Yep, agree would be valuable. #186 related.
• All identifiers in a set: Assuming this is "all the objects that have this sort of number" ... seems easy enough?
• used_specific_object and motivated_by would be on an activity ... which for Identifiers would be an AttributeAssignment of the identifier. You can't, in the API, separate Identifier out from the entity that it identifies. I don't think (beyond AA) that we have data or use cases around identifier management.

[cbutcosk]

Is the best way to emit string data that has identity from an API perspective to use a LinguisticObject? Creation and Publication nodes work better as model for identifier publication / striking / etc anyway and it might be painful to use AAs for audit trail use cases. Throwing that out as an option for those in need, not prescribing it in the top-of-thread use case.