Re: New Draft comments: textual bodies

Hi Bob,  

thanks for pointing this out. However, I did not point out at Flickr "tags", even though
we could now discuss whether it makes sense to share the raw and/or the processed
form of a tag with others.

I pointed at the "notes" people add to images. Here is the API method that allows you to
edit such notes (http://www.flickr.com/services/api/explore/flickr.photos.notes.edit).

And it defines the following fields: x,y,w,h,text

And here is an example showing what Flickr shares as part of an getInfo request on an image.

<notes>
<note id="72157632495054239" author="48821385@N05" authorname="behas" x="20" y="20" w="100" h="200">Test</note>
</notes>  


I think it is straightforward to map this to simple OA annotations using the id to mint a URI, the xywh values to define the fragment,
and the "Test" string(!) to create a simple literal body.

Also, Flickr is just one example.

Bernhard

------
Bernhard Haslhofer
Lecturer, Postdoctoral Associate
Cornell University, Information Science
301 College Avenue

bernhard.haslhofer@cornell.edu
http://www.cs.cornell.edu/~bh392


On Friday, January 11, 2013 at 5:52 PM, Bob Morris wrote:

> 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 (mailto: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 (mailto: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 23:29:03 UTC