Re: New Draft comments: textual bodies

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
>



-- 
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://etaxonomy.org/mw/FilteredPush
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 Friday, 11 January 2013 22:53:14 UTC