Re: Problems with the new beta spec

Hi Robert,

my comments are inline .

On 05/09/2012 06:36 PM, Robert Sanderson wrote:
> Dear Sebastian,
>
> 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.


>> 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 .
>
>
>> 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?

All the best,
Sebastian

>
>
>> I am just asking, because we are developing the NLP Interchange Format within LOD2. See
>> http://svn.aksw.org/papers/2012/WWW_NIF/public/string_ontology.pdf for the
>> latest version and http://nlp2rdf.org/about  for the project. The goal is of course to make it compatible with your effort and provide a transition.
> Fantastic!  I'll try to generate the Open Annotation version of your
> example later today.  It would be particularly useful to walk through
> your requirements and try to see if and how they would be expressed.
>
> Hope that helps!
>
> Rob
>


-- 
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 Wednesday, 9 May 2012 21:38:59 UTC