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

Re: New Draft comments: textual bodies

From: Bob Morris <morris.bob@gmail.com>
Date: Sat, 12 Jan 2013 13:36:25 -0500
Message-ID: <CADUi7O5325PcXQs+JEOkB25s2uMNqf+K5_N=_tEqxmxa8RdnZQ@mail.gmail.com>
To: Antoine Isaac <aisaac@few.vu.nl>
Cc: public-openannotation@w3.org
I find your analysis  plausible.  However, my central point is that
the cost of punning---in this case permitting both resource references
and literals for oa:hasBody--is a needlessly high cost.  The opposite
position is that prohibiting punning (e.g. forcing a CNT-like
mechanism) needlessly adds cost.

The principal argument I've heard for the punning-permissive case is
based on an how common it is for human-facing  annotation generators
to use strings as predicates, particularly for oa:hasBody.  My
argument is that this is virtually irrelevant, because the
overwhelming fraction of such generators will not even reveal the data
model of OA or any serialization of it.  They will just provide a
way--e.g. in a form---for the user to provide a string.

To my mind, the main pain associated with with \either/ the
punning-permissive or punning-prohibitive design will fall on
developers, not on users. That is part of why I support the decision
to avoid the costs of the punning-permissive design. I think the
punning-permissive design complicates (some important) software-facing
applications  much more than the punning-prohibitive approach
complicates any(?) human-facing application. The only exception I can
think of so far is an application generator based simply on an
unstructured, naive text editor. In that case, the pain falls on the
user of the editor-based generator for producing serializations.

Bob Morris
p.s. I also thank Bernhard(?) for bringing up the Flickr case.  At
some point, the OA Cookbook should try to provide examples of a
plausible mapping to the various aspects of what Flickr provides
string interfaces for.  It's a likely case of interest, perhaps along
with Picassa.

p.p.s. Full disclosure: So far in the FilteredPush project we have
implemented  \only/ the applications that require string Bodies, but
we are just now embarking on the integration with annotations produced
and consumed by autonomous agents based on the Kepler workflow
platform, and these definitely need bodies comprising resource

Robert A. Morris

Emeritus Professor  of Computer Science
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
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.

On Sat, Jan 12, 2013 at 6:36 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> Hi Bob, all,
> Thanks for sharing
> http://www.flickr.com/services/api/misc.tags.html
> and others.
> However as I understand the flickr page, to me it just calls for a mapping
> like:
> flickr:tag = oa:Annotation
> flickr:raw = oa:hasBody (of course considering that hasBody could work with
> literals ;-)
> This is in line with your 'tag representations that are nothing if not
> complex structures', it's just that we disagree on which part of the OA
> model the <tag>  should be mapped to.
> The main point for making me interpreting this way is the creator (author,
> "The NSID of the user who added the tag") that goes with the <tag>. I'm not
> really convinced that this 'author' should be attached to the OA body, in a
> mapping to OA. It's really the creator of the oa:Annotation.
> The <tag> has no equivalent to hasTarget, but I suppose this would be obtain
> from an element in the data for the picture (or an API method to get the
> tags) which should be interpreted as the inverse property of oa:hasTarget.
> Antoine
>> Bernhard: We agree on the hypotheses, but not the conclusion of your
>> position.
>> Short form of disagreement: A tag in flickr is not a simple string. It
>> is a structured object with a unique id. (Even globally unique when
>> combined with the ids of the photo and account holder).  See
>> http://www.flickr.com/services/api/misc.tags.html
>> Long form of disagreement:
>> I don't think your flickr example shows that tags are simple plain
>> strings in the flickr data model or any of the exchange formats.  It
>> shows  at most that tags are simple plain strings in the human-facing
>> UI components. But this is probably what should also  happen for human
>> facing applications that prepare or display OA annotations expressed
>> in some exchange mechanism for OA.
>> To me it looks like flickr apis  for tags return tag representations
>> that are nothing if not complex structures.  See for example
>> http://www.flickr.com/services/api/misc.tags.html .  In fact, the
>> flickr JSON response API prepares something that looks quite like CNT
>> when returning something that would be element text in an XML
>> representation. See
>> http://www.flickr.com/services/api/response.json.html
>> All(?) of the flickr APIs have an associated flickr API Explorer
>> implementation.  The one for getInfo
>> http://www.flickr.com/services/api/explore/flickr.photos.getInfo is,
>> to me, instructive about the point of our disagreement. As best I can
>> tell experimenting with some of my own photos as well as the
>> documentation, every one of the four supported return values on a
>> tagged photo provides what I would only call a structured
>> representation of flickr tags. Besides the structure, each tag has a
>> globally unique identifier (perhaps globally unique only if combined
>> with the id of the photo and flickr account).
>> Bob Morris
>> On Fri, Jan 11, 2013 at 10:11 AM, Bernhard Haslhofer
>> <bernhard.haslhofer@cornell.edu>  wrote:
>>> Hi Rob,
>>> On Thursday, January 10, 2013 at 6:22 PM, Robert Sanderson wrote:
>>>> Then there's Markdown, various wiki languages, RTF, various XML or JSON
>>>> dialects for mark up, etc etc. I don't see a client could be expected to
>>>> know even that it can't properly render a comment without some level of
>>>> metadata.
>>>> Unless literals are restricted to *only* text/plain. So no markup at
>>>> all.
>>> Take Flickr commons (http://www.flickr.com/commons) and look at the
>>> thousands of notes people provided for the images there.
>>> Those are real-world annotation examples all of them being simple plain
>>> strings. They could easily be represented as...
>>> flickr:note1 a oa:Annotation ;
>>> oa:hasBody "what are those holes for?" ;
>>> oa:hasTarget<http://www.flickr.com/photos/nationalmediamuseum/3588905866#xywh=160,120,320,240>
>>> # sample pixel values
>>>   >  ;
>>> …without missing information a client needs to render an annotation.
>>> This should show that plain string annotations occur in the real world
>>> and I think OA should take this account and support this kind of simple
>>> annotations.
>>> But again: this is not against the existing ContentAsText approach for
>>> more complex requirements, which, I certainly agree, must be supported. It
>>> is, as Antoine said, just about providing simple patterns for simple,
>>> real-world needs.
>>> Bernhard

Received on Saturday, 12 January 2013 18:36:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:21 UTC