New drafts - general comments and intro

Dear all,

I've started to read the new draft. For all kind of reasons I prefer it to the old one, even if I disagree with some of the choices made, especially on the namespace [1]. Congrats to the editors for carrying out a great deal of work that goes in the right direction!

For the sake of keeping modular myself, I will now only raise comments on the intro and the first level -- otherwise it would be too messy!

I write them below, in the order of reading--I couldn't figure something better, sorry.

Disclaimer: some comments may unearth issues that have been discussed before I joined the Group. I apologize in advance for any less constructive contribution... And yes, I am often picky ;-)

Best,

Antoine

[1] http://lists.w3.org/Archives/Public/public-openannotation/2013Jan/0012.html

----------------

1. I like the modular approach. But I'm not enthusiastic about the numbering and the use of "level" word. It hints that level 3 is of superior complexity than level 2, and/or that it builds upon it. But one can use patterns from level 3 without bothering with the ones of level 2. For example, multiplicity constructs and equivalence of resources are quite orthogonal with Specific Resources. And I don't find everything in L3 more complex than everything in L2.
So I'd suggest a more neutral way to label the different groups. "Core", "Module A", "Module B" may be a way to go, at least for a first approach. Or (and that's especially true for a merged namespace) you can just drop the "Level X" from the section titles (and the rest of the spec!).


2. The intro section should be numbered 1. Having a sub-section numbered "0.2" reads really strange! Note that if you follow the suggestion in 1, then there's no need to have the numbering of sections aligned with the numbering of levels/modules ;-)


3. "An annotation [...] conveys that the body is somehow about the target."
I reckon you're use "somehow" in this sentence, but I find "about" to be dangerously confusing. For tagging and classification, e.g., someone tags a web page with its subject, then it is rather the target (the web page) that "is about" the body (the tag or concept). And that's a quite common scenario.
So unless there's a strong motivation I'm overlooking, I'd recommend a more neutral expression like "the body relates with the target". Granted, it's less informative, but at least it's not dangerous.


4. The 'about' arrow in Figure 0.1 seems dangerous. Not only because it uses "about"! Upon seeing it, a reader may indeed wonder why such direct link is not what the OA model should use from the start. Or at least why it's not present at all in the model.
I'd advice either to remove the arrow or to put a couple of sentences explaining why annotations are not represented by a direct (RDF) link. With a personal preference for the first: I don't feel the required explanation belongs to an intro.


5. "does not prescribe a protocol for creating, managing and retrieving annotations".
Such affirmative statement could be read as conflicting with later sections on States and Fragment Selectors. E.g., "Clients MUST process the value of the FragmentSelector based on the standard that it conforms to" in 2.2.1.


6. "version specific URLs" -> "version-specific URLs" (I think...)


7. The specification re-uses the cnt and trig namespaces. But these are not stable proposals, I fear.
Is anyone still working on the CNT working draft? What will be the status of TriG after the RDF Working Group publishes new material for Named Graphs?
On the technical level there is no crucial issue right now. But I'd advise to write an editorial note warning that "The reliance on the cnt and trig namespaces may be revisited by this group (or future ones) so as to take into account W3C activities impacting these specifications.".
Such a note would also work as a reminder for us or other editors/owners to re-open the issue in the future...


8. Reading the notes on diagrams in 0.3 makes me think all figures in the spec may now carry too much graphic information.
Individually they surely were good ideas at one point, but it is maybe time for some simplification!
My suggestions:

- no need to have two styles for the border lines of instances' ellipses. The identifier of the instance should be enough to say whether it's resolvable or not. If it's not enough, then there's a problem with this identifier! (see comment 9 below)

- no need to distinguish arrows for relationships and properties. Besides comment 10 below, the graph already makes it already visible with the convention that distinguishes the objects ("literals" or "instances").

- there's no need for a specific convention for instantiation arrows, if every arrow is labeled with rdf:type. (And I think it's always the case in the current specs)

- "resource boundaries" is not a clear notion, upon further inspection. It's not really defined anywhere (at least not in the beginning of the spec). And it's not very useful, at least not in the first graphs. It may be even confusing: why are the oa:hasBody and oa:hasTarget arrows in Fig. 1.1 not in the Annotation box?
If it's only useful in a small minority of graphs, I'd suggest to use (and declare) the convention only then.


9. "Example instance identifiers or example literal values always end in a number" deserves a comment of its own.
I believe that in general the examples really lack "real-world flavor. I'm not calling for real examples, but something that look less artificial than "T1#xywh" (even if a toy example) would be better. The pattern with the class label and a number does not give any insight on what is being denoted by an instance.
Whenever possible, changes like in Figure 1.1.1 "Body1" -> "aText" (or even better, something that gives a more precise idea of a specific text) may be more helpful.
Note that an often used convention in RDF is to lowercase the first letter of instance identifiers, to separate them from class identifiers. "Anno1" would be "anno1".


10. Relationships vs. properties.
This conflicts with the RDF terminology, which has only "properties". In fact the distinction in OA seems to exactly match the one in OWL between "object properties" [1] and "datatype properties" [2]. If I'm right, then I'd advise to replace the current distinction by the OWL one. If you find the OWL terminology to hard to swallow, at least it would be great to have a note that maps the OA terminology to the OWL one, .

We could also drop the distinction altogether. After all, it is consistently used in the document, but only experts will notice: I think there's no explicit definition anywhere!

[1] http://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Object_Properties
[2] http://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Datatypes


11. The introduction does not say anything on the "requirements" that appear later in the spec.
In fact I'm quite unconvinced by these requirements in general. Many seem technical, not really "business-oriented". In 1.1.4, why would one want to search for bodiless annotations specifically???
Also, many are trivial to meet, almost self-fulfilling prophecies: they already use the terms of the OA model!

Received on Sunday, 6 January 2013 12:59:01 UTC