Re: Problems with the new beta spec

Sebastian, Paolo,

One of the reasons for having a very abstract set of examples was to
not require the specification to be updated every time a new example
was created.  I do strongly believe that this is important to
maintain, as should the work become a W3C recommendation at some point
(which is not at all certain, but certainly hoped for!) then we would
no longer have the ease of access we do now to update it.

One solution would be to have a static link for each section to a
table of contents document for examples.  Then the ToC document could
be updated without touching the main specification.

However, I think it would be nice to have the W3C folk on the list
weigh in on this particular issue as they must face it for every new
specification, and we should do whatever they recommend.

I have posted two sets of slides online:

http://www.slideshare.net/azaroth42/open-annotation-overview
http://www.slideshare.net/azaroth42/open-annotation-niso-digital-bookmarking

Which each walk through the model with a specific example.  Is this
the sort of thing that you were looking for, Sebastian?  (I am not
proposing using either of these directly)


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

One additional note beyond Paolo's explanation: we see an Annotation
as a sort of reification of the relationship between body and target.
It is not exactly this, as there may be no body, and there may be
multiple targets for a single annotation.  But the creator of the
relationship/annotation can be different from either the creator of
the body resource or any of the target resources, and thus it deserves
its own URI.
For example I can create an annotation that links a youtube video
(that I didn't create) to an image (which I also didn't create).  This
is the case in the second slideset above.

It also follows practically all existing work on annotation; to not
have an identifier for the annotation itself would require a lot of
explanation :)


>>>> 3. The arguments against URI Fragments are very confusing, and I am not
>>>> sure what is meant exactly.  e.g.

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

The other major consideration is the global uniqueness of identifiers,
and what it means to attach properties to them.

For example, if we used Fragment URIs to express a rectangular area of
an image, and then associated more information with that Fragment URI,
then everyone who subsequently used that same Fragment URI would gain
that additional information in their annotations.  This could be very
strange, especially for annotation-specific information such as
styling hints.

Secondly, we need to have methods beyond fragments to identify
arbitrary segments of any resource type.  For example, in the
Extensions document we define two text Selectors and an area Selector
that uses SVG.  Given that we need Selectors anyway, it was more
efficient to recommend always using them, thus reducing the problem of
choice (fragment vs selector) for how to do things and many checks in
consuming application code as to which choice was made.

Finally, as Paolo said, we are working on updating the spec for the
licence to follow the W3C community group requirements, but thanks
indeed for pointing it out -- the CC licence was a hold-over from the
OAC template that we started from rather than put there intentionally.

I hope that helps,

Rob

Received on Wednesday, 9 May 2012 23:28:34 UTC