Using oa:SpecificResource with oa:hasTarget

In our experimentation with the Open Annotation data model, some questions
about best practices with regard to describing annotation targets have come
up. These are (in part at least) about making choices between OA-compliant
options for describing a given annotation. Which options are generally best
in which circumstances? I'd be interested in comments, suggestions and
feedback from others experimenting with the data model.

 

Consider the description of an annotation having as its target a region of a
Web-accessible image. In this case the annotation target is a segment of
page image 9 (counting from cover) from a digitized copy of "Emblematum
Sacrorum Quorum..."
(http://hdl.handle.net/10111/UIUCOCA:duodeksemblema00saub). Assume that the
annotator/annotation tool is making use of our local djatoka service at
Illinois to view the JP2 image and determine pixel box of the region of
interest.  Ignoring details to do with the annotation body and with part of
relationships between page image and the book as a whole, the description of
such an annotation might be expressed as:

 

<http://example.org/myAnnotation1> a oa:Annotation ;

        oa:hasBody <...> ;

        oa:hasTarget
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/J
P2Processed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegio
n&svc_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jp2&svc.region=
890,700,200,150>
&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Pr
ocessed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegion&sv
c_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jp2&svc.region=890,
700,200,150> .

 

1.       Providing oa:hasSource and oa:hasSelector:

 

The lengthy URI of the target is djatoka-service specific and so not all
that helpful to non-djatoka applications that might encounter this
annotation trolling for annotations of the page image involved. This
suggests that at a minimum, it might be more useful to express this
annotation target as an oa:SpecificResource having a W3C Media Fragment
selector, e.g.:

 

<http://example.org/myAnnotation1> a oa:Annotation  ;

        oa:hasBody <...>  ;

        oa:hasTarget <urn:uuid:11111...> .

 

<urn:uuid:11111...> a oa:SpecificResource;

        oa:hasSource
<http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Processed
/duodeksemblema00saub_0009.jp2> ;

        oa:hasSelector < urn:uuid:22222...> .

 

<urn:uuid:22222...> a oa:FragmentSelector ;

        rdf:value "xywh=pixel:890,700,200,150" .

 

First question - the current draft of OA core spec (section 4.4) says, "The
Specific Target is typically identified by a URN, as an HTTP URI would imply
that the exact nature of the Specific Target was available to retrieve by
dereferencing the HTTP URI." In this case, of course, the region of the
image wanted can be retrieved via the djatoka URL given above. This suggests
the possibility of using the URL as the identifier of the target, i.e.,
instead of using <urn:uuid:11111...>. You would then get something like: 

 

<http://example.org/myAnnotation1> a oa:Annotation  ;

        oa:hasBody <...>  ;

        oa:hasTarget
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/J
P2Processed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegio
n&svc_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jp2&svc.region=
890,700,200,150>
&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Pr
ocessed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegion&sv
c_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jp2&svc.region=890,
700,200,150> .

 

<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/J
P2Processed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegio
n&svc_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jp2&svc.region=
890,700,200,150>
&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Pr
ocessed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegion&sv
c_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jp2&svc.region=890,
700,200,150>  a oa:SpecificResource;

        oa:hasSource
<http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Processed
/duodeksemblema00saub_0009.jp2> ;

        oa:hasSelector < urn:uuid:22222...> .

 

<urn:uuid:22222...> a oa:FragmentSelector ;

        rdf:value "xywh=pixel:890,700,200,150" .

 

But this raises questions.
<http://djatoka.grainger.illinois.edu/adore-djatoka...region=890,700,200,150
> is a oa:SpecificResource in the context of my annotation, but is that
statement and the oa:hasSource and oa:hasSelector statements about the image
fragment okay in regard to this resource in other contexts?  I would argue
(tentatively) yes, but it gets a little fuzzier if someone reuses this same
djatoka URL as the URI of a oa:specificResouce target in another annotation
and attaches an oa:hasStyle triple not appropriate in the context of my
annotation. There's also the possibility that some consuming applications
might not bother to examine the oa:hasSource and oa:hasSelector statements
(okay for some purposes, but not all). Having a readily de-referenceable URI
as the object of oa:hasTarget seems convenient, but in the case of an
oa:Specific Resource, is it viable even in this very basic example? 

 

2.       Adding oa:hasState

 

Of course, a user / client application trying to view the annotation given
above might prefer to fetch the image fragment not as a fragment of an
image/jp2 file, but rather as fragment of an image/jpeg. Djatoka is
perfectly able to accommodate:

 

<http://example.org/myAnnotation1> a oa:Annotation ;

        oa:hasBody <...> ;

        oa:hasTarget
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004
<http://djatoka.grainger.illinois.edu/adore-djatoka/resolver?url_ver=Z39.88-
2004&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/J
P2Processed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegio
n&svc_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jpeg&svc.region
=890,700,200,150>
&rft_id=http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Pr
ocessed/duodeksemblema00saub_0009.jp2&svc_id=info:lanl-repo/svc/getRegion&sv
c_val_fmt=info:ofi/fmt:kev:mtx:jpeg2000&svc.format=image/jpeg&svc.region=890
,700,200,150> .

 

So, my second question is about best practice for adding oa:hasState
property to my oa:SpecificTarget - this is left open (i.e., to be dealt with
later) in the current draft of the OA extension namespace. For this example,
assume that the page image in question is available from a service that can
do content negotiation, e.g.:

 

Assume that de-referencing the URI: 

 
http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Processed/
duodeksemblema00saub_0009

 

can get you different representations of the page image - e.g., image/jp2,
image/jpeg, or image/png - in accord with how you have your Accept: header
(Content-Type) set. 

 

The user or client application might want to know this, or at least might
want to know that the annotator was annotating the image/jpeg rather than
the image/jp2. How should this State information be expressed? Is specifying
the MIME type header on its own reasonable, or when talking about State do
we expect implementers to be more specific? In other words is State mostly
about oa:when and specifying values for HTTP Accept headers, or something
more? Assuming proper binding of ex: to a namespace, consider this variant
of the above illustration:

 

<http://example.org/myAnnotation1> a oa:Annotation  ;

        oa:hasBody <...>  ;

        oa:hasTarget <urn:uuid:11111...> .

 

<urn:uuid:11111...> a oa:SpecificResource;

        oa:hasSource
<http://emblemimages.grainger.illinois.edu/duodeksemblema00saub/JP2Processed
/duodeksemblema00saub_0009 > ;

        oa:hasSelector < urn:uuid:22222...> ;

        oa:hasState <urn:uuid:33333...> .

 

<urn:uuid:22222...> a oa:FragmentSelector ;

        rdf:value "xywh=pixel:890,700,200,150" .

 

<urn:uuid:33333...> a oa:State ;

        oa:cachedSource <...> ;

        ex:acceptContent-Type "image/jpeg" .

 

The main question here has to do with the scope of oa:hasState and what is
the right way to express that you are annotating a representation of a
particular content-type that should be retrieved using content negotiation. 

 

What are the issues to adding semantics to the OA extension namespace to
handle the standard HTTP Accept headers (Accept, Accept-Language,
Accept-Encoding, Accept-Charset, leaving off the Accept-Datetime as too
close to oa:when)? Does the scope of oa:hasState need to be broader?

 

3.       Pseudo-Fragment Identifiers

 

Finally there's a potential 3rd issue here of whether a community that makes
extensive use of djatoka would be well advised to extend the OA namespaces
with a property(ies) in the community namespace that basically just treats
the djatoka OpenURL query string (excluding rft_id value) as analogous to a
kind of fragment identifier. Wouldn't be informative to any applications not
familiar with djatoka, but it's so obvious, I wonder if it's going to be
suggested fairly quickly. If not for djatoka then for something even better
suited to this approach, e.g., the IIIF Image API
(http://library.stanford.edu/iiif/image-api/). Not altogether
coincidentally, the IIIF approach is 1:1 mappable to djatoka OpenURL model.
Should this be encouraged or discouraged?

 

Thanks for any comments / feedback.

 

Tim Cole

University of Illinois at UC