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

Re: Connecting multiple fragment selectors with individual bodies

From: Robert Sanderson <azaroth42@gmail.com>
Date: Fri, 7 Sep 2012 09:00:08 -0600
Message-ID: <CABevsUF-v1s7SJJqW56SrY-DjJVxu03N030x9q-qjuRwAxx7tA@mail.gmail.com>
To: Lutz Suhrbier <l.suhrbier@bgbm.org>
Cc: public-openannotation@w3.org
Hi Lutz,

On Fri, Sep 7, 2012 at 8:32 AM, Lutz Suhrbier <l.suhrbier@bgbm.org> wrote:

> 1) Using CompositeAnnotation
> The advantage is, that it clearly composes what I want to compose, a set of
> sub annotations under the ceiling of one annotation.
> Disadvantage: A lot of oa:annotations will have to be created in the model,
> which are some kind of "unwanted" and waisting somewhat the model.

While this idea hasn't been discussed fully, I can say that the model
won't support linking bodies directly to targets as the means of
distinguishing body from target, or which body is associated with
which target.

In RDF, every statement is at a global scope. So B1 annotates T1 is
true everywhere, even "in" annotations where (for example) both B1 and
T1 are Targets. Or another annotation where B1 is the Body, but T1 is
not the target.
This is solved by having the Annotation node to provide identity for
the statement, which is why we sometimes talk about an Annotation as a
reification of the relationship.

Other advantages to the composite approach:
* Doesn't introduce ambiguity for the general case where additional
relationships are not provided or not needed
* Individual annotations are annotations that are simply grouped
together, and hence they can be referenced directly. For example one
might want to annotate only one of the grouped annotations.
* Is an easy overlay on top of the existing model, rather than a
change to the model. Thus people who do not need this do not need to
worry about it

And a couple of design considerations that play in:
* We have considered creating new nodes with UUIDs to be relatively
cheap.  For example if there is a choice between creating a new node
or creating ambiguity or making use cases impossible, we put in a new
* The number of triples is not a factor in the design of the model --
we are not trying to keep things as small as possible, but of course
this has to be balanced with having the model be understandable.

> 2) A combination of multiple bodies and the hasContext property

Multiple bodies have yet to be discussed thoroughly, but ...

> If I understood right, hasContext is thought to be used in any Specific
> Resource. Thus, I could create a Specific Body Resource and use the
> hasContext property to assign that body to a Specific Target Resource

> (Saying, the body makes only sense if regarded within the scope of the given
> target resource).

That would only make sense (to me at least!) if the body was somehow
within the specific target resource.  For example if you had an image
within a web page, that's fine.  But a video on one server is not
within an image on a different server, for example.

> If, furthermore oa:annotation may incorporate multiple bodies, I could
> create one Specific Body as described above, and connect them with the
> dedicated Specific Target Resource. I think, that would perfectly match my
> requirements and would also avoid to create a bunch of unnessary
> oa:annotation instances within the model :-)

But at the expense of creating the specific resource nodes, or do you
need these anyway?

> What I did not really get from the discussions, if hasContext's use in
> SpecificResource is intended as an addition or an alternative to the other
> concepts (e.g. Selector) within a Specific Resource. If it is thought as an
> addition, hasContext could also be used within the Specific Target resource,
> to relate a specific body resource with that specific target including
> fragment selector. That would also be an adequate solution to my use case
> too!

It is definitely an addition, but not intended for linking body to
target (or vice versa)

Hope that helps,

Received on Friday, 7 September 2012 15:00:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:01 UTC