- From: Bob Morris <morris.bob@gmail.com>
- Date: Fri, 11 Jan 2013 17:52:45 -0500
- To: Bernhard Haslhofer <bernhard.haslhofer@cornell.edu>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Antoine Isaac <aisaac@few.vu.nl>, public-openannotation@w3.org
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