- From: Jacob Jett <jgjett@gmail.com>
- Date: Thu, 1 Nov 2012 12:48:36 -0500
- To: Antoine Isaac <aisaac@few.vu.nl>
- Cc: Robert Sanderson <azaroth42@gmail.com>, public-openannotation <public-openannotation@w3.org>
- Message-ID: <CABzPtBKhBm-TFx3UHaVj1Ms82GtfFw0xq19Zsazxdjc2hbH6_A@mail.gmail.com>
Hi Antoine,
On Thu, Nov 1, 2012 at 12:02 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> Hi Rob, Jacob,
>
>
>
>
>> I think you're correct,
>>
>
>
> Thank you both for the answers, really useful to get heads around the Set
> notion. But isn't there a contradiction between what Jacob said on multiple
> bodies/targets [1]:
> [
>
> the annotation node is putting them into a simple OR relationship to one
> another, e.g., < Body1> OR <Body2> annotates <Target1> OR <Target2>
> ]
> and what is said in the resolution [2]
> [
>
> 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.
> ]
> ?
>
I'm not certain what may be contradictory. The logical OR case is very
ambiguous. From the perspective of the specification it is up to the
consumer to decide how to interpret the annotation. The can use both bodies
in one annotation or ignore one of them (this may not be a fair option due
to Open World assumptions, in which case our logical OR is actually some
kind of weird psuedo-XOR). They could even go so far as to map the
annotation into multiple other annotations with exactly one body / target
each.
Ultimately, this exploits RDF's allowance for arbitrary relationships to
realize some savings on minting identifiers and storing triples; however,
the price for this savings is ambiguity of how to interpret the semantics
of the annotation. This may not be a good thing as it will lead to
interoperability issues when developers invariably decide to interpret the
semantics differently.
To some extent I think this may have been Kevin's point back in July when
we were discussing multiple targets.
Something to consider is whether or not there are any actual use cases for
multiple individuals (it is clear that there are cases for both choice and
set/composite) beyond cheating the system and reusing triples.
Regards,
Jacob
>
>
> By the way I like Jacob's suggestion of a label different from 'Set'
> ('Composite' or other) if this construct indeed indicates something similar
> but 'stronger' than what multiple bodies/targets indicate (in the sense I
> understand from [1]).
>
>
>
> 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.
>>
>>
> +1.
>
> (I'll answer the RDF stuff later)
>
> Antoine
>
>
> [1] http://lists.w3.org/Archives/**Public/public-openannotation/**
> 2012Oct/0004.html<http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0004.html>
> [2] http://lists.w3.org/Archives/**Public/public-openannotation/**
> 2012Nov/0010.html<http://lists.w3.org/Archives/Public/public-openannotation/2012Nov/0010.html>
>
>
>> 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 <mailto:
>> 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><
>> 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
>>
>>
>>
>>
>>
>>
>>
>
>
Received on Thursday, 1 November 2012 17:49:45 UTC