image vs image-info URL and type

[VladimirAlexiev]

#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]

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

• http://cona-images.getty.edu/iiif/12345.json
• http://cona-images.getty.edu/iiif/12345 with Accept header JSON or JSONLD
• http://cona-images.getty.edu/iiif/12345.ttl
• http://cona-images.getty.edu/iiif/12345 with Accept header text/turtle

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]

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]

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]

The proposal seems to be a hugely breaking change, so I'm 👎 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:

• iiif:Image (the baseURL not the fully parameterized URL to image representation)
• iiif:Tile
• iiif:Size
• iiif:ImageProfile (see 2.1's section 5.3 ... we've already started down this road)
• dctypes:Image / schema:ImageObject (as the type for logo, thumbnail)

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

[VladimirAlexiev]

• I think conneg is the key. If I ask for JSON, JSONLD, Turtle, RDF... then obviously I want the info not the tiles, so the base URL could return it.
• Let's not forget issue iiif:Image or not? #623 which is currently closed but I think doesn't answer the original issue.
• I'm offering my help to create such ontology. The simpler the better.
• Deferring for the longer term is the right course

[jpstroop]

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

👍 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 😎.