RE: model: multiple resources

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<mailto:jjett2@illinois.edu>

On Mon, Apr 20, 2015 at 3:14 PM, Denenberg, Ray <rden@loc.gov<mailto: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