W3C home > Mailing lists > Public > public-openannotation@w3.org > May 2013

Re: minor whine about documentation arrows

From: Bob Morris <morris.bob@gmail.com>
Date: Mon, 27 May 2013 00:39:50 -0400
Message-ID: <CADUi7O5K72uhvfC_VPZegBTE034c=9AgYLk0mSytG9M5c2iyBg@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation <public-openannotation@w3.org>
I wonder if this discussion belongs in the (moribund?) wiki.  What
I've begun to find is that some of what I feel might depend on the
use, e.g., Word doc vs publication vs web document.  For example, in
illustrating how we use OA for data annotation, I've decided not to
box up literals...it clutters complex examples, especially if the
rdf:type edges are all shown and classes are boxed. Instead, I put the
text in quote marks, abusive as that might be. But  a diagram with
literals in lozenges might not cluttered on a screen.  Maybe.

Bob

On Sun, May 26, 2013 at 10:39 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> Hi,
>
> This actually relates to recommendations I had made a long time ago for
> simplifying the conventions. Not all had been followed then, but of course
> I'm happy that someone's giving a try at it again :-)
>
> So:
> +1 for not having any graphical distinction between the object vs. datatype
> properties
> +1 for the UML stuff. In fact I believe that it's not really needed to have
> a different form of arrow for the rdf:type one. There's already the label...
>
> Antoine
>
>
>>
>> Straight vs Curved: Agreed. It doesn't make a significant difference most
>> of the time, and the resource vs literal is sufficient to easily visually
>> distinguish.
>>
>> Open Arrows: Right, it's not class related but not instantiation. I'm
>> happy to remove the UML comment. (And as a non substantive change, will do
>> so now)
>>
>> Rob
>>
>>
>>
>>
>> On Fri, May 24, 2013 at 3:26 PM, Bob Morris <morris.bob@gmail.com
>> <mailto:morris.bob@gmail.com>> wrote:
>>
>>     OK, I understand that the graphical conventions [1] in the Feb 2013
>>     spec are purely informative, and about the doc, not the model. But I
>>     have come to decide that in publications it would be helpful to stay
>>     as close to the graphics of the spec doc as feasible. In attempting to
>>     do so, I have---so far-- one minor whine and one whimper.
>>
>>     Whine: I see no powerful reason to distinguish object predicates'
>>     arrows from datatype predicates' arrows by whether they are straight
>>     or curved. That distinction should be guided by the layout
>>     constraints in the diagram. For both cases, it is easy to find
>>     oneself forced into graphical ugliness by sticking to the convention.
>>     Among the consequences are wasteful extra white space needed when
>>     straight arrows are "required" and silly trivial curves when curved
>>     ones are "required". By "required" I only mean, "attempting to follow
>>     the documentation conventions." Besides all that, the two types are
>>     already distinguished by the shape of their targets---ellipses for
>>     objects, lozenges for literals. So it would be nice if the
>>     documentation were simply silent on the matter of curves or straight
>>     arrows. It wouldn't even require changing the pictures.
>>
>>     Whimper: It's a stretch to say "Class instantiation (rdf:type) is
>>     depicted as a straight black line with white arrow head, following
>>     UML." Most (all?) UML systems produce diagrams in which the
>>     equivalent of rdf:type is denoted with ":" in the label of a box
>>     depicting the object and its properties. There are no arrows for this
>>     particular UML association between instances and classes. Other
>>     associations between any UML objects are denoted with solid lines,
>>     and, if those associations are directional, with open arrowheads.
>>     Open arrows are generally (always?) reserved for the "generalizes"
>>     association, useful in specifying a class hierarchy. I like the
>>     triangular headed arrow convention for rdf:type, because it's an easy
>>     to find graphical signpost that let's you ignore the predicate name
>>     when it doesn't matter. But crediting it to UML makes me more, not
>>     less, confused, especially in the face of other UML reserved words,
>>     like "association" that are also used differently in UML. I would
>>     remove "following UML" from [1].
>>
>>     Bob Morris
>>
>>     [1] http://www.openannotation.org/spec/core/index.html#Examples
>>     --
>>     Robert A. Morris
>>
>>     Emeritus Professor of Computer Science
>>     UMASS-Boston
>>     100 Morrissey Blvd
>>     Boston, MA 02125-3390
>>
>>     IT Staff
>>     Filtered Push Project
>>     Harvard University Herbaria
>>     Harvard University
>>
>>     email: morris.bob@gmail.com <mailto:morris.bob@gmail.com>
>>
>>     web: http://efg.cs.umb.edu/
>>     web: http://wiki.filteredpush.org
>>     http://www.cs.umb.edu/~ram
>>     ===
>>     The content of this communication is made entirely on my
>>     own behalf and in no way should be deemed to express
>>     official positions of The University of Massachusetts at Boston or
>>     Harvard University.
>>
>>
>
>



-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390

IT Staff
Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob@gmail.com
web: http://efg.cs.umb.edu/
web: http://wiki.filteredpush.org
http://www.cs.umb.edu/~ram
===
The content of this communication is made entirely on my
own behalf and in no way should be deemed to express
official positions of The University of Massachusetts at Boston or
Harvard University.
Received on Monday, 27 May 2013 04:40:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:04 UTC