Re: F2F Decision: Multiple Resources - closing Set?

I think you're correct, but given the open world assumption, I don't see a
way to avoid it.   I think the @@TODO in the spec that says when the RDF WG
comes up with a solution to these issues then they'll be adopted is the
best that we can do.

The devil's avocado position: This is a problem with RDF and can be solved
by getting rid of RDF and having a single JSON serialization of an abstract
model

* We want to make a web centric Annotation model, not necessarily a
semantic web centric Annotation model
* The serialization is relatively unimportant compared to the semantics, as
demonstrated by the many RDF serializations
* Use cases trump technologies:  if a technology can't fulfill all of the
use cases, then it should be dropped in favour of one that can
* The RDF meta-model makes life difficult both for the model and for
developers
* Using JSON would solve the ordering issue, the OWA problems, the
requirement to mint identifiers for everything and the difficulty of
parsing and manipulating the annotations in both client and server.
Basically ... it would solve *all* our current problems.

Which isn't to say that I'm in favour of this, but it seems to me that the
choice is either:

a) we accept that RDF doesn't fit our needs exactly and we're smushing some
stuff in where it may not be ideal, but the advantages of it outweigh the
negatives and is worth a little bit of fudging around the edges
b) we get of RDF as it doesn't fit our needs and other technologies do

Rob



On Thu, Nov 1, 2012 at 3: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
>>
>>
>>
>>
>
>