Re: NEW DRAFT: Documentation and OA/OAX

Dear Jacco, Paolo and all,

Not to "me too" but I definitely agree with your point of view overall.
 It's important that the documentation be welcoming as well as precise, and
the current split doesn't do that very well.

A quick question to get some feedback:

I was interested by the use of CSS as an example, as I wouldn't have
included it as an example of a simple specification.  CSS level 1 is
obsolete, and CSS 2.1 has 17 sections and 8 Appendices, at least one of
which has more than 100 subsections!
( http://www.w3.org/TR/CSS/#css1 and http://www.w3.org/TR/CSS21/ )

This made me think that *at the moment* perhaps what we need aren't formal
specifications, but instead tutorials and guiding documents should receive
more attention?  This would mean that we weren't bounded by some of the
formality and permanence restrictions required of W3C specifications. Once
the model is better understood, especially regarding the choices that have
been made over the process, it would be easier to have more detailed
discussions about the most appropriate way to move forwards.

Thanks,

Rob



On Fri, Nov 9, 2012 at 3:28 AM, Jacco van Ossenbruggen <
Jacco.van.Ossenbruggen@cwi.nl> wrote:

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