Re: Data Model Assumptions

+1. Done.

There's now a separation between always on SpecificResource and on either
SpecificResource or EmbeddedContent for each of the three scenarios.


In fairness to the different approaches, I think the Constraints / Criteria
section is too specific.

The criteria I think we should be working with, for *any* issue:

1. Must be usable in a Linked Data environment, and follow Linked Data best
practices
2. Must be extensible
3. Must allow for graceful degradation
4. Must produce a reasonable JSON serialization
5. Must not require any part of the RDF stack
6. Must be as simple as possible, and no simpler [1]

To map those to this issue:

1. Must not produce unusable results when multiple annotations use the same
resource (body or target) with different roles
2. Must allow extensibility of roles outside of the specification by
different communities
3. Must allow for graceful degradation when unknown roles are encountered
by clients
4. Must produce a reasonable JSON based format of the body plus role
5. Must not require reasoning / inferencing to determine whether a resource
is a body or target
6. Must be as simple as possible, and no simpler :)


[1] http://quoteinvestigator.com/2011/05/13/einstein-simple/#more-2363

My pushback against the current criteria is that I don't think they're
useful for evaluation.

1.  Is not true when used with subProperties.  hasComment "Literal" is
totally valid.
2.  Also rules out subProperties, as it replaces Motivations with
subproperties of hasBody.
3.  I agree with the thought, but I think my first bullet above is more
concise.
4.  Falls under my first bullet too.

But I don't want to simply scrub that section without Tim's feedback.

Rob


On Tue, Aug 18, 2015 at 2:06 PM, Benjamin Young <bigbluehat@hypothes.is>
wrote:

