Re: Annotea's context property

Charles McCathieNevile wrote:
> summary:
>  - "dc:creator" can be anything
>  - reconsidering the idea of context as a literal.
> 
> details:
> 
> dc:creator
> 
> As far as I can tell the protocol makes no formal requirement on the content
> of dc:creator, and the Dublin Core doesn't either. So for interoperability
> you should expect to get any kind of content, and return what you got. This
> can be helpful.

I could rework ZAnnot to do this, although not in time for the upcoming 
0.4 release.

> For example I might want to claim that the creator of  document is
>   <foaf:Person> <foaf:mbox> <mailto:[email protected]> .
> i.e. the person who has the email address [email protected], expressed in
> a way that can be processed by RDF and matched less ambiguously than just a
> literal. This is legal according to my reading of the schemas.

It may be legal, but I'm not convinced that it's a good idea.  If you
create an annotation with some arbitrary RDF resource(s) as the value of 
dc:creator, there will be several Annotea clients that won't know what 
to do with it.

> It seems to me that there are some possible arguments for not forcing context
> to be a literal, rather than simply correcting the schema to say explicitly
> what the protocol authors said on this list.
> 
> One of the use cases for annotations is EARL. From my experience, it makes
> sense to be able to make EARL statements about a part of a document - which
> is like annotating a context. EARL may use an xpath to identify a context,
> but this is not defined for HTML documents. Instead, it might be useful to
> describe the context with a complex bit of RDF, for example identifying the
> context as "an xpath for a document available by submitting an HTML document
> to a web service at http://example.org/tidy-it". (For that matter I might
> like to do this in general annotations).

That sounds like a cool way to extend annotations, but again, it will 
incompatible with clients that implement a:context as a literal.

I don't mean to be a stick-in-the-mud, but to be *usefully* 
interoperable, standards need to be explicit.  If the Annotea protocol 
says "This property can be a resource or a literal, do what you want", 
then we'll end up with a myriad of incompatible client implementations 
that can't read each others' annotations.  This defeats the point of 
having a standard to begin with.  I would much rather see an Annotea 
spec/schema that explicitly lays out a basic set of well defined 
properties *and* their allowed values.  Anyone who implemented that 
would be able to claim "Annotea X.Y" compliance.  Anyone wishing to 
extend the protocol could add properties to the a:Annotation resource, 
and clients that don't understand the extensions could just safely 
ignore them, confident that they're still getting the core functionality.

--Brent