Re: New drafts - general comments and intro

Hi all,

For the record, I'm generally happy with the initial thoughts on the other points.
For stuff like figures, I agree it is worth waiting till we agree on the technical spec first, before spending time beautifying everything. But I'll certainly come back on this at one point!

Cheers,

Antoine


> Hi Antoine,
> a few initial thoughts
>
> On Sun, Jan 6, 2013 at 7:58 AM, Antoine Isaac <aisaac@few.vu.nl <mailto:aisaac@few.vu.nl>> wrote:
>
>     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!
>
>
>
> In Annotation Ontology v.1 (end 2009) I created several namespaces core, selectors, types, integration modules [1]... I thought that was a nice way to organize the different concerns and to have them evolving separately. Well, almost all the people who implemented AO and got back to me, strongly criticized that approach as they found multiple namespaces annoying and overly complicated. That brought me to collapse everything in a single namespace in v.2 [2] and everybody seemed happy with that choice. I still think that having more namespaces - organized by concern - was more elegant and manageable in term of evolution, but it seemed too much of a burden for many.
>
> Then, with the creation of Open Annotation came the approach oa/oax. The interpretation of that split has been always a bit problematic as, I think, it was reflecting several criteria at the same time: stable vs. unstable, simple vs. complex ... We had several long discussions where the problem consisted literally in deciding where to fit a term oa or oax. Some terms were of interest for many but still unstable... and so oax became a staging area. I don't believe it is that simple to determine what is used by everybody and what is used by a few either. And that can change dramatically with time. It would require again a strategy to deprecate and bring into core terms that become accepted and/or mainstream.
>
> If these new specs, besides naming the levels and the tuning of some definitions/charts, are proven to be accepted, I am wondering what you would classify as extensions. I think the new organization of the documents helps the learning process but I don't think it necessarily reflects what is going to be used the most. I can envision an extension for additional selectors and multiple extensions - one for each area of interest - for collecting Motivations. Maybe another extension for states?. But these will not really effect the current documentation. So, maybe the extensions will be managed separately from these specs documents?
>
> [1] http://code.google.com/p/annotation-ontology/wiki/Namespaces
> [2] http://code.google.com/p/annotation-ontology/wiki/v2Namespaces
>
>
>     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 <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!).
>
>
> I think this is a good suggestion. I like "Core", "Module A", "Module B".
>
>
>
>     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 ;-)
>
>
> I believe we can fix that. If we end up changing to "Core", "Module A", "Module B" (or something on that line) numbering will be much easier anyway.
>
>
>
>     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.
>
>
> We had a discussion about this point while writing this version of the spec. I am ok with having 'related' replacing 'about'. The terms are both generic but 'relates' does not imply the directionality.
> Given the example you provided I don't see alternatives.
>
>
>
>     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.
>
>
> I understand that can be confusing as first image. Anybody else has opinions about that figure 0.1/intro?
>
>
>     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...
>
>
> We can certainly add the note.
>
>
>
>     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".
>
>
> I personally like the graphic notation. I agree we can improve the labels though, that would also help the graphic notation understanding.
>
> We discussed many times abstract vs. concrete examples. The idea was to have the concrete examples in the Primer/Tutorial and the Cookbook. I would be interested in collecting additional feedback on this specific point
>
>
>
>     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 <http://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Object_Properties>
>     [2] http://www.w3.org/TR/2012/REC-__owl2-primer-20121211/#__Datatypes <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!
>
>
> Maybe changing the term 'Requirement' to 'Query' would be better?
>
>
>
> --
> Dr. Paolo Ciccarese
> http://www.paolociccarese.info/
> Biomedical Informatics Research & Development
> Instructor of Neurology at Harvard Medical School
> Assistant in Neuroscience at Mass General Hospital
> +1-857-366-1524 (mobile) +1-617-768-8744 (office)
>
> CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s), may contain information that is considered
> to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender.
> If you have received this message in error, please notify the sender immediately.

Received on Wednesday, 9 January 2013 13:31:16 UTC