Re: Textual Note example

The options that we've looked at in the past are:

1.  Multiple Bodies

The annotation is allowed to have multiple bodies, where each body is an
alternative in the same way as multiple Specifiers.
Pro:  Really easy!
Con: People will abuse multiple bodies for non-alternatives
Mitigation: When only one body shows up, the annotator/developer may fix
their semantics

Anno oa:hasBody X ;
    oa:hasBody Y .


2.  Choice

A Structured Body, with a type that expresses it's a Choice between
multiple alternatives.  There can be a default and then one or more other
options.
For example: http://www.shared-canvas.org/datamodel/spec/#Choice

Pros:  No confusion, retains single body model, allows a default to be
specified explicitly
Cons: You need to understand the structured body

Anno oa:hasBody uuid1 .

uuid1 sc:default X ;
  sc:option Y .


3.  alternate

There is a single body and it has an "alternate" relationship with other
equivalent resources.

Pros:  Still single body, still a default (X) but without the structure to
understand
Cons:  Maybe Y is only a good alternative in this annotation but not for
all uses of X.  The chances of collision increase significantly and you
have to chain all the way through all alternates from X -- eg Y may also
have an alternate Z

Anno oa:hasBody X ;
X :alternate Y .


My order of preference at the moment is: 2, 1, 3
However I could be swayed towards 1 if we also have CompositeAnnotation and
get rid of hasSemanticTag as the documentation (at least) would be very
clear as to how to achieve multiple bodies in the ALL OF sense rather than
the ANY OF sense.

Rob


On Fri, Aug 17, 2012 at 8:38 AM, Leyla Jael García Castro <
leylajael@gmail.com> wrote:

