map CCMA IIIF images #12

VladimirAlexiev · 2017-03-10T08:56:40Z

http://data.americanartcollaborative.org/page/ccma/object/4 crm:P138i_has_representation
http://iiif.museum.colby.edu/2013.003_001_cd.jpg.
If you click that URL, it returns JSON so there's a live IIIF server underneath. But that URL is not an image (JPEG)

There are two issues here:

(simple) @bsnikhila @cbutcosk transform the above to an IIIF request for a specific image size
(complex) @workergnome is very interested to demo some IIIF deep-zoom images. So it would be great to also add more triples to describe the IIIF. deep zoom images are not mapped designforcontext/aac_review_tool#51 raises this issue: @workergnome and @azaroth42, can you add that mapping?

cbutcosk · 2017-03-10T14:14:53Z

I also would be very interested in seeing that stuff get mapped! I had intended IIIF_URL to be a IIIF identifier, but can change that to whatever makes sense for mapping. I also will have presentation manifests for those objects up sometime next week if that's helpful.

May I suggest that ImagePath still be mapped as the object of a crm:P138i_has_representation predicate though? In addition to whatever the IIIF mapping turns out to be, I mean. All our objects don't have IIIF-represented images and it'd be a shame to lose representation data about the ones that don't.

caknoblock · 2017-03-10T17:07:18Z

We are building the metadata files for the IIIF mappings, so we will need to figure out how to map and use this data.

…

On Mar 10, 2017, at 6:14 AM, charlie butcosk ***@***.***> wrote: I also would be very interested in seeing that stuff get mapped! I had intended IIIF_URL to be a IIIF identifier, but can change that to whatever makes sense for mapping. I also will have presentation manifests for those objects up sometime next week if that's helpful. May I suggest that ImagePath still be mapped as the object of a crm:P138i_has_representation predicate though? All our objects don't have IIIF-represented images and it'd be a shame to lose representation data about the ones that don't. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABB-qTrs5YjipSJiaJOkqOoK1DzyVhRnks5rkVrdgaJpZM4MZIHn>. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/american-art/ccma","title":"american-art/ccma","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in ***@***.*** in #12: I also would be very interested in seeing that stuff get mapped! I had intended IIIF_URL to be a IIIF identifier, but can change that to whatever makes sense for mapping. I also will have presentation manifests for those objects up sometime next week if that's helpful.\r\n\r\nMay I suggest that ImagePath still be mapped as the object of a crm:P138i_has_representation predicate though? All our objects don't have IIIF-represented images and it'd be a shame to lose representation data about the ones that don't."}],"action":{"name":"View Issue","url":"#12 (comment)"}}}

workergnome · 2017-03-11T01:24:48Z

@azaroth42: Do you have written down any of those notes from our discussion about possible ways to map IIIF to the CIDOC-CRM?

VladimirAlexiev · 2017-03-12T16:39:44Z

designforcontext/aac_review_tool#51 is the general issue for producing IIIF

VladimirAlexiev · 2017-03-12T17:06:03Z

@cbutcosk:

intended IIIF_URL to be a IIIF identifier, but can change that to whatever makes sense for mapping
http://iiif.museum.colby.edu/2013.003_001_cd.jpg

Better lose .jpg because that's not a JPG file. Either do this, or add a flag distinguishing deep-zoom (IIIF) from conventional images (eg JPG).

All our objects don't have IIIF-represented images: ImagePath still be mapped as crm:P138i_has_representation

Sure, it would be a pity to lose those. I propose the same Europeana mapping as you can see on the bottom left of this image from designforcontext/aac_review_tool#51:

<http://data.americanartcollaborative.org/ccma/object/4> 
  crm:P138i_has_representation
    <http://iiif.museum.colby.edu/2013.003_001_cd/full/full/0/default.jpg>.

<http://iiif.museum.colby.edu/2013.003_001_cd/full/full/0/default.jpg> a crm:E38_Image;
  svcs:has_service <http://iiif.museum.colby.edu/2013.003_001_cd>.

