Re: Motivation as Property or Value

Hi, Benjamin, folks–

Thanks for getting concrete in discussing this. I'm personally 
interested to see where this goes in the longer term.

In the meantime, there is some consensus around Rob's proposal, which 
makes substantial improvements, so it would be productive for us to 
accept that and move forward now; I suspect the co-chairs and Ivan will 
feel the same (though I will be going on vacation for a couple weeks).

Once Rob and Paolo have updated the Data Model spec accordingly, I hope 
that a republication can follow soon after.

Regards–
–Doug

On 8/31/15 1:55 PM, Benjamin Young wrote:
> Hey Bill (et al),
>
> Sorry for the slow response time. I've been exploring the edges of this
> discussion to see where the narrowest place across the cavern is in
> hopes of planning some bridge building. :) I'm still hunting, so maybe
> you can help. ;)
>
> I like code. So, I'm going to frame this conversation in JSON(-LD)
> examples for us to discuss--we'll see how that goes. :)
>
> First, if I understand your thoughts on the matter the closest example
> from the "Expressing Role in Multi-Body Annotations" wiki page was this one:
> https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_as_Subproperty_of_hasBody.2FhasTarget
>
> However, I think it misrepresented (a little) your scenario by
> presenting a `*Body` pattern--which would frankly be more painful to
> handle "at scale" than what you *actually* proposed--which I think looks
> more like this JSON (using the same content):
>
> ```
> {
>    "id": "http://example.org/Anno1",
>    "bodies": {
>      "comment": "This image is worth viewing on my desktop.",
>      "semanticTag": {
>        "related": "http://dbpedia.org/page/Arc_de_Triomphe"
>      },
>      "description": {
>        "id": "https://www.youtube.com/watch?v=BZLZyX3JdEM",
>      }
>    }
> }
> ```
>
> Is that closer to what you were expressing?
>
> The currently proposed Roles document format would look like this:
> ```
> {
>    "id": "http://example.org/Anno1",
>    "type": "Annotation",
>    "body": [
>      {
>        "role": "commenting",
>        "content": {
>          "text": "This image is worth viewing on my desktop."
>        }
>      },
>      {
>        "role": "tagging",
>        "content": "http://dbpedia.org/page/Arc_de_Triomphe"
>      },
>      {
>        "role": "describing",
>        "content": "https://www.youtube.com/watch?v=BZLZyX3JdEM"
>      }
>    ],
>    "target": {
>      "id"  : "http://tinyurl.com/ParisLandmark2-jpg",
>      "type": "Image"
>    }
> }
> ```
>
> Bill, could you confirm that this matches your understanding of these
> formats--or, if it differs, provide clarification?
>
> I want to narrow in on some specific code examples, so we can discuss
> like with like and avoid the vagueness of prose. :)
>
> Thanks, Bill,
> Benjamin
> --
> Developer Advocate
> http://hypothes.is/
>
> On Fri, Aug 28, 2015 at 8:33 PM, Bill Hunt <bill@opengovfoundation.org
> <mailto:bill@opengovfoundation.org>> wrote:
>
>     Hi Doug et al.,
>
>     I think(?) I understand where everyone is at with the multiple
>     bodies concerns.
>
>     Without beating a dead horse and just to recap, my original proposal
>     was to have the role be the property name within bodies, which
>     avoids having to iterate over anonymous bodies as is required with
>     triples as all of the other proposals require (at least as I
>     understand it).  This simply isn't performant if you only care about
>     one body-role and have tens of thousands of annotations or more,
>     it's roughly an order of magnitude more expensive. (And of course
>     all of the standard filter functions in javascript, etc, are just
>     loops under the hood.)
>
>     I understand that the consensus is that my suggestion wouldn't work
>     because you'd have to define every role as it would appear - which
>     is hard since we can't predict everything anyone would ever want to
>     do.  My argument was that 99% of roles could be defined in a very
>     narrow set of a half dozen or so; anyone who's doing something else
>     or wants to create a new role wouldn't be handled by a "standard"
>     consumer so they'd be off the map anyway.
>
>     That is, all roles/bodies are not equal, and most consumers in the
>     real world only will care about two or three at most and probably
>     won't know how to handle the others.  E.g., a quoted annotation and
>     a tweet will not be displayed the same, custom handling is necessary
>     for each; Twitter will not be using quoted annotations, Hypothes.is
>     <http://Hypothes.is> will not display tweets. Treating bodies as a
>     box that can contain any sort of role the author wants seems rather
>     vague to me.
>
>
>     That all being said, I see that within the needs of being a pure
>     linked data structure that my proposal doesn't fit nicely, and I
>     don't want to be obstructionist in our pursuit.  To Randall's very
>     valid point, performance and ease of use for the end consumers might
>     not be the deciding factor here for the spec.  But those are very
>     important concerns for us at OGF since we're building a massive
>     consumer of annotations, though I understand that for many members
>     of the group this might be premature optimization.  As a result, it
>     might simply be that this spec, as designed, won't serve our needs
>     at OGF and we'll have to do our own thing, which is wholly
>     reasonable and no hard feelings.
>
>     TLDR, we're happy to step out of the way if that helps the rest of
>     the group reach an amicable solution.
>
>     Cheers,
>     -Bill
>
>
>     Bill Hunt
>     Senior Developer
>     OpenGov Foundation
>     http://opengovfoundation.org/
>
>     Ph: 20-BILL-HUNT
>     202 455 4868 <tel:202%20455%204868>
>     bill@opengovfoundation.org <mailto:bill@opengovfoundation.org>
>
>     On Aug 28, 2015, at 6:15 PM, Doug Schepers <schepers@w3.org
>     <mailto:schepers@w3.org>> wrote:
>
>>     Hi, folks (especially Bill and Benjamin)–
>>
>>     On 8/27/15 8:54 PM, Robert Sanderson wrote:
>>>
>>     ...
>>>     On Thu, Aug 27, 2015 at 3:09 PM, Doug Scheperswrote:
>>>
>>>        I was surprised that the Roles Note didn't contain an example for
>>>        the copy-edit use case,
>>>        [snip]
>>>
>>>        Here is an alternate proposal based on Bill Hunt's suggestion [1],
>>>        which I'm putting forward as a strawman; [snip]
>>>
>>>
>>>     This was discussed and discarded in the most recent call. You'll
>>>     see in
>>>     the minutes of that call (
>>>     http://www.w3.org/2015/08/19-annotation-minutes.html ) albiet
>>>     slightly
>>>     confusedly due to some of the irc lag that of the people that gave an
>>>     opinion:
>>>
>>>     Rob, Benjamin, Jacob, Tim, Ivan: -1
>>>     Chris: +1
>>>
>>>     It's mentioned in the document as bullet three of the options
>>>     that were
>>>     considered and discarded in the intro of section 3.
>>>
>>>
>>>     Compared to the proposal that we gathered consensus around, as
>>>     described
>>>     in the document:
>>>
>>>     Rob, Benjamin, Tim, Jacob, Ivan: +1
>>>     Kyrce: -1
>>>
>>>     And the option for adding to both embedded content and specific
>>>     resource
>>>     which was a very mixed bag.
>>
>>     The structure of that telcon was not really about discussing the
>>     various merits of the options (this one in particular), but rather
>>     to walk through the different items (none of which matched my
>>     proposed compromise) and vote on them. I admit to being lost in
>>     this telcon approach.
>>
>>     So, merely listing the results of the poll isn't very enlightening.
>>
>>
>>>          Both seem to allow for extending the motivations, and would
>>>        gracefully degrade; a UA can just ignore values it doesn't
>>>        understand. Both make reasonable sense to me. The second one
>>>        (Bill's) feels a bit more like it's an analog of element-property
>>>        syntax, which works well with my brain, and it's a bit less
>>>     verbose,
>>>        but maybe there are deeper problems with it?
>>>
>>>
>>>     Again, I'm afraid I don't know how else to explain the problems
>>>     in ways
>>>     other than the discussions that have already happened several
>>>     times already.
>>
>>     There's been a lot of discussion on a lot of related issues;
>>     forgive me if the details of this particular approach have been
>>     discussed before in a larger context that I didn't fully understand.
>>
>>     It was helpful for Tim to gather together multiple proposals into
>>     a single page, but sometimes it seemed like they were tweaking
>>     different parts of the body structure, so it felt a bit like
>>     comparing apples to oranges at times. Because all the proposals
>>     were clustered, the emails around them also mixed different
>>     issues, and it was challenging to follow at times.
>>
>>     I wanted to surface this particular issue because Bill, like me,
>>     may not have recognized it in the conversations, and since he is
>>     the one who proposed it, I thought it best to call it to his
>>     attention.
>>
>>
>>>        Like others, I'd like to close this issue and move on. But I
>>>     do want
>>>        to make sure that we're thoughtfully considering our options
>>>     and our
>>>        rationales,
>>>
>>>     We have and we are :)
>>
>>
>>     Actually, I was hoping that for this issue in particular, we could
>>     hear back from Bill, Chris, and Benjamin, each of whom I've had
>>     some offlist conversations about this with.
>>
>>     Bill still seemed uncomfortable with the current proposed
>>     approach, so I wanted to give him a chance to make his case one
>>     last time before we moved on. Benjamin also had some clear points
>>     to make against Bill's approach, so I'd like to hear him
>>     articulate those points on the list.
>>
>>
>>     I also found some of Ivan's points against this approach worth
>>     considering. I'm hoping that by finally airing it as an issue
>>     distinct from a wide variety of other possible approach, and
>>     comparing it only to a single alternate approach, we can come to
>>     some shared understanding and consensus, and move on.
>>
>>     Regards–
>>     –Doug
>
>

Received on Monday, 31 August 2015 19:10:18 UTC