Re: Problems with the new beta spec

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?


> 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


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


> 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

Received on Wednesday, 9 May 2012 16:36:49 UTC