W3C home > Mailing lists > Public > public-annotation@w3.org > August 2015

Re: Data Model Assumptions

From: Doug Schepers <schepers@w3.org>
Date: Tue, 18 Aug 2015 18:39:55 -0400
To: Robert Sanderson <azaroth42@gmail.com>
Cc: W3C Public Annotation List <public-annotation@w3.org>
Message-ID: <55D3B43B.1080601@w3.org>
Hi, Rob–

I appreciate your using a different analogy to try to get your point 
across; I'm not sure it's really analogous, though.

A tree (or a graph) isn't a set of normalized relational database tables.

In a database, you have to make the relationship an explicit reference, 
because there's no inherent connection between a row in one table and a 
row in another.

In a tree (or graph), the relationship is implicit, because the Body and 
Target entries are contained by the Annotation entry.

So, all the properties you're including to make entries (IDs) explicit 
aren't necessary in a tree or graph. There's no need for the equivalent 
of a "linking table".

Even granting your analogy, I don't see why the added "source" object is 
needed (since you could avoid property-name collisions by using 
different names for the different property types).

Regards–
–Doug

On 8/18/15 4:13 PM, Robert Sanderson 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.
>
> Rob
>
>
> On Tue, Aug 18, 2015 at 11:49 AM, Robert Sanderson <azaroth42@gmail.com
> <mailto:azaroth42@gmail.com>> wrote:
>
>
>
>     On Tue, Aug 18, 2015 at 10:01 AM, Doug Schepers <schepers@w3.org
>     <mailto: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
Received on Tuesday, 18 August 2015 22:40:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC