map CCMA IIIF images - Githubissues

VladimirAlexiev commented 7 years ago

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. https://github.com/american-art/aac_mappings/issues/51 raises this issue: @workergnome and @azaroth42, can you add that mapping?

cbutcosk commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 https://github.com/american-art/ccma/issues/12#issuecomment-285678975, 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 GitHub","url":"https://github.com/american-art/ccma"}},"updates":{"snippets":[{"icon":"PERSON","message":"@cbutcosk 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":"https://github.com/american-art/ccma/issues/12#issuecomment-285678975"}}}

workergnome commented 7 years ago

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

VladimirAlexiev commented 7 years ago

https://github.com/american-art/aac_mappings/issues/51 is the general issue for producing IIIF

VladimirAlexiev commented 7 years ago

@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 https://github.com/american-art/aac_mappings/issues/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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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/iiif.io#1090

workergnome commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

jainn3 commented 7 years ago

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.

american-art / ccma

map CCMA IIIF images #12