Re: Motivation as Property or Value (was: CFC: Basic Roles Proposal)

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>
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 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
> bill@opengovfoundation.org
>
> On Aug 28, 2015, at 6:15 PM, Doug Schepers <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
>
>
>