> Hi Paolo, Bob, all,
>
>
> We thought about the CompositeAnnotation for aggregating annotations that
>> has been produced together - in the same context and about same time. For
>> aggregating annotation produced at different times I would simply suggest
>> the creation of an annotation set by ore:Aggregation
>>
>
> Understood, but still I can achieve that also with a structured body using
> an rdf:Bag as Body, am I right? So, what would be the
> advantage/disadvantage of Composite Annotations? I like more the rdf:Bag as
> body as it implies less triplets, and... it is maybe closer to multiple
> bodies?
>
> Leyla
>
>
> On Fri, Aug 17, 2012 at 1:52 PM, Paolo Ciccarese <
> paolo.ciccarese@gmail.com> wrote:
>
>> I just realized that my previous message did not go through probably for
>> the attachments.
>> These are the links to the two figures
>>
>> http://www.w3.org/community/openannotation/wiki/images/1/10/Possible_representation_of_Comment_in_Multiple_languages_opt1_by_Paolo_Ciccarese.png
>>
>> http://www.w3.org/community/openannotation/wiki/images/0/01/Possible_representation_of_Comment_in_Multiple_languages_opt2_by_Paolo_Ciccarese.png
>>
>> On Fri, Aug 17, 2012 at 8:39 AM, Leyla Jael García Castro <
>> leylajael@gmail.com> wrote:
>>
>>> Hi Paolo,
>>>
>>> What about a third possibility having the only one body modelled as
>>> rdf:Bag? That one would work fine with the current cardinality restriction
>>> on Body and it would also tied the bodies together.
>>>
>>
>> I think you are talking about what we call 'structured body' or
>> 'structured resource'
>> http://www.openannotation.org/spec/extension/#StructuredBody
>>
>>
>>>
>>> I like the Composite approach for annotations meant to be together by
>>> maybe done by different users at different times. For multiple related
>>> annotations, translations for instance, done by the same user at the same
>>> time, I prefer to use rdf:Bag in the Body. The tricky thing is that we
>>> could end up having a Composite for translations done by different users
>>> and rdf:Bag in the Body for translations done by the same user as a single
>>> annotation... would that make sense?
>>>
>>
>> We thought about the CompositeAnnotation for aggregating annotations that
>> has been produced together - in the same context and about same time. For
>> aggregating annotation produced at different times I would simply suggest
>> the creation of an annotation set by ore:Aggregation
>>
>>
>>
>>>
>>>
>>>
>>> On Fri, Aug 17, 2012 at 1:22 PM, Paolo Ciccarese <
>>> paolo.ciccarese@gmail.com> wrote:
>>>
>>>> Bob and Layla,
>>>> here are two examples one using CompositeAnnotation - *brainstorming* -
>>>> and the other multiple bodies * currently not allowed *.
>>>>
>>>> The first is more inline with what we have now in the draft but it
>>>> requires more triples. The second is more compact but is making use of
>>>> multiple bodies which are not currently permitted.
>>>>
>>>> I haven't picked a mechanism for specifying the language yet. I am open
>>>> to any of the  solutions listed by Layla.
>>>>
>>>> Anybody else in the group has some thoughts on this topic or  needs to
>>>> deal with translations?
>>>>
>>>> Paolo
>>>>
>>>> ps: I apologize for the big warnings on the figures.
>>>>
>>>>
>>>> On Fri, Aug 17, 2012 at 7:53 AM, Paolo Ciccarese <
>>>> paolo.ciccarese@gmail.com> wrote:
>>>>
>>>>> The CompositeAnnotation is basically supposed to be a
>>>>> subClass of rdf:Bag or ore:Aggregation
>>>>>
>>>>>
>>>>> On Fri, Aug 17, 2012 at 7:51 AM, Bob Morris <morris.bob@gmail.com>wrote:
>>>>>
>>>>>> On Fri, Aug 17, 2012 at 6:21 AM, Leyla Jael García Castro
>>>>>> <leylajael@gmail.com> wrote:
>>>>>> > Hi Bob,
>>>>>> >
>>>>>> > The range for cnt:chars is a Literal so you can use a language tag
>>>>>> to
>>>>>> > specify the language used in that particular text. Another
>>>>>> possibility would
>>>>>> > be dct:language property.
>>>>>> >
>>>>>> > As for expressing in different languages the same annotation, I
>>>>>> guess there
>>>>>> > are different approaches. The same body, for instance, could be
>>>>>> applied to
>>>>>> > multiple targets representing the same content in different
>>>>>> languages;
>>>>>> > another scenario as you mentioned is having the same textual body in
>>>>>> > different languages, all of them applied to the same target.
>>>>>> >
>>>>>> > For the second scenario, having different bodies is not possible in
>>>>>> OA, but
>>>>>> > maybe having a List or Sequence as body would work? Each member of
>>>>>> the list
>>>>>> > would be then a cnt:ContextAsText with its own language and
>>>>>> corresponding
>>>>>> > text.
>>>>>> >
>>>>>> > any thoughts?
>>>>>> In our pending manuscript, we sort of favor the container solution  as
>>>>>> the simplest multiplicity disambiguation.  Maybe for this rdf:Bag
>>>>>> would be more appropriate even though, I believe, there is no formal
>>>>>> difference from the ordered containers.   This might be more
>>>>>> lightweight than the CompositeAnnotation Paolo suggests in parallel
>>>>>> email. I don't know if that is good or bad.
>>>>>> >
>>>>>> > Leyla
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Aug 17, 2012 at 4:22 AM, Bob Morris <morris.bob@gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> Paolo-
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> http://www.w3.org/community/openannotation/wiki/Annotating_a_Webpage_with_a_Textual_Note
>>>>>> >>
>>>>>> >> With the oa:Body typed as cnt:ContentAsText, is there a way to
>>>>>> specify
>>>>>> >> the language of the cnt:chars?  It doesn't seem that there is a
>>>>>> way in
>>>>>> >> cnt.  I wonder why? One might have to annotate with ContentAsXML to
>>>>>> >> express the language, which is overkill.
>>>>>> >>
>>>>>> >> A related use case is the expression of an Annotation in several
>>>>>> >> different languages. If forced to make them as separate
>>>>>> Annotations,
>>>>>> >> it would be tricky to express that they are meant all to express
>>>>>> the
>>>>>> >> same Textual Note.  Maybe this means that the cnt:ContentAsText
>>>>>> should
>>>>>> >> not be the type of the oa:Body, but rather of something that can
>>>>>> hang
>>>>>> >> on the Body without any cardinality restrictions.
>>>>>> >>
>>>>>> >> Bob
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Robert A. Morris
>>>>>> >>
>>>>>> >> Emeritus Professor  of Computer Science
>>>>>> >> UMASS-Boston
>>>>>> >> 100 Morrissey Blvd
>>>>>> >> Boston, MA 02125-3390
>>>>>> >>
>>>>>> >> IT Staff
>>>>>> >> Filtered Push Project
>>>>>> >> Harvard University Herbaria
>>>>>> >> Harvard University
>>>>>> >>
>>>>>> >> email: morris.bob@gmail.com
>>>>>> >> web: http://efg.cs.umb.edu/
>>>>>> >> web: http://etaxonomy.org/mw/FilteredPush
>>>>>> >> http://www.cs.umb.edu/~ram
>>>>>> >> ===
>>>>>> >> The content of this communication is made entirely on my
>>>>>> >> own behalf and in no way should be deemed to express
>>>>>> >> official positions of The University of Massachusetts at Boston or
>>>>>> >> Harvard University.
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Robert A. Morris
>>>>>>
>>>>>> Emeritus Professor  of Computer Science
>>>>>> UMASS-Boston
>>>>>> 100 Morrissey Blvd
>>>>>> Boston, MA 02125-3390
>>>>>>
>>>>>> IT Staff
>>>>>> Filtered Push Project
>>>>>> Harvard University Herbaria
>>>>>> Harvard University
>>>>>>
>>>>>> email: morris.bob@gmail.com
>>>>>> web: http://efg.cs.umb.edu/
>>>>>> web: http://etaxonomy.org/mw/FilteredPush
>>>>>> http://www.cs.umb.edu/~ram
>>>>>> ===
>>>>>> The content of this communication is made entirely on my
>>>>>> own behalf and in no way should be deemed to express
>>>>>> official positions of The University of Massachusetts at Boston or
>>>>>> Harvard University.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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.
>>>>
>>>>
>>>
>>
>>
>> --
>> 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.
>>
>>
>