Multiple images with the same Version value

[f27wood]

A couple of testers have asked whether we can indicate which thumbnail, preview or large image is the one to use - as there is often more than one image with these values.

Removing the EMu images when Piction images exist, will reduce the number of images. However there will still be cases where there are multiple images and hence a number of images that are a 'thumbnail image', 'preview image' and 'large image'.

I have suggested that they use the first image listed. As this will be the preferred one. I am assuming this is the case in that the API lists the images in the same order as Collection Explorer? I have tested this on a number of object records and it seems to be the case.

Or should we offer to add a flag to the preferred image? We would not want to add this to EMu, but could use the first image and add a flag ourselves. So developers can search for the flag rather than for the first image listed. This would be more work for you, so can be considered for a future release.

[Conal-Tuohy]

Are you saying that the first image listed in the XML input file should indeed be considered preferred? i.e. that they are maintained in EMu in that way?

If so, then I suggest we do tag those images with a flag that identifies them as "preferred-image". We have a bunch of such "types" already attached to images (to distinguish thumbnails from banners and so on), and adding another type to the first image would be an absolute doddle.

I should say that I don't think it's safe to expect that the API will return the images in the order in which they were listed in the XML. In fact the explicit ordering of the XML is lost in the translation to RDF, and if they are in fact coming out in the same order it's more good luck than anything else.

[f27wood]

I am hoping that the first image in the XML file is the preferred one, but I will need to check with Simon when he gets back... and then yes we could flag them as 'preferred-image'. BTW the 'preferred-image' would then have thumbnail, preview and large versions.

This can make until the full version.

[SimmoK]

Yeah it's the order the images are arranged on the Web Admin tab see attached.

[Conal-Tuohy]

So @SimmoK the first of these images should be tagged as "preferred"?

[SimmoK]

Yes, the first one is the preferred

[f27wood]

Great thanks Simon, glad that was the case.

[f27wood]

I am looking at record 157435 and cannot see how the preferred image is being flagged? Or is it that it is the first image? (which is the correct preferred one)

Noting that these images are form Piction.... so the preferred image is the one with page order=1.

[Conal-Tuohy]

"page order=1"? Do you mean to just pick the first Piction record that refers to any given object and mark it "preferred"?

A tricky thing is that the individual records in the Piction data file can refer to (i.e. depict) more than one object. It's possible that some objects might end up with more than one "preferred" image. e.g. imagine we have only 2 Piction images, in order:

• image m refers to object A
• image n refers to objects A and B

So image m would be marked preferred since it's the first image for object A, and image n would be preferred because it's the first referring to object B. Now object A ends up with two images whose type is "preferred". We might need to model the "preference" differently; rather than a "preferred image" being a type of image, it could be a type of depiction; i.e. the object's relationship to the image might be called has_preferred_image or something.

[f27wood]

Hmm I thought the Piction XML had a page order value which determines the order, but mayb eit is page number, as I cannot see a page order field in the Piction XML. Will check with Simon.

[f27wood]

I can confirm that it is the page number not the page order in the Piction XML.

When this has a value of 1, it means that image is the preferred image.

When there is no value, it means either:

• There is only one image so it is the preferred image
• there is more than one image and the page number hasn't been entered yet, in which case use the first image as the preferred image (ideally and over time all objects with multiple images will be numbered).

When the value is a different number (2,3,4, etc) it means that there are multiple images for that object and the number represents the order. As the number isn't 1, it is not a preferred image

[Conal-Tuohy]

<field name="Page Number">1</field>

[Conal-Tuohy]

Done in https://github.com/Conal-Tuohy/NMA-API-ETL/commit/c62cdc19c4cfc39b61454d41ac384d1989824a9f

[staplegun]

The JSON-LD contains classified_as: term/preferred, in simple DC there is no field but the preferred representation is always first, e.g. object 35504.

[f27wood]

For object 35504, yes the first image in the DC is the preferred one, however using another example.

Phar Lap's heart: 64620

The first image in the DC format is not the preferred one.

Is it possible to include a "preferred' flag/term in the DC format? I think this would make it easier for developers and ensure it is correct?

Also note that images of object 35504 are restricted... so should not be in the API at all... will log this separately.

[staplegun]

I have discovered where the issue is. The DC conversion is looking for media with P2 type of https://api.nma.gov.au/term/preferred but the IRI of the P2 type added during the CRM conversion stage uses the domain name of the current server, e.g. http://nma-dev.conaltuohy.com/term/preferred, so they are not identified as being preferred (as they don't match the expected IRI).

Fixed in https://github.com/NationalMuseumAustralia/Collection-API-ETL/commit/3e1e60f4cd9f74a5f15ef6a248da0ef3cb9c6a4d

[staplegun]

This fix seems to have worked. Phar Lap's heart object 64620 now has the preferred media MA23067914 as its first representation.

[f27wood]

Great! Fixed and moving to done. Noting that this will need to be documented.