RE: Multiplicity and Roles

Embedded below.

 

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

 

Hi Tim,

 

I agree with the substance of what you're saying, although I'm missing your point about 'canonical exemplar' being contextual. 

 

Arguably canonical exemplar is contextual information that some might want to say is particular to an annotation, and therefore (I was trying to say) your example where you want to express that a particular item in a set is the canonical exemplar is a better argument for using role on an item or member than the control dataset example. Though I still think it falls short. 

 

The whole purpose of motivation and role is to communicate contextual information. 

 

I would phrase it that role is to communicate particular contextual information – i.e., information about the role of a body or target resource in the annotation.  To express other kinds of contextual information, like the fact that a particular image in a set is the canonical exemplar in that set, I would argue that you need a different predicate.  The question then is whether such a predicate belongs in our annotation ontology. I don't think it does. 

 

I get that we're trying to limit the scope to the annotation but all the proposal really does is say that having a role is a property that SpecificResources can have. It doesn't say anything about roles w.r.t. annotations. 

 

I disagree. I think the proposed resolution does assume that role has a relatively narrow semantic meaning with respect to annotations, and that meaning is limited to annotation bodies and targets – from the introduction, "Some use cases require a role to be associated with a body or target resource, …"

 

We intuitively get that it does because SpecificResources can appear in the context of being objects for hasBody and hasTarget but they can also appear in other contexts within the model. They are not actually particular to those two predicates and, if they were, it would have even larger impacts elsewhere (the entire specifier section would suddenly become incompatible with the multiplicity section).

 

The model includes examples of instances of oa:SpecificResource as bodies and targets.  It does not actually show examples of SpecificResource in any other context, but I think you are correct to the extent that an instance of oa:SpecificResource can appear as an item or member in Choice, Composite or List, when the Choice, Composite or List is a body or target. We probably need to clarify this within the model. While multiplicity classes can be used in other contexts, e.g., when a choice of selectors is available, I don't believe an instance of oa:SpecificResource is allowed as a member of an instance of oa:Choice used to list alternative selectors, but I'm not sure.  This gets pretty abstract… Am I forgetting a use case? Can a selector be a SpecificResource?

 

My point is that since the members of the multiplicity types are allowed to be SpecificResources we'll be leaving the door open for some amount of "tag abuse" since hasRole is a property that all SpecificResources may have. 

 

I don't think the proposal means to assert that all instances of SpecificResource can have hasRole, again the introduction is pretty clear we are talking about the role of annotation bodies and targets, but I may be wrong. Or maybe we need to be clearer about this.

 

"Canonical 

exemplar" may not fit into our existing collection of roles but, since we've provided this convenient bucket for it and nothing prevents someone from extending the collection with it (this was the point of using Skos afterall, so that various communities could extend the collection of roles with ones that we didn't think of at the time or that are particular to their community) its inevitable that someone will invent it or something like it.

 

All ontologies are subject to mis-interpretation. We have to do the best we can with the explanation of what hasRole means.

 

My question is whether or not this is desirable and whether or not we can live with it if undesirable. 

 

With regards to using List to indicate order of preference, that is a promise of the model document. While rdf:List does indicate some arbitrary order, it doesn't actually commit to what that order means. We would have to infer from the presence of choice that the list of things is probably ordered by preference (but really, it could be ordered according to some other criteria and we actually have no way of knowing one way or the other). The rdf:List container is ontologically neutral w.r.t. the context around it.

 

Agreed that it is a promise of the model, but it is explicit in the model, "A Choice has an ordered list of resources from which an application that is consuming the Annotation should select only one to process or display."

 

The rdf:List construct is also a very cumbersome one. Abusing the Role here has the added benefit to the developer of jettisoning the entire rdf:List construct making the serialization much more succinct (all of the Choice members can now share the same pattern as Composite and (oa)List [which is more or less the oa equivalent to rdf:Bag as I recall]).

 

The model says that oa:Choice is in construction equivalent to rdf:Alt, oa:Composite is in construction equivalent to rdf:Bag, and oa:List is a subclass of oa:Composite.  None of them actually depend or try to replicate rdf:List or rdf:Collection for the reasons you suggest.  But they are not exactly equivalent in meaning rdf:Bag and rdf:Alt.  In the model as currently written we introduce order for oa:Choice and oa:List (as indicated by the predicate oa:member).  oa:Composite is explicitly unordered according to the model. From an RDF standpoint the claim that Choice and List are ordered is very tenuous (at best).  

 

I think it's good to work through all of the implications and permutations of adopting the proposed change. A small change to the simplest part of the model may make another part that was already complex, monstrously so or, it may lead to communities using the ontology in inventive ways to craft workarounds for those complex parts.

 

Absolutely

 

I completely agree that data models do have contextual constraints but that's not the way that Specific Resource or the Specifier and Multiplicity sections of the model are written right now and nothing in the proposal text that we have to date changes that. I think the cost for limiting the scope of Role to only SpecificResources that are the objects of hasBody and hasTarget is too high. We'd need a new sub-type of SpecificResource that didn't have Role as a property that could be used for Choice, Composite, and List and with all of the other Specifiers (in my mind hasRole is just another kind of specifier, specifying context in this case) or we'd need to radically rewrite the Specifier and Multiplicity sections all over again.

 

This goes back to making sure we know where oa:SpecificResource is allowed now. As I understand it, but Rob or Paolo can correct me, instances of oa:SpecificResource are allowed directly as an annotation bodies and targets and indirectly as items or members of Choice, Composite and List instances that are bodies or targets (or nested within Choice, Composite or List instances that are bodies are targets). They are not allowed elsewhere. It does get more complicated if they are allowed elsewhere. Whether we need a subclass of SpecificResource to make clear where hasRole can appear and where it can't may be worth a discussion. I hope not, but even if we do it'll be in the model only (I think), not in the JSON serialization. 

 

If we go with SpecificResource only appears as body / target or as member/item in multiplicity class instances appearing as body/target, then one question becomes whether it is a good idea to limit oa:hasRole to instances of oa:SpecificResource that appear directly as annotation bodies and targets (i.e., not allow them on SpecificResources appearing in item or member lists).  That would solve a great deal of what's being discussed here, I think. Whether it would require defining a subclass to clarify this distinction is another matter.

 

The second question becomes whether oa:hasRole is a valid property for Choice, Composite or List instances appearing directly as annotation bodies and targets. Alternatively, if you constrain oa:hasRole to oa:SpecificResource, then if you want to associate a role with a Choice, Composite or List, you have to do so by instantiating a SpecificResource that has as source/content the Choice, Composite or List. 

 

I think the latter question especially is still open. Every time we get close, there's always one more thing…

 

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 Tue, Aug 25, 2015 at 3:09 PM, Timothy Cole <t-cole3@illinois.edu <mailto:t-cole3@illinois.edu> > wrote:

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>  [mailto: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 <mailto:bigbluehat@hypothes.is> >
Cc: Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com> >; t-cole3 <t-cole3@illinois.edu <mailto:t-cole3@illinois.edu> >; Ivan Herman <ivan@w3.org <mailto:ivan@w3.org> >; W3C Public Annotation List <public-annotation@w3.org <mailto: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