Comments on the draft W3C Annotatea specification

These comments are based on the draft specification on the W3C 
website at:
http://www.w3.org/2002/12/AnnoteaProtocol-20021219

[There is a more recent draft on the www.annotea.org website at:
http://www.annotea.org/Annotea/User/AnnoteaProtocol-20051226.html
which includes a whole new section on Bookmarks and Topics.  However, I
don't believe it has any official standing.  If it does ... or
should ... have standing, then it would be a good idea if someone at the
W3C added it to the W3C website!!]

0)  The structure and language of the current draft is not really
appropriate as a specification. This is understandable given the history
of the document, but it would need to be addressed if Annotea is to
progress to a W3C recommendation.  (IMO, this work needs to be done
anyway.)

1)  The relationship between the Annotea Protocol and Annotea RDF
schemas should be spelled out more clearly.  I would expect to a
reference in the Annotea Protocol document's overview, and a later
section that lists and describes the core schema properties, and states
whether they are mandatory, recommended, optional, single-valued,
multi-valued, whatever in the context of the protocol.  (I acknowledge
that making properties mandatory goes against the grain with RDF, but an
Annotea client or server-side implementation needs a clear "contract"
which spells out what is required for the protocol to "work".  For
example, the "annotates" property needs to be mandatory in some
contexts.  This is noted in the spec at some points ... but are there
other properties like this?)

Re: Comments on the draft W3C Annotatea specification

Here are a couple of clarifications / followups to my previous post:

On Tue, 2008-11-11 at 13:27 +1000, Stephen Crawley wrote:
> 6)  When I POST or PUT an annotation with an embedded body, the body
> is
> assigned a URI.  The examples show URLs for the body taking the form
> "/Annotations/body/XYZZY", where "/Annotations/XYZZY" was the url for
> the annotation.  Is the string "body" required to be present, or could
> some other string be used?  Similarly, could the unique part of the
> body
> URI ("XYZZY") be different to the corresponding part of the annotation
> URI?

6a)  If the embedded body has a URI, should this URI be preserved or
should the body be stored with a new URI?

> 7)  If I PUT or DELETE an annotation that was previously POSTed with
> an
> embedded body, what should happen to the old embedded body?  Bear in
> mind that the old body would have been given a URL, and that it could
> be
> the 'object' of some other annotation property.

7a)  The spec clearly states that the DELETE should cause an embedded
body originating from an earlier POST or PUT should be deleted.  (My
mistake ...)  But it does not say if a PUT causes an old embedded body
to be deleted immediately.  

11)  The spec does not say what should happen if you POST two

EARLY REGISTRATION ENDS NOV 11: ONTOLOGY FOR THE INTELLIGENCE COMMUNITY (OIC 2008)

Re: Comments on the draft W3C Annotatea specification

And a couple more:

21)  In Section 2.1.2, the spec talks about using the HTTP Message
schema to encode XML-based formats such as XHTML, MATHML and SVG as
annotation bodies.  However, it is not clear whether this use of the
HTTP Message schema is mandatory or optional.  (I assume that it is
optional.)

22)  Section 2.3 does not clearly state how the server should respond to
a GET request for a 'body' URL.  If the original embedded annotation
body conforms to the HTTP Message schema, should the server respond to a
GET by decoding and sending the HTTP body?  What should it do if the
original body is does NOT conform to the HTTP Message schema?  What
should it do if the original body contains other RDF properties?

23)  Section 2.3. should include examples showing how the server
responds to GET requests.

24)  Section 2.1.2 contains the words "[t]he authors have not decided
whether to move to using that mechanism.".

25)  There should be a way for a client to TELL the server to respond a
GET request for a 'body' URI by sending the body as RDF ... not
withstanding the use of the HTTP Message schema.