Re: Roles Proposals

On Sun, Aug 23, 2015 at 5:26 PM, Robert Sanderson <>

> 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:
> 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

> * 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



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

> 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