Re: F2F Decision: Multiple Resources - into oax?

Hi Rob, Paolo,

Thanks for this: it's quite a feat that you managed to capture almost all what we discussed in such a short mail. One only misses our nice drawings ;-)

Given the complexity of the matter, and the fact that some decisions may be seen as questionable by some (why duplicating RDF containers, even if it is on a temporary basis?) I'd favor however to put all the machinery for multiple resources in some Appendix or even better, in the oax extension...


> 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:54:35 UTC