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.

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.

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)?

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.


Regards,

Jacob






>
>> Rob
>>
>>
>