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

Re: Streamlining the OA Model

From: Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>
Date: Wed, 01 Aug 2012 17:31:25 +0200
Message-ID: <50194BCD.9010101@informatik.uni-leipzig.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 August 2012 15:32:00 GMT