Image rights statement in linked art version

[f27wood]

I just noticed that in the simple format, the image rights are mapped under HasVersion / Rights. This makes sense to me as the rights relate to the image.

However,in the linked art format it looks like the rights relate to the object, as they are stated in "Subject_to". I would expect them to be under Representation / Rights so it is obvious they relate to the image.

Although i cannot test this in the dev API at the moment, so it may already have been changed.

Example: Fourth object down: http://nma.conaltuohy.com/apiexplorer.html?keywords=*convict+love+token&endpoint=object&field=text&sort=&format=json-ld&size=100

[staplegun]

This may be difficult without post-processing the record during JSON-LD construction (the rights statement comes from EMu and the media from piction, which are merged after JSON-LD construction).

There is also a complication that a Piction image can represent multiple objects (so potential for duplication if pull down from EMu object records).

1. An alternative might be to make it clear that the rights statement refers to the media rather than the object or metadata, e.g. give the right its own identifier making it a type of 'image reuse right'.

2. It might be possible to add another representation layer e.g. /object/64620#media where the rights statement is attached - this can be addressed from within EMu and Piction processing.

Option (2) is more complex but more semantically correct (reflects that EMu has rights attached to the object). It adds another layer of abstraction in the data, but that could be contained only in JSON-LD and collapse back for simple DC.

Option (1) may be sufficient - legally we state that the right stated only applies to the images. Also attaching the rights to the image instead of the object is clearer to users - often get confused when see rights against the object, e.g. might think it is for the record metadata.

[staplegun]

Decided option (2) is best - pulls correct data together in JSON-LD, can still present flatter structure in simple DC.

[Conal-Tuohy]

• [ ] Every PhysicalObject will have a P138i _has_representation property, which is an instance of E36_Visual_Item, and which bears the legal rights.
• [ ] In turn, actual images, either from EMu or Piction, will hang off that E36_Visual_Item as values of its own P138i _has_representation property.
• [ ] The PhysicalObject's P138i _has_representation property should be redacted if the property value has no P138i _has_representation property value itself.
• [ ] The top-level E36_Visual_Item should have only one P138i _has_representation property value; if there are two, then the EMu-sourced one should be redacted.

[staplegun]

Slight change in approach - instead of wrapping in a 'super image' entity, keep each image as a representation of the object, but add a parallel bundling of the images (isAggregatedBy) that is subject to the rights.

[f27wood]

I have tested this and all AOK, moved to done.