Hi Bill, Thanks for your input into the discussion! On Fri, Aug 28, 2015 at 5:33 PM, Bill Hunt <bill@opengovfoundation.org> wrote: > > I understand that the consensus is that my suggestion wouldn't work > because you'd have to define every role as it would appear - which is hard > since we can't predict everything anyone would ever want to do. My > argument was that 99% of roles could be defined in a very narrow set of a > half dozen or so; anyone who's doing something else or wants to create a > new role wouldn't be handled by a "standard" consumer so they'd be off the > map anyway. > I think that, happily, we can easily put this to rest. There are already a dozen motivations defined in the model [1], and your use case did not fit into those 12, as there isn't a motivation that's explicitly the text to replace target text with. So in order to fulfill your use case, you would be outside of the standard too. The 12 were already trimmed down from longer lists of motivations by looking across many use cases and previous research in the OAC and OA-CG days. In the IIIF use case, we had to define a new motivation (painting), and that's likely insufficient and we'll need at least 3 further motivations as narrower concepts of it to clarify expected client behavior (transcribing, translating, editing [in the sense of creating a textual edition of a work]) [2]. So, I hope that you can see that 99% of roles really won't fit into half a dozen, and hence property-as-role really doesn't work for interoperability without the significant overhead of RDF inferencing to determine how they relate to hasBody or hasTarget. Thanks, Rob [1] http://www.w3.org/TR/annotation-model/#motivations [2] http://iiif.io/api/presentation/2.0/#image-resources -- Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305
Received on Saturday, 29 August 2015 02:04:13 UTC