W3C home > Mailing lists > Public > public-openannotation@w3.org > August 2012

Re: Selection Filtering

From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Date: Fri, 10 Aug 2012 09:57:03 +0100
Message-ID: <CAPRnXt=XLNEoCGc-L547E0U2Q7tiDE=pRjZnrLetsUqjGkNKuw@mail.gmail.com>
To: Robert Sanderson <azaroth42@gmail.com>
Cc: Paolo Ciccarese <paolo.ciccarese@gmail.com>, James Smith <jgsmith@gmail.com>, public-openannotation <public-openannotation@w3.org>
On Thu, Aug 9, 2012 at 11:13 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> Does the hasContext approach (eg climbing up rather than drilling
> down) deal with situations when there's really embedded content, or
> only resources that are referenced but have their own unique URIs?
>
> For example, the use case I have in mind is an ePub document
> (basically a zip file that contains HTML and related content) that has
> a URI, but the chapter xhtml files within it do not.  And similarly
> the images referenced from those chapters don't have their own URIs,
> they're just named bitstreams within the zip.
>
> I don't immediately see it, if it does.  And if not, how would we go
> about providing a solution for the use case?

They *could* have a URI constructed for them, but it would be
something quite specific, similar to Java's jar: protocol (which
actually would work with ePubs, as they are ZIPs):

jar:http://example.com/ebook.epub!/path/within/archive/page.html
jar:http://example.com/ebook.epub!/path/within/archive/picture.jpeg


But I take your argument; there are many compound resources where we
want to refer to things inside it, and then things inside that inner
compound resource again.


So why not just a chain of specific resources?

:aboutPictureOnPage a oa:Annotation ;
  oa:hasTarget :pictureOnPage .

:pictureOnPage a oa:SpecificResource ;
  oa:hasSelector :somePictureSelector ;
  oa:hasSource :page .

:page a oa:SpecificResource ;
  oa:hasSelector :somePageSelector ;
  oa:hasSource <http://example.com/ebook.epub> .

I am not too keen on this, because here oa:hasSource suddenly goes to
an 'abstract' resource, and given <http://example.com/ebook.epub> it
would be much harder to find annotations on anything inside it.  This
could however be sane when a specific resource also has a URL (which
now that we moved hasStyle is kind of OK), and you can't decide which
is the top level:


:aboutPictureOnPage a oa:Annotation ;
  oa:hasTarget <http://example.com/ebook/page25/image.jpeg> .

<http://example.com/ebook/page25/image.jpeg> a oa:SpecificResource ;
  oa:hasSelector :somePictureSelector ;
  oa:hasSource <http://example.com/ebook/page25/> .

<http://example.com/ebook/page25/> a oa:SpecificResource ;
  oa:hasSelector :somePageSelector ;
  oa:hasSource <http://example.com/ebook/> .





I thought I would prefer the oax:hasContext (we can make it allowed to
be chained to other oa:SpecificResource's) - here I try to make an
example of multiple layers:

Multi-layer contexts:

:aboutAreaOfPictureOnPage a oa:Annotation ;
  oa:hasTarget :areaOfPictureOnPage .

:areaOfPictureOnPage a oa:SpecificResource ;
  oa:hasSelector :someSvgSelector ;
  oax:hasContext :pictureOnPage ;
  oa:hasSource <http://example.com/ebook.epub> .


:pictureOnPage a oa:SpecificResource ;
  oa:hasSelector :somePictureSelector ;
  oax:hasContext :page ;
  oa:hasSource <http://example.com/ebook.epub> .

:page a oa:SpecificResource ;
  oa:hasSelector :somePageSelector ;
  oa:hasSource <http://example.com/ebook.epub> .


This has some problems. For instance :areaOfPictureOnPage might look
like just running an SVG Selector on the epub archive. This would not
work - but for some combinations of selectors and source it could look
like it works, like an xpath selector on the XHTML embedded as text
within an XML which is also selected on with xpath.

So for the hasContext approach, we would also need to add something
like a oa:hasState [ a oax:ContextState ]  to prevent that
interpretation.  Then the oax:hasContext could be stated in there
instead of in the oa:SpecificResource.


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
Received on Friday, 10 August 2012 08:57:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 10 August 2012 08:57:52 GMT