Re: F2F Decision: Multiple Resources - into oax?

On 11/2/12 2:57 PM, Paolo Ciccarese wrote:
> 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.


+1. It's a good idea to explicitly point from the Core to the Extension, for the implementers interested in finer grain.

Antoine


> Paolo
>
> On Thu, Nov 1, 2012 at 5:54 AM, Antoine Isaac <aisaac@few.vu.nl <mailto: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.
>

Received on Friday, 2 November 2012 14:02:11 UTC