Re: NEW DRAFT: Documentation and OA/OAX

Dear Jacco,
thank you for participating to the discussion and for expressing your
concerns.

We understand we need something simple to get started. And the decision of
restructuring the specs is going in a similar direction to what you are
proposing. In fact, we are not assuming that developers have to fully
implement specifiers and cardinality… unless they need to.

Actually, Rob and I discussed about having this topics in different
documents to make clear that these are optional features on top of the
basic ones. I guess your comments are in support of that approach rather
than having all the topics listen in a single document. It would be
interested to collect opinions from other members on this topic.

And, if I understand correctly, you are suggesting to formalize profiles so
that applications can comply to a basic or a more advanced profile. I
recall we discussed profiles in the past. Personally, I am not against such
approach. I believe we have at least one issue that might arise with such
organization - namely fragment URIs - but otherwise I believe it is doable
and you are probably right in saying it would deliver a clearer message.

Other comments follow.

On Fri, Nov 9, 2012 at 5: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.
>

As mentioned above, it is not mandatory to use Specifiers, unless you need
to. Regarding the Tag representation I am not completely sure at what
example of the cookbook you are referring to. In general, the examples of
the CookBook have to be updated following the changes we agreed upon in the
last couple of month (F2F Decisions and New Draft in the mailing list). The
Tag type wont be in oax anymore and, taken away provenance data, the
complexity is about the cnt:ContentAsText construct. The reasons for that
construct are motivated here:
http://www.w3.org/community/openannotation/faq/#faq3


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

I have to think about this. I personally have mixed feelings about
reification of DC metadata but I see some might be interested in that. As
we support named graphs that might be the solution there. Do you have
concrete examples you can contribute?


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

Agree.


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

I don't think that is very far from our thinking that clearly did not
emerge from the simple list of topics above.
Certainly some food for thought!

Paolo