Re: Problems with the new beta spec

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