Re: F2F Decision: Multiple Resources - into oax?

I think putting these topics in the extensions is ok as it will lower the
learning curve of those that approach the core for the first time.

Now that multiple bodies are allowed, we just have to make clear, in the
core document, what is the semantic (or non-semantic) interpretation of
multiple resources without any additional structure. Then we can link to
the extensions for more complex structures.

Paolo

On Thu, Nov 1, 2012 at 5:54 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> 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...
>
> Antoine
>
>
>
>  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
>>
>>
>
>


-- 
Dr. Paolo Ciccarese
http://www.paolociccarese.info/
Biomedical Informatics Research & Development
Instructor of Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
+1-857-366-1524 (mobile)   +1-617-768-8744 (office)

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s),
may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to
any other party without the permission of the sender.
If you have received this message in error, please notify the sender
immediately.