Re: F2F Decision: Multiple Resources

I don't see a problem with it, but should definitely be
oax:asIncludedIn, as it can be used for both Body and Target.
asAnnotatedIn would imply it could only be used for the target.

Rob

On Mon, Oct 29, 2012 at 2:21 PM, Paolo Ciccarese
<paolo.ciccarese@gmail.com> wrote:
> Hi Jacob,
> I've never thought about the use of oax:annotatedIn for targeting one of the
> bodies.
> However, that seems an interesting use case.
>
> Is this what you mean?
>
> _: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> .
>
> _:y a oa:Annotation ;
>   oa:hasBody <body> ;
>   oa:hasTarget <comment-in-french> ;
>   oa:annotatedIn _:x .
>
> After Chicago [1], the decision was to introduce a new predicate:
> oax:annotatedIn from a
> SpecificResource to any Resource (including a SpecificResource). The idea
> was simply to identify
> something the user was looking at when performing the annotation.
>
> That is very easy to understand when I think of an HTML document embedding
> other media.
> The question is if we want to extend that definition to annotation of
> annotation parts.
>
> Would anybody see a problem is using the property oax:annotatedIn (or the
> later proposed
> oax:asIncludedIn) for the annotation of annotation parts use case?
>
> Paolo
>
>
>
> [1]
> http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0003.html
>
> On Mon, Oct 29, 2012 at 3:22 PM, Jacob Jett <jgjett@gmail.com> wrote:
>>
>> ...but couldn't this already be done in the model by annotating the
>> initial multi-body (oa:Choice) annotation? More specifically, couldn't we
>> annotate one of the choices and use the context predicate "oax:annotatedIn"
>> to capture the annotating an annotation bit?
>>
>> It seems like this might be very useful for your use case where, if we
>> were to model the different distinct possibilities as one oa:Choice, you
>> could then add an annotation targeting one of the objects of an oa:item
>> predicate within that choice, e.g., 'this is our default choice and here is
>> why', and use oax:annotatedIn to denote that this annotation noting a
>> default choice and the reasoning why (i.e., the evidence), was made in the
>> context of an oa:Choice.
>>
>> The modeling is complex but it seems like this would service the needs of
>> your use case without adding additional properties to the specification.
>> Does that seem sensible? Seems like there are some other ways to do this
>> too, including adding additional properties.
>>
>> Regards,
>>
>> Jacob
>>
>>
>> On Mon, Oct 29, 2012 at 1:46 PM, Bob Morris <morris.bob@gmail.com> wrote:
>>>
>>> A typical use case for us would be a taxonomist's annotation of an
>>> image, or of a morphological description,  of  an organism for which
>>> the annotator is offering several different possible distinct species
>>> as an identification, but with no ability to say which of those
>>> species it may be.  In such cases, an "arbitrary" choice on the part
>>> of the consumer is not going to be based on preference, but on some
>>> kind of scientific evidence which possibly arises from related
>>> resources, or even from part of an annotation dialogue.  A second
>>> annotator, not the Target publisher,  who acquires the first
>>> annotation might well launch an annotation of the form "In Annotation
>>> X, I don't know what species the Target is, but I know it isn't
>>> Alternative A, and here's my evidence for that."   This is also likely
>>> to be a typical biomedical application where the resources are patient
>>> examination data and the goal is a medical diagnosis. In fact,
>>> taxonomists often refer to the descriptive data that distinguishes one
>>> species from another as"diagnostic characters."
>>>
>>> (Remark: in science, all choices between hypotheses are based on
>>> evidence, which is why I'm gathering use cases to make a case for
>>> adding Evidence modeling to OA.  I'd even go so far as to suggest that
>>> \all/ scholarship needs Evidence sooner or later to support its
>>> assertions....)
>>>
>>> Bob Morris
>>>
>>>
>>> On Mon, Oct 29, 2012 at 11:33 AM, Robert Sanderson <azaroth42@gmail.com>
>>> wrote:
>>> > The XOR or Choice is to select one and only one of the resources.  For
>>> > example, if there are three translations of the same comment, a system
>>> > should display only one of them as appropriate for the user's
>>> > preferences (and potentially allow the user to se the other options).
>>> > On the other hand, given an oa:Set of three comments, all three should
>>> > be displayed.
>>> >
>>> > Hope that helps,
>>> >
>>> > Rob
>>> >
>>> > On Mon, Oct 29, 2012 at 4:44 AM, Leyla Jael García Castro
>>> > <leylajael@gmail.com> wrote:
>>> >> Hi Bob,
>>> >>
>>> >> Do you have a use case for the ao:XOR? Not so sure whether I
>>> >> understand it.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Leyla
>>> >>
>>> >>
>>> >> On Sun, Oct 21, 2012 at 11:16 PM, Bob Morris <morris.bob@gmail.com>
>>> >> wrote:
>>> >>>
>>> >>> With respect to the Multiple Resources model[1] that emerged in
>>> >>> Chicago
>>> >>>
>>> >>> 1. It would be nice if the Issues List reflected what Rob's initial
>>> >>> proposal morphed into, and the discussion continued there. (Rob: I'll
>>> >>> have a
>>> >>> try if you want...)
>>> >>>
>>> >>> 2. oa:Set and probably oa:List can profitably be applied to  a
>>> >>> collection
>>> >>> of oa:Annotations.  The use case is actionable annotations that are
>>> >>> delivered to remote agents,  and upon which collections of expected
>>> >>> actions
>>> >>> must taken, possibly in a prescribed order.  This is particularly
>>> >>> needed
>>> >>> when actionable annotations will generate response annotations (e.g.
>>> >>> "Agent
>>> >>> Smart accepted all of your corrections in the oa:Set :mySet1 except
>>> >>> the
>>> >>> oa:item :mySet1.item10.").  If a collection of actionable annotations
>>> >>> travels in a disconnected fashion, the annotation publisher can not
>>> >>> easily
>>> >>> (at all?) convey that a coordinated action is desired.  There may be
>>> >>> an
>>> >>> argument for ao:XOR on collections of annotations also.  It's likely
>>> >>> that
>>> >>> none of these collection types should be restricted to Target, Body,
>>> >>> and
>>> >>> Specifiers, as is perhaps being suggested in [1]
>>> >>>
>>> >>> 3.  Probably oa:List objects cannot(?) survive being put in a triple
>>> >>> store, since order of identified nodes is not defined in the graph.
>>> >>> [2] is a
>>> >>> proposal to address the issue, but it is unclear how much traction it
>>> >>> has.
>>> >>> This means that  processing order for oa:List will depend on the
>>> >>> serialization, not on the RDF.  I vaguely recall this was raised in
>>> >>> Chicago,
>>> >>> perhaps tabled for more discussion.
>>> >>>
>>> >>> [1]
>>> >>>
>>> >>> http://lists.w3.org/Archives/Public/public-openannotation/2012Oct/0004.html#start4
>>> >>> [2] http://www.w3.org/2009/12/rdf-ws/papers/ws14
>>> >>>
>>> >>> Bob Morris
>>> >>>
>>> >>> --
>>> >>> 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.
>

Received on Monday, 29 October 2012 22:31:36 UTC