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. The whole purpose of
motivation and role is to communicate contextual information. 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. 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).

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.
"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.

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.

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]).

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.

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.

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

On Tue, Aug 25, 2015 at 3:09 PM, Timothy Cole <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] *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>
> wrote:
>
> On Mon, Aug 24, 2015 at 2:20 PM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>
>
> Hi Tim,
>
>
>
> On Mon, Aug 24, 2015 at 12:54 PM, Timothy Cole <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
>
>
>
>
>
>
>