- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Fri, 10 Aug 2012 09:57:03 +0100
- 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 UTC