Administrative statuses

[richardofsussex]

Looking at e.g.:

photography.permission.image_supplier.lender object-1550 photography.permission.image_supplier.rights_holder object-15225 photography.permission.all_media object-18535 photography.permission.note object-1550 photography.permission.photography object-18535 photography.permission.press_photography object-3002 "photography.permission.note.value / type:""press note""" object-15225 photography.permission.press_note object-15225 photography.permission.tech_photography object-18535 access.item.reproduction.permission.non_website object-16573 access.item.reproduction.permission.press_note object-5201 access.item.reproduction.permission.website object-16573

To what extent do you want to output administrative status information? Generally speaking, these will be mapped to the "referred_to_by" array as LinguisticObjects, with the best classification I can drum up from AAT. In other words, they will be (elaborately presented) textual notes, with little semantic value. I don't see any way within LA to group together, e.g., all 'photography.permission' fields, so each statement/text note will be presented separately.

[RGShepherd]

These can all be safely ignored. They are either akin to handling notes, or will shape what images are available, but the shaping will happen within the CIIM.

[richardofsussex]

What about these? I can't even find an agent key in object-4023:

agent.@admin.id object-4023 agent.@link.role.value object-4023 agent.@link.prefix object-4023 agent.@link.suffix object-4023 agent.@link.date.value object-4023 (test data only) agent.@link.date.from object-4023 (test data only) agent.@link.date.to object-4023 (test data only) agent.@link.public object-4023 agent.@link.historical object-4023 agent.@link.sort object-4023 agent.@link.created object-4023 agent.@entity object-4023 agent.@admin.status object-4023 agent.@admin.uuid object-4023

[RGShepherd]

They will need to be reviewed by me: we used this area as a dumping ground prior to properly resolving publicity rules in TMS / the CIIM. Please ignore them for now; we may need to come back to the once they're properly mapped.

[richardofsussex]

OK, I have now gone through the whole of the 'additional object indexes' document, and have done what I thought sensible with the object records listed therein which I have been able to access. You can access any of these results via a URL of the pattern:

http://richardofsussex.me.uk/ng/output/object-[id-number].json e.g. http://richardofsussex.me.uk/ng/output/object-5959.json

It would be helpful if you could take a look, and let me know if this is broadly what you are hoping for.

[RGShepherd]

Re. agent...., there is currently no agent block in the public index; however, we should allow for it to be present. Contents will be similar to e.g. creation.maker...., but agent.@link.role.value will always just be "related" - think of good old Spectrum 'related people' ;-)

[RGShepherd]

@richardofsussex , just checking where you think we are with this one? It's a case of allowing for an agent block within object records that would be restricted to 'related person', as opposed to any more specific role such as subject, maker, former owners, etc.

[richardofsussex]

Vapourware on both fronts, I think. On the input side, IIUC, there are no agent blocks in the CIIM7 data to test. If that's wrong, please point me to an example containing suitable data. On the output side, it sounds as though you want a generic "this agent is related in some way to this object". Is that right? The only "related" in the context document is a mapping of the SKOS related concept, which has a different domain and range.

[RGShepherd]

Well, I've added one to object-4668.

Could we not use the solution for related objects proposed in https://linked.art/model/object/aboutness/#related-objects, but with a person as the assigned property rather than an object? If I understand it correctly, we could add an assigned_property with a value of, I think, http://vocab.getty.edu/aat/300444150, associated agents.

[richardofsussex]

I take it that what you have added is all the previous owners? (I don't see "related" anywhere in the data.)

[RGShepherd]

In the agent block; but I see we're not publishing the data anyway (it's just on the admin index). I'll see whether we can't open this up. Incidentally, object-1708 should be our test record for this.

See now https://github.com/national-gallery/NG-CIIM/issues/22#issuecomment-1752756457

[richardofsussex]

I take it then that what I'm seeing is more than the public interface currently offers?

If the agents I'm seeing in object-1708 are former owners (and recorded by you as such), why downgrade that information to a generic "related person" link?

Is the issue that LA reaches for a separate 'record' as soon as it tries to model provenance events, and you would prefer to avoid this, keeping everything in a single 'record'? (The provenance examples all offer an independent block with its own URL, and an entity type "Activity".)

[RGShepherd]

Which URL are you sending your queries to?

[richardofsussex]

e.g. https://data.ng.ac.uk/es/public/_search?q=@admin.id:object-1708, which suggests I'm using the public index. However, I am seeing a couple of agents within provenance.

[RGShepherd]

That's correct; and those provenance agents will be dealt with when he have some more granular provenance data (i.e. in a year or two). The 'related' people would have their own top-level agent block, rather than being a child of provenance, etc.

TLDR: on hold until we've got some data in the public index.

[richardofsussex]

OK, this is what I have done with the agents lurking in the provenance block:

(After reading https://linked.art/model/assertion/ I decided that the assigned_property should be a property from the LA context document, not - for once - an AAT URL. This means that the assigned_property values will be context-specific, once we have more agents to include from the public interface.)