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

Re: F2F Decision: Multiple Resources - RDF

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Thu, 1 Nov 2012 20:20:06 +0100
Message-ID: <5092CB66.2000804@few.vu.nl>
To: public-openannotation <public-openannotation@w3.org>

I think I agree with much of what you say below (with the exception of the one on serialization: it reads like a pro for RDF, in fact!).
I'd say compatibility with RDF is an absolute requirement. But compatibility doesn't imply full equivalence and/or lossless data round-triping. If there are constructs that are impossible to capture fully in RDF, then so be it.
I'd just welcome note that about the features that are "degraded" (I expect that we will never fully lose something) when implementing the annotation model in RDF, and which are faithfully represented in alternative syntaxes like JSON.

By the way JSON is good but I'm wondering whether would solve everything. There are probably some issues under the carpet. For example, wouldn't there be an issue when we have to recommend the "non-interpretation" of the order of values in the array of an oa:Set? (of course you could represent an oa:Set as an object, but that may look a weird choice in simplicity-seeking JSON...)


> 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>
>         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 19:20:36 UTC

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