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

Re: F2F Decision: Multiple Resources - closing Set?

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Thu, 1 Nov 2012 10:55:53 +0100
Message-ID: <50924729.1000702@few.vu.nl>
To: <public-openannotation@w3.org>
Hi again,

Trying to understand the full implication of Set: is there a formal relation between a case where there are several bodies and a case where there's one Set body with multiple items?
Are the two logically equivalent? Or is there fundamentally something more to a Set than to multiple bodies (or targets or selectors)?

Reading your email exchange with Bob [1]. I feel there could be differences . Namely, for the case of multiple targets:
"I think you mean the body to apply to each of the targets
individually, and if one of them were to be taken away, then it would
still apply to the rest of them. "
This hints that an annotation with a Set cannot have one item removed without becoming invalid.

I think I could live with the idea. But the consequences of the open world assumption on this makes me doubt.

Imagine you have one Set s with items r1, r2, r3. According to the OWA, one could state later that s also includes r4. In such case we would have a case where:
- a annotation applies to all r1,r2,r3,r4 according to the set semantics (according to the later statement)
- the annotation is also true for r1,r2,r3 alone (according to the original set of statement)

In order to keep a semantic distinction between Sets and multiple bodies (or targets or selectors) then we'd have to find a way to "close" Sets, wouldn't we?

(and sorry if I accidentally opened a can of worms; I'd prefer to be wrong on all this in fact ;-) )


[1] http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0023.html

> The most contentious issue discussed was the semantics and use of
> multiple occurrences in a single annotation for Bodies, Targets and
> Specifiers.
> The current model is either unclear or inconsistent as to their usage
> and meaning.
> Bodies:  Only allowed one
> Targets: Multiple allowed, but semantics unclear
> Style: Multiple allowed, semantics are a List (but with unclear order)
> Selector: Multiple allowed, semantics are a Choice, with a Set
> possible in CompositeSelector (order unspecified)
> The requirements were that the next revision of the model must have
> consistent and clear semantics.
> Discussed, but disliked, were options for additional predicates
> between the Annotation and the targets/bodies (added extra complexity
> without solving anything) and a resource that described how to
> interpret multiple predicates (didn't allow nesting at all, is very
> un-rdf to have a triple modify interpretation of the graph and other
> triples).
> The consensus of the group following much discussion was:
> The use cases for multiple bodies were accepted, thus allowing
> multiple uses of oa:hasBody in a single annotation.
> Use cases were presented and accepted that required nesting of Choices
> and Lists for Selectors.  And example use case was the choice between
> a media fragment selector that described a rectangular bounding box at
> a point in time in a video, and a composite of a more exact SVG
> selector and a media fragment for only the point in time.
> Use cases for nesting of constructions at the Body and Target were
> discussed and considered complex edge cases.  The consensus was that
> they should be implicitly possible but not made into concrete
> examples.
> * Multiple occurrences of the same predicate are to be treated as "Individuals".
> This means that each body annotates each target completely
> independently of any other body or target.
> Thus given bodies b[1]..b[n], and targets t[1]..t[n], it is true
> without further restriction that:
>    for x in bodies
>        for y in targets
>              b[x] annotates t[y]
> Specifiers were considered not to follow this pattern directly, and
> hence multiple specifiers must use one of the following
> constructions...
> * Other constructions require explicit, typed nodes within the graph.
> The same classes will be used for Bodies, Targets and Specifiers.
> The nodes would be instances of:
> - oa:Choice:  Exactly one of the items in the Choice should be used.
> - oa:Set:  All of the items in the Set should be used, and order is unimportant
> - oa:List: All of the items in the List should be used, and order is
> important.  The order is given via the rdf:List construction in an
> overlay of the items.
> - oa:item (domain oa:Choice, oa:Set, oa:List) An item which is part of
> the Choice, Set or List
> - oa:default (domain oa:Choice)  A Choice node can have a default
> selection that should be used if the client has no reason to select
> any other item.
> * oa:CompositeSelector is to be deprecated in favor of the more
> general oa:Set (or List)
> Some examples:
> An annotation where a comment is translated, but the French version is
> preferred by the annotator:
> _:x a oa:Annotation ;
>    oa:hasBody<choice1>  ;
>    oa:hasTarget<ny-times-article>  .
> <choice1>  a oa:Choice ;
>    oa:default<comment-in-french>  ;
>    oa:item<comment-in-english>  ;
>    oa:item<comment-in-spanish>  .
> (plus further description of body resources)
> An annotation that discusses two related parts of an image:
> _:y a oa:Annotation
>    oa:hasBody<comment>  ;
>    oa:hasTarget<set1>  .
> <set1>  a oa:Set ;
>    oa:item<uuid1>  ;
>    oa:item<uuid2>  .
> <uuid1>  a oa:SpecificResource ;
>    oa:hasSource<image>  ;
>    oa:hasSelector<selector1>  .
> <uuid2>  a oa:SpecificResource ;
>    oa:hasSource<image>  ;
>    oa:hasSelector<selector2>  .
> (etc.)
> Thanks,
> Rob&  Paolo
Received on Thursday, 1 November 2012 09:56:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:20 UTC