<http://iiif.museum.colby.edu/2013.003_001_cd> a svcs:Service;
  dct:conformsTo <http://iiif.io/api/image>.

  ## The rest is not needed in the semantic repo, since it's in info.json
  doap:implements     <http://iiif.io/api/image/2/level2.json> ,
    [ iiif:format    "webp" , "jpg" , "gif" , "png" ;
      iiif:quality   "gray" , "default" , "bitonal" , "color" ;
      iiif:supports  iiif:arbitraryRotationFeature , iiif:sizeAboveFullFeature , iiif:canonicalLinkHeaderFeature , iiif:profileLinkHeaderFeature , iiif:mirroringFeature , iiif:regionSquareFeature] ;
   exif:height         3072 ;
   exif:width          2308 .

For conventional images, it's quite simpler:

<http://data.americanartcollaborative.org/ccma/object/4> 
  crm:P138i_has_representation
    <http://iiif.museum.colby.edu/2013.003_001_cd.jpg>.

<http://iiif.museum.colby.edu/2013.003_001_cd.jpg> a crm:E38_Image.

VladimirAlexiev · 2017-03-12T17:09:15Z

@bsnikhila To implement this (I use $ to indicate variable interpolation as in perl):

if ImageUrl ends in \.(jpe?g|png) then emit

<$obj> crm:P138i_has_representation <$ImageUrl>. 
<$ImageUrl> a crm:E38_Image.

else emit

<$obj> crm:P138i_has_representation <$ImageUrl/full/full/0/default.jpg>.
<$ImageUrl/full/full/0/default.jpg> a crm:E38_Image; svcs:has_service <$ImageUrl>.
<$ImageUrl> a svcs:Service; dct:conformsTo <http://iiif.io/api/image>.

VladimirAlexiev · 2017-03-12T17:11:06Z

