search

IIIF / api

Source for API and model specifications documents (api and model)
http://iiif.io/api
107 stars 54 forks source link

image vs image-info URL and type #631

Closed VladimirAlexiev closed 8 years ago

VladimirAlexiev commented 8 years ago

623 wonders whether {scheme}://{server}{/prefix}/{identifier}/info.json should return "@type": "iiif:Image" or not.

This issue wonders whether there should be 1 or 2 URLs, what should be the link between them, and how the statements should be distributed between them. I'm mapping Getty CONA images. Assume that http://cona-images.getty.edu/iiif/ is an IIIF server. Currently I've made these statements (in turtle):

<http://cona-images.getty.edu/iiif/12345> 
  ### "free" description (DC/DCT/DCTypes)
  a dctype:StillImage;
  dc:identifier "12345";
  dc:title "View of St Peters basilica at sunset";
  dc:description "The dome practically shines";
  dc:rights "(C) Getty Museum, photography John Smith";
  ### IIIF description
  a iiif:Image;
  exif:height 4000;
  exif:width 6000;
  doap:implements <http://iiif.io/api/image>;
  dct:conformsTo <http://iiif.io/api/image/2/level0.json> .

I'm happy with this but http://iiif.io/api/image/2.0/#image-information requires the latter group of statements to be returned by http://cona-images.getty.edu/iiif/12345/info.json. The question is, should they also be also attached to such URL? CoolURIs says "don't use extension in semantic URLs", and it's good to link the two nodes with a relation, so it becomes eg:

<http://cona-images.getty.edu/iiif/12345> 
  a dctype:StillImage, iiif:Image;
  dc:identifier "12345";
  dc:title "View of St Peters basilica at sunset";
  dc:description "The dome practically shines";
  dc:rights "(C) Getty Museum, photography John Smith";
  wdrs:describedby <http://cona-images.getty.edu/iiif/12345/info>.

<http://cona-images.getty.edu/iiif/12345/info>
  a iiif:ImageInfo;
  exif:height 4000;
  exif:width 6000;
  doap:implements <http://iiif.io/api/image>;
  dct:conformsTo <http://iiif.io/api/image/2/level0.json> .

I'm not fond of complexity: neither wdrs:describedby, nor using two types iiif:Image vs iiif:ImageInfo, nor using two nodes... I'd be happier to stick with the first (simple) variant.

But is it ok if http://cona-images.getty.edu/iiif/12345/info.json returns statements about http://cona-images.getty.edu/iiif/12345 ?

VladimirAlexiev commented 8 years ago

Is it an option to say that all these should return image info rather than tiles?

I bet it is not, since existing IIIF servers and clients conform to the /info.json URL, and expecting them all to change would be unrealistic.

jpstroop commented 8 years ago

FWIW (as the other eds know), I've never been happy with the spec recommending that the base URI, as we call it in the spec, e.g. http://cona-images.getty.edu/iiif/12345, return the info.json.

jpstroop commented 8 years ago

It could be a RESTful endpoint for doing CRUD with the server, you could conneg for info or the source image (out of scope for the API, but it's been discussed as an extension), other serializations of the info....

azaroth42 commented 8 years ago

The proposal seems to be a hugely breaking change, so I'm :-1: and suggest defer. There's nothing that prevents conneg for alternate serializations, but there's no use case that requires them, and we don't want to have to explain RDF to people looking just to implement an image server. That's the beauty of JSON-LD :)

A non-breaking change would be to enumerate OPTIONAL types for all of the resources in the response structure:

This would also close #523 if we had an rdfs/owl ontology doc as well.

VladimirAlexiev commented 8 years ago
jpstroop commented 8 years ago

One big IIIF ontology seems like a good idea in general (building out updating/replacing /api/presentation/2/ontology.xml).

:+1: to deferring and doing properly when we're ready for a breaking release. But I strongly agree that we shouldn't lose sight of the fact that most image API consumers don't care that the info.json is RDF/LD in disguise :sunglasses:.