RE: Multiplicity and Roles

Rob-

Agree that for Choice we lack compelling use cases that would require assigning roles to individual member resources. 

But if you define oa:hasRole as solely the way to express the role of a body or target in an annotation, I also do not think you need this expressiveness for Composite or List. The rationale for putting something in Composite or List rather than just having multiple bodies or targets is because the group of resources need to be included in the annotation as a set, either ordered or unordered.  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. oa:hasRole is not used to express role within the set (or we would need additional terms).  To assign oa:hasRole to an individual item or member within a Composite or List is to assign to that item or member a role in the Annotation while simultaneously saying it is only in the Annotation as part of a set. This I think has unintended consequences.

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.  As regards this issue, I would personally prefer:

1. hasRole allowed directly on SpecificResource, Choice, Composite, List and EmbeddedTextualBody. 

2. type is optional for Specific Resource, Composite and EmbeddedTextualBody, but still required for Choice and Composite.

-Tim Cole 

> -----Original Message-----
> From: Ivan Herman [mailto:ivan@w3.org]
> Sent: Monday, August 24, 2015 11:08 AM
> To: Robert Sanderson <azaroth42@gmail.com>
> Cc: W3C Public Annotation List <public-annotation@w3.org>
> Subject: Re: Multiplicity and Roles
> 
> 
> > On 24 Aug 2015, at 17:44 , Robert Sanderson <azaroth42@gmail.com>
> wrote:
> >
> >
> > The (very valid) concern raised by Jacob and Stian is that the proposal as it
> stands does not mention multiplicity at all, being Choice, Composite and List.
> >
> > If role should be only on SpecificResource, then the content/source for it
> would have to be the multiplicity construct, such as:
> >
> > {
> >   "type": "Annotation",
> >   "target": "http://example.com/target",
> >   "body": {
> >      "role": "commenting",
> >      "content": {
> >          "type": "Choice",
> >          "members": [
> >              "http://comment.example.org/en",
> >              "http://comment.example.org/fr"
> >           ]
> >        }
> >    }
> > }
> >
> > Which doesn't seem too bad to me. Would be great to get other folks'
> reactions to this particular case.
> 
> I agree with you. It is a fairly obvious combination with what we have in the
> proposal. It is a bit complex, but the example is complex...
> 
> 
> >
> >
> > It becomes more complex for Composite or List, as there would be the
> specific resource for the Choice/List within the Annotation, and then the
> specific resource to associate the role with the actual resource.  That said, the
> pattern is consistent and reliable, if deeply nested.
> >
> > {
> >   "type": "Annotation",
> >   "target": "http://example.com/target",
> >   "body": {
> >      "content": {
> >          "type": "List",
> >          "members": [
> >            {
> >               "role": "commenting",
> >               "content": "http://comment.example.org/en"
> >            },
> >            {
> >               "role": "tagging",
> >               "content": {
> >                  "text": "tag"
> >                }
> >            }
> >           ]
> >        }
> >    }
> > }
> >
> > This structure does make the lack of type more concerning, as the
> members of the Choice or List could be anything, and not necessarily
> consistent within any individual construct.
> 
> I am not sure what the problem is, I must admit.
> 
> Ivan
> 
> >
> >
> > Rob
> >
> > --
> > Rob Sanderson
> > Information Standards Advocate
> > Digital Library Systems and Services
> > Stanford, CA 94305
> 
> 
> ----
> Ivan Herman, W3C
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
> 
> 
>

Received on Monday, 24 August 2015 16:57:23 UTC