- From: Denenberg, Ray <rden@loc.gov>
- Date: Tue, 21 Apr 2015 13:14:49 -0400
- To: Jacob Jett <jjett2@illinois.edu>, Web Annotation <public-annotation@w3.org>
Here's my point. I don't want to have to say: <anno1> a oa:Annotation ; oa:hasTarget <target1> ; oa:hasBody [ a oa:List ; oa:member <body1> ; oa:member <body2> . This explicitly lists an order and imposes significant overhead. I want to say: <anno1> a oa:Annotation ; oa:hasTarget <target1> ; oa:hasBody <body1> ; oa:hasBody <body2> . Rob implies that this is valid. I just want to be sure. Ray ________________________________________ From: jgjett@gmail.com [jgjett@gmail.com] On Behalf Of Jacob Jett [jjett2@illinois.edu] Sent: Monday, April 20, 2015 5:39 PM To: Denenberg, Ray; Web Annotation Subject: 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<mailto:jjett2@illinois.edu> On Mon, Apr 20, 2015 at 4:32 PM, Denenberg, Ray <rden@loc.gov<mailto: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> [mailto: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<tel:%28217%29%20244-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
Received on Tuesday, 21 April 2015 17:18:34 UTC