Re: New Draft comments: textual bodies

Dear Bob,

I got your central point, I just wanted to prevent using the flickr example as motivation for it ;-)

In the end it boils down to how much everyone weigh punning vs punning-prohibition. (and to what we can possibly suggest for alleviating the drawbacks of one option in the eye of the other option's proponants).

The arguments in favour of punning should of course *not* be about users being able to enter simple strings. The punning-prohibitive approach will not complicate human-facing applications, we fully agree. My point is that it would raise the bar for software developers, who have simple cases and will not understand why they should program against a model which introduces an extra level of complexity (bodies as objects instead of strings, to caricature it).

Granted, in the JSON-LD representation it doesn't look like a big deal at all. And certainly the OA spec has a point recommending JSON-LD as the prefered serialization format...
But I'm not sure the costs of extra complexity start and stop at the serialization format. There's the price of a possibly steeper learning curve for the exchange model itself. And while we all agree that an exchange model is not the specification of all "internal" implementations, it sometimes influences them.

Probably your experience with FilteredPush will be really instructive on that point!
But your case is still specific though: you already have implemented bodies as resources before (and with a good reason for them) so you'll probably suffer less than someone who'd implement OA for the first time, and has only flickr-like tags to handle.

Best,

Antoine


> 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
> references.
>
> 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://wiki.filteredpush.org
> 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.
>
>
>
> 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 Sunday, 13 January 2013 21:44:46 UTC