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

Re: Connecting multiple fragment selectors with individual bodies

From: Lutz Suhrbier <l.suhrbier@bgbm.org>
Date: Wed, 12 Sep 2012 17:58:35 +0200
Message-ID: <5050B12B.1050201@bgbm.org>
To: Robert Sanderson <azaroth42@gmail.com>
CC: public-openannotation@w3.org
Am 07.09.2012 17:00, schrieb Robert Sanderson:
> 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.
I guess, I start to understand the basic idea behind the annotation 
model you have specified. So, a target shall not determine which 
body(ies) relates to it, because it that restriction holds true, if that 
target was (re-)used in another annotation, where that restriction is 
not true. The same applies to the body and only an annotation can 
establish relationships between primarly independent Resources.
>
> 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
> node.
> * 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.

Anyway, I think my use case is not adequately covered by the current 
model, not at least from a semantic perspective. Enforcing the creation 
and composition of annotations, which are not dedicated to represent an 
independent annotations are also contradicting to the global scope 
assumptions. That way, the statement that what in my use case is called 
an annotation element represents an independent annotation is simply 
false and not intended.

As the model provides multiple specific target definitions within one 
annotation, there should be also a means saying, that a given body is 
only valid related to a given target, or in a given context. So, having 
multiple bodies and a hasContext property allowing to relate a body with 
the restricted context of a specific target also makes semantically 
sense and currently appears to me the most promissing approach which is 
currently discussed.
>
>
>> 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.
Yes, that's definitely true, as in my use case the bodies would contain 
a new value and a comment only valid in a specific context: A specific 
XML-Element (or set of XMLElements) described by an XPath expression 
which applies to a unique source document stated within a specific 
target. It is never thought to be valid outside of that unique document. 
Though, in my case, the relationship is not to a potentially modifiable 
web page, but to a given document's state retrieved at a given point in 
time.

>
>
>> 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?
Yes, that creates some more specific bodies, but creating bodies are 
really lightweight as opposed to creating annotations and semantically 
much more correct in my use case !!!

>
>
>> 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)
Addition sounds good, but if there is no linking allowed, than I worry 
that none of the actually discussed approaches could solve my use case's 
problem in an appropiate and standard conform way, see my arguments above.

best regards
Lutz


>
>
> Hope that helps,
>
> Rob
>
Received on Wednesday, 12 September 2012 15:59:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 September 2012 15:59:15 GMT