Field-markers evolved

[manuelbernhardt]

Field markers are essentially a mechanism that enables interoperability between the vast number of schemas that we are dealing with, to avoid having to deal with "vanilla" fields (title, description, thumbnail, ...) in a custom way for each and every format.

Hence, their meaning must be very clear.

I ran into an issue with the delving:imageUrl field-marker being mapped to a PDF file this morning - which won't work, because an image is expected, and a PDF is not an image. The "Check" of the field-marker in this case was "digital object", which I think is too broad for the purpose of interoperability - a digital object can be anything, but displaying "anything" without contextual information (mime-type) isn't exactly easy.

I'd like to propose to evolve the field-markers a little more to make full use of the fact that LIDO in fact gives all the necessary context:

<lido:resourceRepresentation lido:type="image_master">
    <lido:linkResource lido:formatResource="application/pdf">http://collectiveaccess.murberget.se/media/ylm_ca_system/images/4/6/8/58347_ca_object_representations_media_46857_original.pdf</lido:linkResource>
    ...
</lido:resourceRepresentation>

i.e. here we have a link and a mime-type available and that we could make use of for the formats that provide it.

What I'd like to suggest is the following:

• introduce a delving:digitalObject field marker
• extend the field-marker mechanism to be able to fetch the URL from one xpath expression and the mime-type from another one
• write out these field-markers in the rootAugmented() tree as <delving:objectUrl mimeType="...">URL</delving:digitalObject>

The hub can then use this information and provide adequate rendering of those digital object fields.