Re: Problems with the new beta spec

Hi Paolo and Robert,
(before I forget, which application did you use to make all the graphs 
and images? They look really great. )

thanks for your emails, I understand the choices you made much better now.

NIF takes a different approach, as it is designed for web services.  In 
the context, of a request many things are clear, i.e. client sends a 
string to server and gets a set of annotations back. Thus normally the 
provenance is clear (i.e. the tool that attached part of speech tags for 
example), which is why each annotation in NIF is one triple, rather than 
an entity.  There are some issues with e.g. confidence rating, but we 
might tackle them with OWL 2 Axiom annotations or something similar.  In 
general, would you think that a str:String in NIF could serve as a 
oa:Target? Or would I need to define OWL axioms or RIF rules to make a 
transition.


@Robert, I would still like to see the example, where "Bob", the 
annotator attaches a comment "Good idea that Semantic Web!"  to the 
first occurrence of "Semantic Web" on 
http://www.w3.org/DesignIssues/LinkedData.html . Could you create it for me?
In NIF it would need these 5 triples, "wa" is a fictitious namespace for 
a web annotation vocabulary:

<http://www.w3.org/DesignIssues/LinkedData.html#offset_717_729>   a 
str:StringInContext ;
     wa:comment <http://myannotation.org/comment/kf094erk430943k> .

<http://myannotation.org/comment/kf094erk430943k>
     rdf:type wa:Comment  ;
     wa:commentString "Good idea that Semantic Web!" ;
     wa:commentor "Bob"  .

Although I looked at the slides and the core and extension specification 
documents, I really feel unable to create an example myself. This is 
because of the lack of real examples. I just found this one here: 
http://www.openannotation.org/spec/extension/#SelectorOffset , but I 
still would not know how to do it. Here is my guess, how to model the 
target (body left out):

