Re: Data Model Assumptions

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.

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