RE: Multiplicity and Roles

Jacob-

 

A general comment that we need to be careful about requiring support for scenarios in the abstract that would never occur in the wild, so to speak. More specific comments embedded below.

 

From: jgjett@gmail.com [mailto:jgjett@gmail.com] On Behalf Of Jacob Jett
Sent: Tuesday, August 25, 2015 1:16 PM
To: Benjamin Young <bigbluehat@hypothes.is>
Cc: Robert Sanderson <azaroth42@gmail.com>; t-cole3 <t-cole3@illinois.edu>; Ivan Herman <ivan@w3.org>; W3C Public Annotation List <public-annotation@w3.org>
Subject: Re: Multiplicity and Roles

 

On Tue, Aug 25, 2015 at 12:31 PM, Benjamin Young <bigbluehat@hypothes.is <mailto:bigbluehat@hypothes.is> > wrote:

On Mon, Aug 24, 2015 at 2:20 PM, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com> > wrote:

 

Hi Tim,

 

On Mon, Aug 24, 2015 at 12:54 PM, Timothy Cole <t-cole3@illinois.edu <mailto:t-cole3@illinois.edu> > wrote:

The individual items or members of the set are not meant to be understood in the context of the annotation independently, or why would you put them in Composite or List.  While the resources in the set may have roles within the set, it is the role of the set as a whole in the annotation that is expressed using oa:hasRole.

 

So I think we only need to worry about whether the role is assigned directly to the Choice, Composite, List instance or whether role is assigned to the Choice, Composite, List instance via a SpecificResource that has the multiplicity class instance as its content/source.  

 

 

To be clear, meaning that we don't need to consider per-resource roles within the Composite or List?  And hence it's just the same as Choice?

 

I think that makes sense.

 

+1

 

 

If I understand Tim's proposal correctly, oa:hasRole also becomes a property for the Choice, Composite, and List types. 

 

This would be an optimal solution; however, I'm not clear on whether or not this means we can add Roles to the members that nest inside of these containers. See more below.

 

 

Making this clear should only help alleviate likely confusion afaict.

 

  Does anyone have an example use case that would require this?

 

I can't think of any situation where you'd want a Composite or a List with varying roles. It sounds like a recipe for disaster...actually. :)

 

 

I can think of a few times an annotator might want to indicate more specific roles for the resources inside a Composite container. Take an annotation targeting juxtaposed images. The juxtaposition is what is being annotated but the annotator wants to indicate that one image in the composite whole is a canonical exemplar while the other is being compared to it. Similar use cases exist for tabular science data where I have one group of control data and another group of experimental data.

 

I would express these as attributes of the individual resources using properties in a non-oa namespace, not as different roles played in the annotation. 

 

This is clearly the way to go with the science data example. That DataSet1 is from a control group and DataSet2 is from a treatment group are true statements irrespective of the annotation. If they together comprise a composite target in the annotation, then the body is saying something about them collectively and their role in the annotation is a collective role.  

 

Your juxtaposition example is a little more borderline. Juxtaposition is a Composite use case and being the 'canonical exemplar' in a set of images sounds a bit more contextual, but I'm not convinced.  I'm also not convinced that canonical exemplar though important to the juxtaposition in some ways fits in our current ontology of annotation motivations / roles. Compare to classify, comment, describe, edit, highlight, bookmark, identify, link, moderate, question, reply, tag.  Canonical exemplar in a set of resources sounds less like an annotation role and more like a type of attribute one would assign to a member in a set – at which point you are no longer talking annotation role but rather talking some other kind of property, I think. I would rather not go there in our annotation model and let communities that need such expressiveness create and use ontologies in their own namespaces. 

 

In the case of Choice, having the ability to express a preference for a particular choice or to rank the choices (and this might be an abuse of the intent of Choice) through the form of Role might present a better solution for some of the discussions we had in OAC and the OACG about what to do when the annotator wants to present the consumer or rendering agent with a variety of equivalent resources (e.g., the same exact image available via multiple servers or in multiple formats) and leave the choice of what to render up to the system's decision making capacities.

 

The way we dealt with this was to make Choice an ordered list, so that preference could be expressed, albeit with no way to say whether the order was important or unimportant. But in any event, I don't think that rank fits with our definition of role in annotation. 

 

Somewhat more problematic, since the range of oa:member includes SpecificResource, how do we propose to limit the use of oa:hasRole without damaging an annotator's ability to include specified portions of resources as members in the container (e.g., as in the case where my composite consists of multiple specified portions of a single image)?

 

This may be a valid concern, but one we might be able to live with.  

 

Will it be necessary to create yet another sub-class of SpecificResource that let's us still employ non-role specifiers? Or should we place a note in the model document that limits the scope of a Role to just it's parent's context? (I.e., Role w.r.t. a Body or Target describes that resource's role vis-a-vis inside the annotation (i.e., the relationship of the body to the target), Role w.r.t. a Composite or List member describes that resource's role vis-a-vis inside that composite entity or list (i.e. the relationship of that member to the other members).)

 

This latter kind of scoping seems like it would be intuitive but that assumption (that developers or users find it intuitive) hasn't usually been borne out in library or industry data systems.

 

I would normally want to say that Role in this case is out-of-scope for what we're trying to develop, except that we invented Choice and Composite specifically for the ontology and specifically with the idea that SpecificResources, among other things, would be members in them. It doesn't make sense if hasRole is some kind of situational property of the SpecificResource. 

 

I guess I would disagree. In my experience many data models do have constraints that are specific to context. Of course it may be that I encounter too many poor quality data models. 

 

Regards,

 

Jacob

 

 

 

 

 

 

Rob