<Anno1>  a oax:Comment ;
     oa:hasTarget [
        a oa:SpecificResource ;
        oa:hasSource<http://www.w3.org/DesignIssues/LinkedData.html>  ;
        oa:hasSelector [
             a oax:TextOffsetSelector ;
             oax:offset "717" ;
             oax:range "12"
        ] .
<http://www.w3.org/DesignIssues/LinkedData.html>   a dctypes:Text .



All the best,
Sebastian


On 05/10/2012 12:46 AM, Paolo Ciccarese wrote:
> Dear Sebastian,
> a few comments below
>
>
>
>>> On Wed, May 9, 2012 at 10:09 AM, Sebastian Hellmann
>>> <hellmann@informatik.uni-leipzig.de>   wrote:
>>>
>>>> Dear all,
>>>> I hope this is the right mailing list to give feedback on the new beta
>>>> core specification ( http://www.openannotation.org/spec/core/ )
>>>>
>>> Yes, this is the right list, many thanks for joining and providing
>>> feedback :)
>>>
>>>
>>>   1. Could somebody please replace the examples with realistic ones? The
>>>> document is very difficult to understand. Examples that are too generic are
>>>> not helpful
>>>>
>>> This was intentionally done, so as to not prejudice the specification
>>> towards a particular scenario, or to bloat it with many different
>>> scenarios. Typically specifications, as opposed to guidelines or
>>> tutorials, do not give explicit examples.
>>>
>>> The idea is to have additional documents, and especially a cookbook of
>>> very specific examples such as how to associate a video with a part of
>>> an image, or some text with a particular version of a resource.  The
>>> Extension document also tries to be a little more specific.
>>>
>>> This was the intent of the first paragraph of section 1.3.  Once we
>>> have a good consensus on the specifications, both core and extension,
>>> we would direct our efforts towards populating the cookbook. And, of
>>> course, would welcome examples from others!
>>>
>>> Do you consider this an appropriate strategy?
>>>
>>>   No, I think it is inappropriate. First of all, only bad specification do
>> not contain examples. Most of the W3C Recommendations I have read contain
>> many good examples, which are easy to understand, here are some examples:
>> 1. http://www.w3.org/TR/owl2-syntax/  (it is full of Peter Griffin)
>> 2. http://tools.ietf.org/html/rfc5147#section-5
>>
>> The matter is also not sensitive (such as gender/religion/race
>> discrimination) . I don't think you will offend the image/media guys, if
>> you only have example using html web documents.
>>
>> Actually, I chose rather to write an email here than invest the effort to
>> understand the spec. The examples are really a show stopper. If you do not
>> include them, then you should put a link to a specific example right in the
>> spec.
>
>
> When the cookbook examples will be ready, I believe linking them to the
> specs is something we can consider. That will mean having proper examples
> we can link to each section of the spec. Some more work, but it could be
> beneficial.
>
> In this respect, if you want to help us identifying concrete examples for
> the CookBook you would be more than welcome. And if we find out something
> is not possible we will list them as use cases to address in the future
> revisions.
>
>
>>
>>
>>   2. Can there be more than one body per annotation?  Why do you need the
>>>> Annotation node then? You would have to create an extra URI without a
>>>> reason.
>>>>
>>> There can be either zero or one Body but not more than one, as per the
>>> last paragraph in the description of section 3.1
>>>
>> Why do you need an Annotation node then? What properties can Annotations
>> have that Body couldn't have. Normally, it makes sense to separate the
>> feature from the location.  What is the difference between body and
>> annotation? For me it just seems to be an additional URI to mint,
>> additional triples and also additional SPARQL joins .
>
> I'll give you a couple of examples.
>
> I have a scientific document that publishes some scientific argumentation.
> The document contains several claims. We can represent formally a claim
> with a discourse ontology and then we can use the node annotation to
> connect such representation to the text fragment that is related to that.
> The claim is a self contained entity, it is not an annotation and it can
> live by itself. The same claim can be published in multiple articles and
> different websites and it has authors and provenance usually different than
> those of the annotation. We can have one representation of the claim and
> multiple annotation objects linking such claim to the text/images fragments
> that are 'representing' it. That link is not a property of the body, unless
> your body is something else that embeds that claim and we go back having
> two entities.
>
> If I annotate video A with video B. Video B is not an annotation is still a
> video that has been linked through an annotation. Again, the link is not a
> property of the videos, it is something different with different provenance
> than the target/body.
>
> I hope this clarifies a bit more our design choice. The choice was also one
> of the core design principles of the two previous models OAC and AO that
> are now merged in this spec.
>
> In any case, if you have a concrete example to show us that will help the
> thinking process.
>
>
>>>   3. The arguments against URI Fragments are very confusing, and I am not
>>>> sure what is meant exactly.  e.g.
>>>> "If the Target of the Annotation was a resource with a fragment URI,
>>>> then it would not be possible to query for the Source's URI directly."
>>>> Technically, URI's are not queried, instead URL's are retrieved. With a
>>>> URL containing a hash-fragment, the client would strip the #-part and
>>>> retrieve the whole content of the resource and then select the respective
>>>> fragment addressed by the fragment identifier. That is quite a  "direct"
>>>> action in my opinion.
>>>>
>>> Yes, a good point, I'll try to make this more explicit.  The query use
>>> case is that in SPARQL or other similar graph query languages, URIs
>>> are treated as completely opaque.  You can't search for the base URL,
>>> only the complete one.
>>>
>>> So, imagine a service that allows you to search for annotations on
>>> particular resources.  You would not be able to construct all of the
>>> possible URIs with fragments to search for, you would want to just
>>> search with the base URL.  And thus to make this easier, we don't want
>>> to promote targeting URIs with fragments.
>>>
>> Querying with SPARQL  is more or less the only use case, where URIs using
>> fragments are not ideal. I wonder why you would not recommend them,
>> however. They are useful for many other use cases. Is SPARQL the main
>> reason for the open annotation movement?
>>
> Sebastian, 'NOT RECOMMENDED' means  "that there may exist valid reasons in
> particular circumstances when the particular behavior is acceptable or even
> useful, but the full implications should be understood and the case
> carefully weighed before implementing any behavior described with this
> label". The implications are that the URI fragments are not covering all
> the known use cases - in fact we need additional methods to identify
> fragments - and that SPARQL will not do the job. In our experience, and
> with the interoperability goal in mind,  those are two good reasons and we
> feel it is right to warn the users in that regard.
>
> Best regards,
> Paolo
>


-- 
Dipl. Inf. Sebastian Hellmann
Department of Computer Science, University of Leipzig
Projects: http://nlp2rdf.org , http://dbpedia.org
Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann
Research Group: http://aksw.org

Received on Thursday, 10 May 2012 09:57:52 UTC