> On Tue, Aug 18, 2015 at 4:13 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>>
>> I'll try again, as I thought of a way that hopefully makes things more
>> concrete.
>>
>>
>> The issue is the same as primary/foreign keys in relational databases.
>>
>> In a relational database, you might start off with three tables, for
>> annotations, bodies and targets.
>>
>> The annotation table would have the identity of the annotation as the
>> primary key.
>> The body table would have the identity of the body as its primary key.
>> You don't want to duplicate information, so the body table has each body
>> only once (hence the primary key).
>>
>> We need to link from the annotation to zero or more bodies.  How do we do
>> that?
>> We can't put it in the annotation table, as there's potentially multiple
>> instances.
>>
>>
>> Annotation Table
>> | annoId | bodyId | targetId | ...
>> -------------------------------------------
>> | a0        | b0        | t0          | ...
>>
>> So annotation a0 has body b0 and target t0.
>>
>> Nope can't add a second row, because you can't repeat the id a0 for the
>> annotation to give it a second body, b1, because annoId is a primary key.
>>
>> So you create a linking table:
>>
>> | linkId  |  annoId |  bodyId    |
>> --------------------------------------
>> | L0       | a0          | b0          |
>> | L1       | a0          | b1          |
>>
>> Now annoId a0 has two bodies, b0 and b1.
>>
>> And we could associate more information with that table, about the
>> details of the use of that body with that annotation:
>>
>> | linkId | annoId | bodyId | role                 |
>> ------------------------------------------------------
>> | L0      | a0        | b0        | "commenting" |
>> | L1      | a0        | b1        | "tagging"         |
>>
>> Nice huh? We've reused a required piece of functionality (the link table)
>> to also improve the data by recording the role of the body with respect to
>> the annotation.
>>
>> The link here is the Specific Resource in the data model.  If you were to
>> turn that table structure into JSON you would get:
>>
>> {
>>   id: a0
>>   type: annotation
>>   body: [
>>     {
>>       id: L0
>>       role: commenting
>>       source: { id: b0 }
>>     },
>>     {
>>       id:L1
>>       role: tagging
>>       source: { id: b1 }
>>     }
>>   ]
>> }
>>
>> So all we're doing is exactly what any first year CS student would do
>> following relational databases 101.
>>
>> And for re-use it works exactly as expected:
>>
>> | linkId | annoId | bodyId | role                 |
>> ------------------------------------------------------
>> | L0      | a0        | b0        | "commenting" |
>> | L1      | a0        | b1        | "tagging"         |
>> | L2      | a1        | b0        | "questioning"  |
>>
>> Because the role is a property of the link, not of the body.
>>
>
> Thanks for this, Rob. I think it clearly represents the "internal
> referencing" thing going on in these proposed solutions.
>
> Are we to the point where these bits can start being crafted into more
> complete examples and headed toward consensus / inclusion in the model (are
> we there yet?! ;) )?
>
> Also, if you could dust of the wiki page's examples for the multiple-body
> proposals, that'd be super too. I'm not sure I quite know which one lines
> up with this proposal (or I'd do the work). I believe it's this one:
>
> https://www.w3.org/annotation/wiki/Expressing_Role_in_Multi-Body_Annotations#Role_Attached_to_resources_.28e.g.2C_SpecificResource.29
>
> But there's still "motivation" on that one...which I find a bit confusing
> in some ways.
>
> Clarity there, if you can provide it, would be super.
>
> Thanks!
> Benjamin
> --
> Developer Advocate
> http://hypothes.is/
>
>
>>
>> Rob
>>
>>
>> On Tue, Aug 18, 2015 at 11:49 AM, Robert Sanderson <azaroth42@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Aug 18, 2015 at 10:01 AM, Doug Schepers <schepers@w3.org> wrote:
>>>
>>>> This is actually why I raised the issue of putting Motivation directly
>>>> on the Body; it explains what role each Body plays in the whole Annotation
>>>> (though not necessarily what the relationship of each Body is to each
>>>> Target, for example).
>>>>
>>>> These entailments are where Rob and I might differ, BTW; he said [1],
>>>> “The role of the resource in the annotation is not a property of the
>>>> resource, it is a relationship between the Annotation and the Resource.”
>>>>
>>>> I might be misunderstanding him, but if "Resource" means a Body (in
>>>> this case), then putting the role/motivation in the Body seems like the
>>>> most straightforward way to describe the relationship of that Resource to
>>>> the Annotation.
>>>>
>>>
>>> Yes, in this case we're talking about the body, but the same applies to
>>> any other resource. (Intentionally overlooking the non-resource literal
>>> bodies).  I'll try to explain further why I strongly believe this to be
>>> true, regardless of linked data or RDF.
>>>
>>> The role of the body in the annotation is not a property of the body,
>>> because it's only true for the particular annotation, not generally.
>>>
>>> It is not a property of a video, that someone has used it in a certain
>>> way, any more than that it is a property of a web page for which browser
>>> some user is looking at it with.  You cannot set page.browser = chrome
>>> because someone else can just as reasonably view it in firefox.  Instead
>>> the person views-in-chrome the page.  Viewing-In is a relationship between
>>> the user, the page and the browser.  It would have properties like when it
>>> was viewed.
>>>
>>> You cannot set video.role = commenting because someone can just as
>>> reasonably use that same video in a different role, such as questioning or
>>> replying.  Instead, the annotation uses-as-a-comment the video.
>>>
>>> To avoid annotation.uses_as_a_comment = video, we have an extensible set
>>> of motivations and a single property of "body":
>>>
>>> annotation.body = video
>>>
>>>
>>> But remember we can't say video.role = commenting as it's _specific_ to
>>> the annotation.  Thus we introduce a level of indirection for the body:
>>>
>>> annotation.body.role = commenting
>>> annotation.body.source = video
>>>
>>> And that is the specific resource.  It holds properties that are
>>> specific to the annotation about the annotation's use of the video.
>>> Similarly, it's not a property of the video that the annotation only needs
>>> the first 60 seconds of it.  Instead we have a selector on the specific
>>> resource:
>>>
>>> annotation.body.selector.value = "t:0,60"
>>>
>>> It's not a property of the HTML page that the annotation needs a
>>> specific segment of it. It's not a property of the page that the comment is
>>> about a representation of it at a certain time. It's not a property of the
>>> page that the annotation creator wants the region highlighted in green
>>> rather than red.  It's not a property of the page that the annotation uses
>>> it as a comment, rather than a question.
>>>
>>> Maybe that makes it clearer, I hope so!
>>>
>>> Rob
>>>
>>>
>>
>>
>> --
>> Rob Sanderson
>> Information Standards Advocate
>> Digital Library Systems and Services
>> Stanford, CA 94305
>>
>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305