- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Wed, 18 Jul 2012 18:09:10 +0200
- To: Christian Morbidoni <christian.morbidoni@gmail.com>
- Cc: public-openannotation@w3.org
On Wed, Jul 18, 2012 at 3:45 PM, Christian Morbidoni <christian.morbidoni@gmail.com> wrote: > Dear Robert, all, > as you suggested...here I'am with asking for some clarifications :-) :) > 1) We are using xpointers and would like to model using Fragment Selectors, > however we also would like to support different kinds of media fragments > (e.g. video, images, etc.). So we would need to have specializations as > subclasses of oa:FragmentSelector, e.g. pundit:XPointerFragmentSelector And to be explicit that the fragment is an XPointer, rather than a Media Fragment, an HTML fragment or some other type of fragment? Without inspecting the contents and using some sort of clever fragment parser, it seems impossible to know which fragment specification is being used. I think this is a very good point. Like Paolo, I'm not averse to subclassing FragmentSelector to be more specific. > 2) Instead of having FragmentSelectors as resources wouldn't it make sense > to model like this ? > :fragment :hasXPointerFragmentSelector "fragment" . > :fragment :hasSource <http://exmaple.org/page1.html> . > It would be a more compact representation and I see no big drawbacks. We've tried to avoid using many different relationships to reduce the implementation load. It seems easier (at least to us!) to test a class than to iterate through a long list of possible relationships. > 3) Is there a standard way to represent collections of annotations (in > Pundit we are calling them notebooks)? Should I use ORE Aggregations? I'm > not sure it is exactly what I need.. do you know if someone faced this > issue? ORE Aggregations would definitely be one way. We have used that approach in the Shared Canvas work, combined with rdf:List to indicate order of the aggregated resources. Links: http://www.openarchives.org/ore/ http://www.shared-canvas.org/ I don't think that we should formally recommend this in the specification however, it seems to be out of scope for an annotation specification to talk about the higher levels of collections, though an issue that will be very common, so a related best practices document seems to be in order. Perhaps we could start that in the wiki? > 4) In Pundit we assume a web page can include what we call "named contents", > that are atomic, granular pieces of content that can have identifiers ( > resolvable URLs). Think about a page that is divided in paragraphs. A web > representation of that page can include a number of paragraphs and > explicitly mark them up specifying identifiers (URLs) for each of them. Then > you could have a different page where some of the paragraphs appears, > perhaps mixed with other content (e.g. commentary, or text taken from other > sources, etc.). You can read more at http://thepund.it/client.php under > "Play nice with Pundit". > In practice we are using such named contents as targets of our annotations > (instead of the URL of the enclosing web page), so that we are able to show > annotations in whatever web page includes those named contents, and > furthermore, allows us to correctly display the annotation even if the HTML > around a named content changes. However, we also want an annotation to > remember the enclosing web page (containing the named content) where it has > been created. To this end we are using a pundit:hasPageContext relation. > ... I know this is a bit tricky and I hope I succeeded in explaining it :-) > Do you think this could be relevant to open annotation? Is it covered by the FragmentSelector and hasSource in place of hasPageContext, and the element id as the object of the rdf:value property? Or if that's not appropriate, then a new selector with the named section and the html page linked to the specific resource. Perhaps I'm misunderstanding the exact nature of the named target? One thing I would avoid doing is using the named target as the identifier for the specific resource, in case people annotate it with State (to capture a particular time) or Style (to provide particular rendering attributes) Thanks for your engagement, Christian! Rob
Received on Wednesday, 18 July 2012 16:09:42 UTC