Re: New Draft comments: textual bodies

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 11:36:53 UTC