Re: F2F Decision: Multiple Resources - closing Set?

Hi Antoine,

The way I imagine the difference between a set and several bodies is
somewhat like how I conceptualize the difference between a collection and a
novel. If my collection is a barrel of apples and each apple is a body of
an annotation. I can take away individual bodies without damaging the
overall semantics of the annotation, much like I can eat an apple from my
barrel and yet still have a barrel of apples (since there are still apples
in it). For the case of the set, the annotation bodies (or targets) form an
integrated / composite resource which is doing the annotation (or being
annotated). If even one of the set members is missing then the semantics of
the annotation are radically altered, much like if I tear out a page from
my novel, its narrative is damaged if not destroyed.

As an aside this is also why I don't believe exhibits to be good examples
of collections, their narratives (and semantics) are altered if members are
gained or lost.

Going back to annotations, I think one thing to realize is that the
multiple individual targets and bodies case is something of a built in
cheat. What is probably a best practice is to use individual annotations
for individual targets and/or bodies (although this causes the creation of
redundant triples). We should use oa:Choice when we mean that the targets
or bodies are in a XOR relationship to one another and, we should use
oa:Set when the targets or bodies are in an AND relationship to one
another. (IMO, oa:Composite, rather than oa:Set, might be a more accurate
description since we're making a new resource from multiple other
resources, that will semantically speaking, be more than the sum of its
parts.)

Another way to consider individual bodies and targets is that the
annotation node is putting them into a simple OR relationship to one
another, e.g., < Body1> OR <Body2> annotates <Target1> OR <Target2>.
Something to think about is whether or not that adds potentially
undesirable semantics to oa:Annotation.

Regards,

Jacob

On Thu, Nov 1, 2012 at 4:55 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> 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 ;-) )
>
> Antoine
>
> [1] http://lists.w3.org/Archives/**Public/public-openannotation/**
> 2012Oct/0023.html<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
>>
>>
>>
>>
>
>