Re: New drafts - general comments and intro

Hi Antoine,
a few initial thoughts

On Sun, Jan 6, 2013 at 7:58 AM, Antoine Isaac <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.