- From: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
- Date: Wed, 01 Aug 2012 17:31:25 +0200
- To: Paolo Ciccarese <paolo.ciccarese@gmail.com>
- CC: public-openannotation <public-openannotation@w3.org>, Robert Sanderson <azaroth42@gmail.com>
Hello Paolo, let's separate the issues. Issue a) things you can represent with fragment selectors (expressivity) Issue b) syntax a) I am well aware of your use case. Do you have a benchmark that I could use for experiments? If you look at http://svn.aksw.org/papers/2012/NIF/EKAW_short_paper/public.pdf page 6, then you can see that NIF hash URIs are designed for robustness and to withstand changes made to Wikipedia. I am collecting a larger corpus currently, also including HTML. Do you have data sets or pages, which I could use? b) has nothing to do with a) . Truth is, however, that current fragment Ids are not designed to suit many use cases, but this is a shortcoming of issue a) expressivity and not the fault of the syntax. Let's say you could encode all information of OA selectors into fragment-id syntax. What is the harm done? I would really like to have a look into this. Is there a list with available selectors? I found: http://code.google.com/p/annotation-ontology/wiki/v2Selectors But it only lists 4 classes of selectors and all are not very powerful. Sebastian Am 01.08.2012 17:12, schrieb Paolo Ciccarese: > Dear Sebastian, > I produce annotation on webpages that I cannot control and I work with the > DOM. I mainly annotate scientific content with > http://annotationframework.org > > One example of why the counting and XPointer might not work is the fact > that pages includes sections like advertisements and news which change > often. There are even more simple examples, like having the document > displaying somewhere today's date. These modifications can fail selection > and counting and that is why, three years ago I started using different > mechanisms that are less affected - not immune unfortunately - to the > common changes in pages. About at the same time, the need emerged in the > OAC community as well. > > In general, Selectors also makes sense considering the need for annotating > media types other than HTML. For instance, Media Fragments fall short in > many of the already implemented use cases of video annotation tools. > > Hope this helps, > Paolo > > > On Wed, Aug 1, 2012 at 2:43 AM, Sebastian Hellmann < > hellmann@informatik.uni-leipzig.de> wrote: > >> Dear Paolo, >> Why wouldn't this work well? It is based on RFC5147. Offset works for any >> string and therefore also HTML source. Problems arise, when you interpret >> strings. They do not work well for DOM, of course, but this is where one >> would rather use xPointer (W3C) . I guess, it also wouldn't work well to >> use an OA text selector on an image, right? >> With fragments, you definitely gain: >> - compatibility with the web (which also means free implementations) >> - less triples >> - less generated UUID's (if any at all) >> >> What do you gain, when using selectors? I am not interested in >> theoretical/modelling issues. For me only things count that help you >> succeed in a use case. >> Building a parser for URIs is something very easy to implement, much >> easier in fact than understanding and working with selectors. >> Sebastian >> >> >> Am 31.07.2012 19:51, schrieb Paolo Ciccarese: >> >> Is the mechanism >>> http://www.w3.org/**DesignIssues/LinkedData.html#**offset_717_729<http://www.w3.org/DesignIssues/LinkedData.html#offset_717_729>really >>> working in general? >>> >>> In my experience it does not with HTML pages in general. That would mean >>> having lots of ways of composing the URIs that then need would need to be >>> parsed. That is why we designed more complex selection mechanisms ( >>> http://www.openannotation.org/**spec/core/#Selector).<http://www.openannotation.org/spec/core/#Selector%29.>.. >>> and therefore more >>> triples. >>> >>> Paolo >>> >> >> >> >> -- >> Dipl. Inf. Sebastian Hellmann >> Department of Computer Science, University of Leipzig >> Events: >> * http://sabre2012.infai.org/**mlode <http://sabre2012.infai.org/mlode>(Leipzig, Sept. 23-24-25, 2012) >> * http://wole2012.eurecom.fr (*Deadline: July 31st 2012*) >> Projects: http://nlp2rdf.org , http://dbpedia.org >> Homepage: http://bis.informatik.uni-**leipzig.de/SebastianHellmann<http://bis.informatik.uni-leipzig.de/SebastianHellmann> >> Research Group: http://aksw.org >> >> > -- Dipl. Inf. Sebastian Hellmann Department of Computer Science, University of Leipzig Events: * http://sabre2012.infai.org/mlode (Leipzig, Sept. 23-24-25, 2012) * http://wole2012.eurecom.fr (*Deadline: July 31st 2012*) Projects: http://nlp2rdf.org , http://dbpedia.org Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann Research Group: http://aksw.org
Received on Wednesday, 1 August 2012 15:32:00 UTC