Re: model: multiple resources

Then as Rob says, they should be treated as multiple bodies and targets.

Realistically, you still won't be able to accomplish the "any order you
want" because there will be an arbitrary order explicitly laid out in the
serialization. Unless someone is going to take the extra steps of adding
some kind of randomizer to their serialization writing or ingestion service
then the order will still be their. Something I might expect would be some
kind of sorting algorithm for "groups" on ingestion (and maybe on
serialization) but this works equally well for multiple bodies/targets and
lists.

So again, I don't see why we would need an additional grouping entity when
the essential semantics are already handled a number of ways in the
existing model.

Regards,

Jacob


_____________________________________________________
Jacob Jett
Research Assistant
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu

On Mon, Apr 20, 2015 at 4:32 PM, Denenberg, Ray <rden@loc.gov> wrote:

>  Hi Jacob -
>
> Definitely not a composite.  It’s saying, process them independently, in
> any order you like, and if you only get through half of them, no problem.
>
>
>
> Yes, you COULD treat is as a list, but I explicitly don’t want to do that
> because of the implication that they have to be processed in the order
> specified.  That means that there has to be an order specified. Specifying
> an order in RDF imposes a significant  burden  (which may not be obvious
> from serializations other than n-triples or RDF/XML).
>
>
>
> rAY
>
>
>
> *From:* jgjett@gmail.com [mailto:jgjett@gmail.com] *On Behalf Of *Jacob
> Jett
> *Sent:* Monday, April 20, 2015 4:30 PM
> *To:* Web Annotation
> *Subject:* Re: model: multiple resources
>
>
>
> Hi Ray,
>
>
>
> I feel like there are two ways to interpret your example, neither of which
> require a 4th "group" entity.
>
>
>
> In  my first interpretation, the example you lay out seems like an
> unordered list type of entity, in which case the list structure seems to be
> most appropriate (even unordered lists have orders, they're just arbitrary
> ones).
>
>
>
> The other way I interpret your example is that the your body is actually a
> composite but, you would like a method to gracefully fail should one of the
> parts of the composite not resolve correctly (or resolve at all). This
> would be useful in that the tool would still present what it could of the
> composite annotation to the end user. This seems like it would need to be
> handled through best practices.
>
>
>
> Regards,
>
>
>
> Jacob
>
>
>
>
>   _____________________________________________________
>
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164
> jjett2@illinois.edu
>
>
>
> On Mon, Apr 20, 2015 at 3:14 PM, Denenberg, Ray <rden@loc.gov> wrote:
>
> For multiple bodies/targets  we have (1) choice, (2) composite, (3)
> list.   I think there should be a fourth.
>
>
>
> Let’s call it (4) group.
>
>
>
> Suppose I have 10 annotations that I want to submit for a resource and let’s say they all have the same metadata. So I decide instead of 10 annotations, to submit a single annotation with 10 bodies.   “Composite” doesn’t seem to fit this situation:  “A Composite is a set of resources that are all required for an Annotation to be correctly interpreted.”  I feel there is a distinction between, on one hand, grouping a bunch of bodies into a single annotation for efficiency purposes, versus, on the other hand, multiple bodies which only make sense as a composite. In the first case, if one of those bodies cannot be processed, the other nine can; in the second case, no.
>
>
>
> And instead of:
>
>
>
> <anno1> a oa:Annotation ;
>
>     oa:hasTarget <target1> ;
>
>     oa:hasBody [
>
>         a oa:Group ;
>
>         oa:item <body1> ;
>
>         oa:item <body2> .
>
>
>
> You could say:
>
>
>
> <anno1> a oa:Annotation ;
>
>     oa:hasTarget <target1> ;
>
>     oa:hasBody <body1> ;
>
>     oa:hasBody <body2> .
>
>
>
> So “group” would sort of be the default, that is, multiple bodies without a “multiplicity type”  would default to “group”.
>
>
>
> (And there’s probably a better name than “group” but I can’t think of one offhand.)
>
>
>
> Ray
>
>
>
>
>