Re: NEW DRAFT: Documentation and OA/OAX

On 08 Nov 2012, at 22:11, Robert Sanderson wrote:

>  Although it is our prerogative as editors to choose the means we  
> feel most appropriate to convey the consensus of the community  
> group, we of course value all of your feedback and hence would like  
> to discuss the issue openly.

Dear Robert, dear all,

For all interoperability formats, it is strategically important to  
strike the right balance between expressivity and simplicity.  If you  
make things too hard nobody will use or implement your format, but if  
you make things too simple everybody requires non-standard extensions  
and you will not achieve sufficient interoperability.  Finding the  
sweet spot in this tradeoff is really difficult, and I'm not sure we  
have found it yet.  Many successful web standards have done a pretty  
good job here by publishing a base format that is the simplest model  
that is still useful, and cater for more complex things by making the  
base format extensible, and publish "standard" extensions. Formats  
such as Dublin Core, CSS, SKOS all have this "very simple but with  
extensible profiles or levels if you need them" philosophy. Since  
there is very wide range of annotation types and applications, I have  
always expected OA to follow the same path.

However, even with the old OA/OAX split I had the feeling really  
simple things were very complicated.  I needed the cookbook to find  
out how to represent a simple flickr-like image tag or a youtube-like  
video comment: after reading the OA/OAX drafts I still did not know  
how to do this, and after reading the cookbook I was surprised that  
something so simple as a tag was so complicated (needing > 15 triples  
to represent a simple tag, needing extensions such as oax:Tag and non- 
intuitive OA concepts such as cnt:ContentAsText and the cnt:chars  
property!). I also doubt if the majority of the OA users really  
_require_ the Specifier functionality, or that this is a "nice to  
have" feature that should go into a extension profile. If being "OA  
compliant" means that applications need to fully implement the  
Specifier functionality, I'm afraid this could become a show stopper  
for many developers.

On the other hand, many existing web applications supporting  
annotations will already use RDF.  An annotation where a web user  
claimed his home page has that user as the author is likely to be  
represented with some (reification of) <homepage_url> dc:author "user  
name".  If such applications would like to upgrade to being OA  
compliant, there should be a clear migration path, which is missing in  
the current specs and cookbook examples, because expressing "how" a  
body is related to a target is still unclear.  This could also become  
a show stopper for existing apps to upgrade to OA: "OA cannot even  
represent the simplest Dublin Core metadata!"

So the question is: who do you need to convince to make OA a success?   
These readers need to immediately see why OA is relevant, preferably  
after reading section 1 of the spec.

To conclude: I agree that the current OA/OAX split is not very useful.  
I would like to see a different split, e.g. a "OA Core" around  
Annotation Basics and the Publishing Model. The need to support this  
Core should be "obvious" and few people should complain about the need  
to fuly implement this to become an "OA compliant tool". After reading  
the Core spec, people should know how to express simple and common  
things like tags, comments and bookmarks.  For those needing more,  
there are the extension profiles, one dealing with Specifiers (or  
maybe even 3?), one with Semantic Structures and one with expressing  
specific Cardinality constraints. These profiles will be optional and  
can be implemented only if needed by the application, but providing  
the interoperability for those who need it. Cookbooks can help to show  
best practices for advanced annotations, but should not be need to see  
how to implement simple annotations.

I know this proposal is a radical break.  But I'm really worried: we  
have several projects running that would benefit from a good OA  
model.  The current sentiment  at the coffee machine is, however, that  
adopting OA would lead to an explosion of triples and non-intuitive  
sparql queries for most applications, and that these drawbacks are not  
outweighed by the advantages of interoperability offered by OA.  I  
doubt that the developers in these projects will embrace OA as it  
currently stands.

Jacco

Received on Friday, 9 November 2012 10:28:58 UTC