hasRoles capability

See also discussion thread at https://groups.google.com/d/msg/distributed-text-services/ET7XnQx4RG8/brE4ItsTAQAJ

The collections hasRoles capability is intended to enable the publisher of a collection to assert that a member item of a collection has one or more special roles in the context of that collection. Two important assumptions motivate this design:

1. Member items of a collection can exist on their own outside of any given collection and may belong to multiple unrelated collections, published by the same or different publishers

2. An item may take on a special meaning that only applies within the context of a given collection

Original Intent

The follow two use cases drove the original thinking behind the design:

In the CTS model, a Work is a collection which contains multiple editions and translations as member items. The publisher of a CTS collection may want to designate one of these editions as the 'default' edition to be served for a work. Which edition is the 'default' may change over time as new editions are added to the collection.

In the SCTA model, expressions contain collections of manifestations. One of those manifestations may be deemed the "canonical" manifestation within the context of that collection.

In these two use cases, "default" and "canonical" are similar but may not convey the exactly same meaning, nor the same implications for clients of the collection. But each are special roles that apply to member items only in relation to their presence in the collection.

Extended Usage

The Beta maṣāḥǝft model has collections contained up of members which each have a different relationship to the parent collection. For example a collection of hymns has member items with relationships to the parent collection such as saws:formsPartOf, saws:isAttributedToAuthor, saws:follows, ecrm:P129_is_about.

Follow up from Jeff

The cases Bridget describe cohere with my original understanding.

However, I would also add that I also understood roles as a way to create separate categories / subclasses of different types of "members".

If we're only talking about workGroups having members, then it might seem obvious that the members of a workGroup are works. And that's that.

But it's not so obvious if a collection can extend to chapter 1 in a text.

Chapter 1 may contain parts (such as section 1, section 2), but chapter 1 might also have 1, 5, or 100, manifestations/versions. These can be considered members of the chapter 1 collection, but they are certainly different.

Roles could be a way to classify these different kinds of members.

A diagram is a very hard to draw because what I imagine here is a three-dimensional tree. But here's an attempt.

In this picture, chapter 1 at the center would be the collection and would have at least two kinds of members. 1. Sections and Manifestation/Version Chapters.

Sections, when functioning as a collection, in turn would have two categories of sub sections. 1. Sub-sections (not shown) and 2. Manifestation/Version Sections.

This then is a slightly different use of roles to what Bridget introduced, because a second use of role might be necessary to distinguish a particular member within its member sub-class.

So we might want the default manifestation / version of chapter 1.

The default manifestation / version of chapter 1 might then be classified as follows.

• Member
  • Manifestation (type="member" role="manifestation")
    • Default (type="member" role="manifestation default")