Re: Using JP2000 images as bodies/targets of annotations

We do a kind of hybrid of 1 and 2, where the body is a full image but links
to the service.  Then a regular client will get something back that it can
use, but a client that's aware of the service can use it to fetch tiles.

So:

<anno1> a oa:Annotation ;
  oa:hasBody <http://www.example.org/iiif/image/full/full/0/native.jpg> ;
  oa:hasTarget <canvas1> .

<image1.jpg> a dctypes:Image ;
  sc:hasRelatedService <http://www.example.org/iiif/image/> .

<canvas1> a sc:Canvas ;
  exif:height 1000 ;
  exif:width 700 .


The trickier bit (to me) is how to represent annotations on the tile-able
image, in terms of how to express the segments.  You need to know, in the
client, the full size of the image rather than the current representation.
Or you need to record the current size and segments relative to that, and
allow the client to scale both up and down.

Hope that helps :)

Rob



On Tue, Jun 18, 2013 at 3:00 PM, James Smith <jgsmith@gmail.com> wrote:

> This might also be relevant for Shared Canvas, but I figured the basic
> idea is more Open Annotation than Shared Canvas.
>
> We're building out a Shared Canvas digital facsimile edition of Shelley's
> Frankenstein notebooks (among other of her family's papers). Our grant
> requires that we use scalable images for the page scans (e.g., something
> like OpenSeadragon). We've settled on JP2000 and djatoka for providing the
> tiles.
>
> The result is that we aren't annotating the canvas with a single zoom
> level, pixel density, etc., version of the image, but with the JP2000 image
> assuming that the client will select the appropriate pixel density and
> tiling for the given view window onto the canvas.
>
> If we were assuming that only a single zoom level was annotating the
> canvas, we'd be done simply by using the appropriate URL to retrieve the
> full image at the right size.
>
> Instead, we want to construct an annotation that has the JP2000 image as
> the body, but not restrict the rendering to a particular version of the
> JP2000 image. We can think of two ways to do this.
>
> (1) Construct an annotation with the body's specific resource being a URL
> that retrieves the JP2000 image in some other format by referencing a
> djatoka server in the URL. This does not seem to fit the intent of the
> annotation, but allows current browsers with no knowledge of JP2000 to
> gracefully degrade. It does require a djatoka-aware viewer to parse the
> URL, which seems counter to how we want linked data to work.
>
> <anno1> a oa:Annotation ;
>   oa:motivatedBy sc:painting ;
>   oa:hasBody <content1> ;
>   oa:hasTarget <canvas1> .
>
> <canvas1> a sc:Canvas ;
>   exif:height 1400 ;
>   exif:width 1000 ;
>   rdfs:label "Page 1" .
>
> <image1> a dctypes:Image ;
>   dc:format "image/jpeg" .
>
> (with <image1> being a URL constructed to return a particular rendering of
> a JP2000 through djatoka).
>
> (2) Construct an annotation with the body's specific resource being the
> URL of the JP2000 image with an additional property pointing to the djatoka
> server that can be used to retrieve various versions of the image. This
> does not require special parsing of URLs, but won't work if a browser
> doesn't understand JP2000.
>
> <anno1> a oa:Annotation ;
>   oa:motivatedBy sc:painting ;
>   oa:hasBody <content1> ;
>   oa:hasTarget <canvas1> .
>
> <canvas1> a sc:Canvas ;
>   exif:height 1400 ;
>   exif:width 1000 ;
>   rdfs:label "Page 1" .
>
> <image1> a oa:SpecificResource ;
>   dc:format "image/jp2" ;
>   oa:hasSource <source1> ;
>   sc:hasRelatedService <djatokaService1> .
>
> I'm leaning towards (2) because it's cleaner from a LoD perspective even
> if the browser doesn't work quite right. In this case, the question is
> which property should indicate the recommended djatoka server? Shared
> Canvas as a sc:hasRelatedService property, but I'm wondering if there's
> something more appropriate that people have used already.
>