F2F Decision: Multiple Resources

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 Monday, 1 October 2012 19:36:20 UTC