- From: Jacob Jett <jjett2@illinois.edu>
- Date: Mon, 24 Aug 2015 08:46:51 -0500
- To: Web Annotation <public-annotation@w3.org>
- Message-ID: <CABzPtBLx-EQ9W9MHg9WtMqRgv4RBZYOoxjARL9Pc1oXSDSdsxg@mail.gmail.com>
On Sun, Aug 23, 2015 at 5:26 PM, Robert Sanderson <azaroth42@gmail.com> wrote: > > Dear all, > > Following from the discussions of the past couple of months, we have > arrived at a concrete proposal for allowing roles / motivations to be > associated with bodies. > > The proposal is documented here: > http://w3c.github.io/web-annotation/model/wd/roles.html > > It has two major sections: > > * Section 3.1 documents the changes that we believe there is consensus > around at this stage. > > We will issue a more formal Call for Consensus regarding this section > momentarily. Please respond in the thread-to-come regarding this entire > section. > The CFC will be open until Tuesday September 1st. > > * Section 3.2 documents additional changes that have arisen. > > Please respond in this thread with reactions to _each_ of the subsections, > 3.2.1 through 3.2.5. As a guideline, if you support the idea just give a > +1. If you don't, please explain why. This isn't a call for consensus, > just a straw poll to see which areas need further discussion. > > Straw Poll for Support: > > * 3.2.1 Require the use of SpecificResource for Bodies > > +0.5 -- What does this do to the multiplicity body types (e.g., choice, composite, etc.)? Are you also proposing to absorb those into the SpecificResource as sub-classes? Are we left with a nesting set of SpecificResources? The text of the proposal is unclear. I'm also not certain that we've considered how this change propagates through various bits and pieces of the model. > * 3.2.2 Require the use of SpecificResource for Targets > > +0.5 -- Same concern as above. > * 3.2.3 Allow hasRole on new EmbeddedTextualBody class > -0 -- As mentioned above, we already have multiple body/target types for multiple bodies/targets (i.e., choice, composite, etc.). I'm not sure I see a down side to adding another one specifically designed to encapsulate strings. > > * 3.2.4 Rename hasSource to hasContent > -1 -- I'm still trying to wrap my head around this one. Is our intent to say that bodies and targets are content containers (i.e., little more than objects)? Is that a different implication than what was implied by hasSource (i.e., this thing was derived from this other thing)? I feel like things only get weirder as you layer on other features like selectors. For instance, we have a specific resource which is scoped and defined by a set of selectors and then we say it "hasContent" and by that we mean the resource from which the SpecificResource was selected from. The semantics are very odd. If folks don't like hasSource, I'd suggest using something like 'derivedFrom' or anything else that suggests that my specially selected sub-portion of a resource is not, in fact, the content of the whole resource. I'm also starting to feel like the entire discussion about roles on bodies and the need to do this using a SpecificResource is distracting us from the true purpose of the SpecificResource. In the first place it was developed as a means to identify sub-portions of resources that serve as the target portion of the annotation and then extended to the Body on the grounds of symmetry. I think it's okay to extend its use to capture role information but renaming the hasSource predicate has some implications for the other (more common) usages of SpecificResource. > > * 3.2.5 Remove motivatedBy completely, rename Motivation to Role > > +1 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 > Many thanks! > > Rob > > > -- > Rob Sanderson > Information Standards Advocate > Digital Library Systems and Services > Stanford, CA 94305 >
Received on Monday, 24 August 2015 13:47:59 UTC