@workergnome Then you can query like this:

  ?obj crm:P138i_has_representation ?img.
  optional {?img svcs:has_service ?iiif. ?iiif dct:conformsTo <http://iiif.io/api/image>.}

azaroth42 · 2017-03-12T18:05:58Z

Unsurprisingly, we came up with a simpler approach that treats the Image API endpoint as a CRM Image. Image in CRM is an abstract concept, not necessarily a representation in the web architecture sense, which is fine for the service endpoint from which you can get images.

<https://linked.art/example/object/37> a crm:E22_Man-Made_Object ;
    rdfs:label "Sculpture" ;
    crm:P138i_has_representation <http://iiif.example.org/image/1> ;
    crm:P2_has_type <http://vocab.getty.edu/aat/300047090> .

<http://iiif.example.org/image/1> a crm:E38_Image ;
    rdfs:label "IIIF Image API for Sculpture" ;
    dcterms:conformsTo <http://iiif.io/api/image> .

cbutcosk · 2017-03-21T13:56:40Z

We just pushed a bunch of changes to our IIIF setup and our data, the fixed image links are in our most recent commit. The next time @bsnikhila runs the mapping we should be good on our end.

Per @VladimirAlexiev 's suggestion, our IIIF IDs now drop the file extension and internal suffix. They also point at larger images where they can, but an "is DZI?"-style flag isn't workable given our implementation. The IIIF endpoint and returns the right sizes/tile where it can so open sea dragon and/or @workergnome 's viewer should be hunky dunky.

VladimirAlexiev · 2017-03-21T15:23:38Z

Pragmatically speaking: IMHO restricting crm:P138i_has_representation to actual image URLs will make @workergnome's work simpler.

When he needs to display a lightbox (image grid): he can use the crm:P138i_has_representation URLs directly, no matter whether these are IIIF images or not
Then to activate deep zooming on an image, he'll check for the presence of dcterms:conformsTo.

Following @azaroth42's proposal, he'd need to examine dcterms:conformsTo and then tack /full/full/0/default.jpg to the end (but what if a particular museum has PNG not JPGs? What if it wants smaller than full size to be used for the "default rendition" of an image?)

Ontologically speaking, an image is different from a server that can return many transformations of that image, including parts thereof. It's true that crm:E38_Image is abstract, so you could interpret it as that whole family of images. But if I return one pixel from Mona Liza, you'd be hard-pressed to call that an image of Mona Liza!

azaroth42 · 2017-03-21T15:44:39Z

If the implementation cannot return a JPG, then it's not a valid IIIF implementation as the JPG format is mandatory at all conformance levels. And once you get to adding on parameters, that seems beyond the utility and expectations of modeling in CRM to me.

Another suggestion was to give application/ld+json;profile="..." as the dc:format of the IIIF endpoint, as that is what it should return (after a redirect). This is good too, and easily distinguishes from an image with dc:format of image/jpeg ... but IIIF needs to decide what URI to use for the JSON-LD profile in the media type. See: IIIF/api#1090

workergnome · 2017-03-21T15:53:01Z

I agree that the format is important. Either I should be able to assume that an id linked using P138i_has_representation will always be natively displayable in a web browser (which seems foolish), or there should be a way to filter on a consistent property those IDs with the correct format.

Speaking as a client, I'd much rather write switch statements based on results returned in dc:format, or sparql queries WHERE {?format IN ("image/jpeg", "image/png")} , then construct logic based around explicitly including and excluding things by OOB mappings.

bsnikhila · 2017-03-21T23:15:02Z

There are 2 fields: Image_Path (ends in jpg) and IIIF_URL (does not end in jpg). Which field should I consider for mapping? Or should I use both? Could you please tell me how I should map these and if I should do this for all museums (Note: other museums do not have the IIIF URL).

Tagging @jainn3 too because he is using this data.

workergnome · 2017-03-22T00:31:25Z

image_path should be mapped as a standard image.

The one without should be mapped so:

<IIIF_URL> a crm:E38_Image ;
    rdfs:label "a meaningful label if provided" ;
    dcterms:conformsTo <http://iiif.io/api/image> .

cbutcosk · 2017-03-27T15:33:19Z

The commit I made just now includes a "Label" field in the array of images associated with an object for the <IIIF_URL> rdfs:label "Label" part of the mapping. Not a ton of meaningful data in there currently (though some sculptures include a "3/4 view" label), but updated labels should come soon.

bsnikhila · 2017-03-29T02:22:23Z

Discussed with @caknoblock today. We are generating the manifest files for all museums' image data, including for CCMA. Is it required for me to map the IIIF URLs here or will the manifest files do?
(CCMA is the only museum that has the IIIF URLs.)

VladimirAlexiev · 2017-03-29T07:11:14Z

@caknoblock If only CCMA has IIIF (deep zoom) images, why do you need manifests for the other museums? Plain image URLs are enough.

@cbutcosk CCMA had manifests (see first URL in this issue) but I can't find them now. checked these URLs

cbutcosk · 2017-03-29T12:44:11Z

@VladimirAlexiev Use the updated URLs/Identifiers from the JSON I pushed a few days ago and you should be good, eg:

@bsnikhila & @caknoblock I think it may be useful to map these images the way already outlined in this issue if you're looking to generate Presentation manifests for all museums--resources backed by servers that speak the Image API have a service key that need the image identifier as its @idAFAIK.

VladimirAlexiev · 2017-03-29T13:30:52Z

Confirming the above work ok. https://iiif.museum.colby.edu/image/2013.003_001 redirects to
https://iiif.museum.colby.edu/image/2013.003_001/info.json that has the image info.
https://iiif.museum.colby.edu/image/2013.003_001/full/full/0/default.jpg returns the image.

Charlie, do you mean a manifest describing all the images of a museum? That could be useful to @workergnome. For an example, go to http://projectmirador.org/demo/, click left dropdown, select Yale, click right dropdown, select Gallery, and the result is:

This is the same image as described by ResearchSpace in 2014: https://confluence.ontotext.com/display/ResearchSpace/Yale+Mapping+Problems#YaleMappingProblems-ImageViews.
Other collections at http://projectmirador.org/demo/ have images of different sizes, and it shows the viewer can lay them out nicely.

workergnome · 2017-03-29T14:01:54Z

@VladimirAlexiev: The image API will give us access to metadata that will enable Deep Zoom, and thumbnails, and things like that.

Manifests and the Presentation API will give us the ability to associate metadata with the images, to group related images, and to make using and sharing these images more powerful. They're orthogonal, so we can have a presentation API for a non-deep-zoom image, and we can use the Image API without a manifest, but they're most powerful when you have both.

workergnome · 2017-03-29T14:02:43Z

@bsnikhila—if an institution has their own, published manifests, it's probably best to use those.

jainn3 · 2017-04-04T21:54:16Z

We can extract image_url prefix (https://iiif.museum.colby.edu/image/1995.151_001) from the image url itself (https://iiif.museum.colby.edu/image/1995.151_001/full/full/0/default.jpg) and use it as service id in the manifest file. We will do this using the python script and put in the manifest file.

VladimirAlexiev mentioned this issue Mar 10, 2017

URIs to images? american-art/acm#2

Open

cbutcosk mentioned this issue Mar 29, 2017

Image URLs drop commas #20

Closed

cbutcosk mentioned this issue Apr 27, 2017

Map IIIFManifests #30

Open

cbutcosk added the enhancement label Apr 30, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

map CCMA IIIF images #12

map CCMA IIIF images #12

VladimirAlexiev commented Mar 10, 2017

cbutcosk commented Mar 10, 2017 •

edited

Loading

caknoblock commented Mar 10, 2017 via email

workergnome commented Mar 11, 2017

VladimirAlexiev commented Mar 12, 2017

VladimirAlexiev commented Mar 12, 2017

VladimirAlexiev commented Mar 12, 2017 •

edited

Loading

VladimirAlexiev commented Mar 12, 2017

azaroth42 commented Mar 12, 2017

cbutcosk commented Mar 21, 2017

VladimirAlexiev commented Mar 21, 2017

azaroth42 commented Mar 21, 2017

workergnome commented Mar 21, 2017

bsnikhila commented Mar 21, 2017

workergnome commented Mar 22, 2017

cbutcosk commented Mar 27, 2017

bsnikhila commented Mar 29, 2017

VladimirAlexiev commented Mar 29, 2017

cbutcosk commented Mar 29, 2017

VladimirAlexiev commented Mar 29, 2017

workergnome commented Mar 29, 2017

workergnome commented Mar 29, 2017

jainn3 commented Apr 4, 2017

map CCMA IIIF images #12

map CCMA IIIF images #12

Comments

VladimirAlexiev commented Mar 10, 2017

cbutcosk commented Mar 10, 2017 • edited Loading

caknoblock commented Mar 10, 2017 via email

workergnome commented Mar 11, 2017

VladimirAlexiev commented Mar 12, 2017

VladimirAlexiev commented Mar 12, 2017

VladimirAlexiev commented Mar 12, 2017 • edited Loading

VladimirAlexiev commented Mar 12, 2017

azaroth42 commented Mar 12, 2017

cbutcosk commented Mar 21, 2017

VladimirAlexiev commented Mar 21, 2017

azaroth42 commented Mar 21, 2017

workergnome commented Mar 21, 2017

bsnikhila commented Mar 21, 2017

workergnome commented Mar 22, 2017

cbutcosk commented Mar 27, 2017

bsnikhila commented Mar 29, 2017

VladimirAlexiev commented Mar 29, 2017

cbutcosk commented Mar 29, 2017

VladimirAlexiev commented Mar 29, 2017

workergnome commented Mar 29, 2017

workergnome commented Mar 29, 2017

jainn3 commented Apr 4, 2017

cbutcosk commented Mar 10, 2017 •

edited

Loading

VladimirAlexiev commented Mar 12, 2017 •

edited

Loading