IIIF @id in the context of RDF and LinkedData

[Markus Enders]

Hi all,

 

I would like to understand a bit how IIIF and linked data are supposed to work together. My understanding of linked data and the underlying RDF is that every subject of an RDF statement must be identifyable by a URI or a blank node.

My understanding is that theoretically every IIIF-object may or may not have an @id “element” in JSON. RDF does not specify whether a resource should be retrievable by its URI. For LinkedData however this is different.

My questions are:

• -          Which IIIF elements must have @id?
  
• -          Which of the URIs in @id must be resolvable?
  
• -          What does this URI need to retrieve? My understanding is that when requesting a particular canvas, only the canvas would be returned, not the manifest.json.
  

The table below shows my current understanding – I assume it is incorrect, so please correct.

 

Annotation Type	@id element	Allowed URI schemas in @id	URI resolvable	Retrievable Objects
Manifest	mandatory	http / https	mandatory	Manifest.json
Sequence	optional	any	optional	The sequence object with all child objects (embedded)
Canvas	mandatory	http / https	mandatory	The canvas object with all child objects (embedded)
Oa:annotation with motivation sc:painting	optional	any	optional	???
Resource (Image)	mandatory	http / https	mandatory	The actual (image) resource
Service (for Images)	Mandatory, if IIIF image service exists	http / https	Mandatory, if applicable	JSON structure of IIIF Image Service Information request
Range	optional	any	optional	The range object with all child objects (embedded)

 

 

It would be great to receive some comments. Especially as many users will not have a Triple-Store, I am wondering what different systems are actually providing. Otherwise I think it would be great if the spec could clarify and consolidate this information (maybe in a similar table as above).

 

Ciao

Markus

 

[Robert Sanderson]

Hi Markus,

Sorry for not getting back on this one earlier and thanks for bringing it back to light on the call.

My thoughts inline below:

I would like to understand a bit how IIIF and linked data are supposed to work together. My understanding of linked data and the underlying RDF is that every subject of an RDF statement must be identifyable by a URI or a blank node.

Yes.

 

My understanding is that theoretically every IIIF-object may or may not have an @id “element” in JSON. 

Also correct.  "@id" may be used for any object to give it an identifier, and that identifier must be a URI.

 

RDF does not specify whether a resource should be retrievable by its URI.

Yes.

 

For LinkedData however this is different.

Yes. Linked Data adds the recommendations that the URIs that we use to identify entities be HTTP URIs and that those URIs should provide information about the entity when it is dereferenced.

 

My questions are:

• -          Which IIIF elements must have @id?
  
• -          Which of the URIs in @id must be resolvable?
  
• -          What does this URI need to retrieve? My understanding is that when requesting a particular canvas, only the canvas would be returned, not the manifest.json.

Great questions and I think we should include this table in an appendix in the next version of the specification.   We could maintain it in a note for the mean time.

Overall, any time there's an optional URI, I think it would still be recommended that the URI be http[s] and that the URI be resolvable.  We should follow best practices of the web architecture, but we shouldn't require implementations to do things anything more than is necessary to achieve the minimal desired results.  

My interpretation of the specification in these regards:

Manifest:  mandatory / http[s] / mandatory / the manifest with embedded objects per the spec

Sequence:  There are two situations.  The regular case where there's only one sequence for a manifest which is as you have:

    optional / any / optional / sequence with all embedded objects

And the infrequent case of multiple sequences:

    mandatory / http[s] / required / sequence with all embedded objects

We should have a fixture object as an example of this, rather than relying on the text description for Sequence.

Canvas:  Mandatory / http[s] / Optional / Canvas object with embedded children

The Canvas MUST have a URI in order to be the target of annotations.

It MUST be http[s] so that we can be certain the URI scheme allows fragments, so we can use the #xywh=1,2,3,4 pattern.  But as the content will be in the manifest, it's not really required to dereference a canvas separately.  

Annotation:  Optional / Any / Optional / the annotation using the IIIF context. 

This gets a little bit fuzzy as well with the Open Annotation context being different to the IIIF context (and the Web Annotation WG context will be slightly different again for the same structure).  But in essence you should return the content as per the example in section 6.4: http://iiif.io/api/presentation/2.0/#image-resources

And the same for commentary annotations.

Image:  Mandatory / http[s] / Mandatory / The image :)

Service:  mandatory / http[s] / mandatory / Following the Image API, the base URI of the image service should return the info.json content, and it should be a 303 to info.json.  This is at the end of section 2:  http://iiif.io/api/image/2.0/#uri-syntax

Range: optional / any / optional / Range with embedded objects.

And the other types:

Collection:  Mandatory / http[s] / Mandatory / The collection with optionally embedded collections and minimal manifest descriptions -- the manifests can include top level metadata, but must not include the sequences or ranges.  

Layer:  optional / any / optional / Layer with references only to annotationLists

AnnotationList:  Mandatory / http[s] / Mandatory / The list of annotations embedded.

 It would be great to receive some comments. Especially as many users will not have a Triple-Store, I am wondering what different systems are actually providing. Otherwise I think it would be great if the spec could clarify and consolidate this information (maybe in a similar table as above).

Stanford is in the process of building out its infrastructure to be 2.0 compatible.  At the moment we're only generating Manifests, though collections are high on the to-do list.

We're not using a triplestore for it, just generating from existing descriptions.

Hope that helps!

Rob 

--

Rob Sanderson

Technology Collaboration Facilitator

Digital Library Systems and Services

Stanford, CA 94305