W3C home > Mailing lists > Public > public-openannotation@w3.org > May 2012

Re: Q: how to encode annotation "roles"

From: Robert Sanderson <azaroth42@gmail.com>
Date: Thu, 31 May 2012 15:48:28 -0600
Message-ID: <CABevsUHhdVgPAf=6AWRC3xi7Vi2+305kbYD0E9bh3N-dFftzQQ@mail.gmail.com>
To: Bob Morris <morris.bob@gmail.com>
Cc: Jacco van Ossenbruggen <Jacco.van.Ossenbruggen@cwi.nl>, public-openannotation@w3.org
And to reply to the multiple body problem:

On Wed, May 30, 2012 at 8:51 PM, Bob Morris <morris.bob@gmail.com> wrote:
> Jacco-
>
> My understanding of your #4 approach---which I would argue for among
> your suggestions--seems to run afoul of the  restriction of at most
> one Body in the current proposal. I argued against that restriction in
> the pre-public discussions as being needlessly closing the world.  The
> counter argument was that allowing multiple Bodies can lead to
> ambiguity in case there are also multiple Targets.  That is true, but
> it is a generic problem about associations of one part of a graph with
> another.

Yes, from an annotation-as-graph perspective, the restriction on 0-1
bodies is difficult to explain, however this is too broad for our
purposes.   Defining what an annotation is is already very tricky, if
there were multiple bodies it would be even more complicated if not
impossible.

Thus the restriction comes from the current definition of an
annotation -- a description of the relationship between a body
resource which is somehow about one or more other target resources.

We then introduce two special cases for ease of implementation:

* The no-body case, where there's a body implicit in the motivation.
Eg a simple bookmark doesn't need an explicit body with no content.
* the oax:hasSemanticTag case, which is a shortcut to allow tags to be
included along with a regular body.


> My position is that such ambiguity has several ways to
> resolve, and which choice can best be left to communities of practice
> or within an application.

For a regular application specific data model I would completely
agree, however we need to be careful to keep in mind that this data
model is expressly for the purpose of interoperability.  If
communities decide that they need to have multiple bodies and they
have a way to disambiguate the relationships between bodies and
targets, great! But until such time as there's a generic solution that
will cover the 90% rather than the 10%, we'd prefer to leave them out
of the interoperability specification.

The ambiguity, to be clear, is the coherence of the relationships
between the bodies and the targets.  A comment body and a tag body
have different relationships to a single target, for example and hence
the need to introduce the special case hasSemanticTag relationship.
So already we have a situation with two body-like things, with
different relationships to a single target.  This would become
unmanageable with multiple targets and multiple bodies of many
different types.

> A use case I offered is an Annotation that needs to have Bodies
> expressed in several natural languages (or for that matter, in several
> different domain terminologies), even for a single Target.

This can be covered in two different ways:

1.  A structured body, where the resource in the Body role has links
to the resources in different languages.  We use this approach in
Shared Canvas, which is based on Open Annotation:
    http://www.shared-canvas.org/datamodel/spec/#Choice

2.  As the different languages are all versions of the same thing,
just pick one of the resources as the default, and link the others to
it with an appropriate predicate (dcterms:hasFormat?)

Hope that helps explain the current thinking :)

Rob
Received on Thursday, 31 May 2012 21:48:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 May 2012 21:48:59 GMT