Re: Using oa:SpecificResource with oa:hasTarget

On Thu, Jul 5, 2012 at 3:40 PM, Tim Cole <t-cole3@illinois.edu> wrote:

> 1.       Providing oa:hasSource and oa:hasSelector:
[...]
> 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?

That depends on what you mean by "okay", I think :)
If you're willing to risk that other people might also separately
annotate exactly the same region as you, and the system would generate
the same specific resource URI for all of the annotations.  If the
only thing that the system will do is allow selection, that's fine.
If it also allows style or state, then these will be inherited across
all of the annotations, which is probably not okay.

A dereferencable URI could be made unique by appending a unique
#fragment on the end, such as the identifier for the annotation.  It
certainly wouldn't make the djatoka OpenURLs any less readable ;)



> 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.
> So, my second question is about best practice for adding oa:hasState
> property to my oa:SpecificTarget
> 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?

The scope of State is to enable the consuming application to be able
to discover and retrieve the correct representation of the resource
for the annotation.  Thus accept headers are definitely something that
needs to be available.  How to specify these is open for suggestions,
existing standards of course preferred :)



> 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?

It seems like a use for a generic and universally understood Selector
(eg FragmentSelector) and an alternative of a community specific
Selector (IIIFSelector, DjatokaSelector)

Then the community's applications can use the more functional but less
generic approach without losing the semantics for other applications.

And, to avoid a "me too" post, I agree with everything that Jim said
in his response as well.

HTH,

Rob

Received on Friday, 6 July 2012 15:08:21 UTC