Disposition of useRightsUrl

[stuartasutton]

The useRightsUrl property was brought over to DCMI in the transition as part of the LRMI-approved version 1.1. [1] As we know, the useRightsUrl was not adopted by schema.org given the schema.org/license property (https://schema.org/license). As part of the RDF encoding of 1.1, the useRightsUrl property was included [2] and declared as a subproperty of the schema.org/license property.

At the time of adoption by schema.org/license property, there was an ongoing conversation on the LRMI GG of refining the lrmi:useRightsUrl with subproperties that would better meet the needs of certain use cases (get GG message permalinks). I know that Steve and Brandt were keen on refinement. That refinement conversation stalled in light of the schema.org/license adoption and the shift of LRMI focus to the transition of the specification's stewardship.

So, the question: Where do we stand on the lrmi:useRightsUrl status and refinements discussion?

[1] http://dublincore.org/dcx/lrmi-terms/1.1/
[2] http://dublincore.org/dcx/lrmi-terms/#useRightsUrl

[science]

Background

My input (this is Steve Midgley) on this one is to have two fields related to use Rights. One field is for describing the actual license attached to the resource. This should be "useRightsUrl" I think. The other is for a field which describes how you can access a resource via its license. For example, useRightsUrl isn't very useful in accomplishing that if it links to an "All Rights Reserved" page. One criticism raised in the past to me by a few publishers is that useRightsUrl has an inherent bias towards open licensed resources. Closed licensed resources can't communicate how users can access and use their resources using useRightsUrl because there are complicated restrictions that can't be codified in a universal license.

Use-case / Issue

This proposed alternative field (call it xyzUrl in this post), designed to address this issue, would indicate for example what class of users might have access to the resource. Or in which collection the resource belongs. In Brandt's use-case, the need is as follows: SBAC publishes a set of resources that are accessible to any teacher in any of the states who are members of SBAC. Each state (for example) is given an LTI key they can use to auth/n/z their users into the SBAC repository. SBAC also publish a set of resources which are freely accessible to anyone under CC-By-3. The question is how do we signal in the metadata that a state LOR should use a given LTI key to log a user into the SBAC repository, or even show the user that content (with the knowledge that the user could log in if they click on the resource)? The counter-purpose is to avoid having LORs show content to users that the users can't access because (in this example) they teach in a state which is not an SBAC member.

Proposed solution

The proposal to address this is to have a second field, xyzURL, that allows SBAC to attach access rights descriptions to resources. In this example it might be xyzURL: http://sbac.org/access/2015/member

Then when they distribute their LTI keys to the LORs (state, non profit and commercial entities) they can tell the LOR operators "only show resources with the xyzURL field matching http://sbac.org/access/2015/member to users in the following states, and only use this LTI key we're giving you for those authorized users."

Other user-cases

This is just one use-case but hopefully it demonstrates why we want a second field in addition to the license field. Other use-cases include for-profit publishers who wish to distribute metadata publicly but want to only have paying customers display those resources to their users (and they want to add new customers easily). The license field in this example would just be a link to the SBAC copyright page or something similar.

Naming of the field

There have been various proposals on the name of this field (xyzUrl). As I recall they include:

• accessRestrictionsUrl
• accessRightsUrl

Personally, I don't care what the field is called so long as it is meaningful. I mildly prefer accessRightsUrl because it is shorter to type.

Re-use of a single field?

I think one question to surmount is whether the useRightsUrl field could be appropriated for this purpose (and so avoiding the need for a second field). IIRC, Phil Barker argued (on LRMI list) strongly and with evidence that this was a bad idea, and I'm inclined to agree with him.

[stuartasutton]

Just a brief note on "Re-use of a single field"--technically, we cannot "appropriate" (reuse) an exiting property where that means changing its meaning/semantics. It violates the core tenet of "persistence" on which trust and reliability rest (and violates the DCMI namespace policy):

"If ... such changes of meaning are likely to have substantial impact on either machine processing of DCMI terms or the functional semantics of the terms, then these changes will be reflected in a change of URI for the DCMI term or terms in question."

In other words, a URI that names a property or class can never be "reused" or "appropriated" through change of meaning because it places relying systems at risk of breaking. Substantive changes result in a NEW property or class. Properties/classes can be deprecated (no longer present for preferred use), but they are never deleted or semantics changed in harmful ways...never make legacy systems break.

In the LRMI RDF schema at http://dublincore.org/dcx/lrmi-terms/#useRightsUrl , we have declared lrmi:useRightsUrl as a subproperty of schema:license. If we were to create a property for defining access restructions (lrmi:accessRestrictionsUrl or lrmi:accessRightsUrl), it might also be declared a subclass of schema:license.

My only question is whether making this distinction between "use" and "access" means that existing systems that have used lrmi:useRightsUrl for BOTH purposes would then be "wrong" (or half wrong) because we have narrowed the meaning (and application) of the property? What is the risk and what are the consequences?

[science]

I don't think there is much risk of breaking existing applications which are overloading useRightsUrl - I'm not aware of anyone abusing/extending that field right now. It's that a few of us want to communicate this information and currently don't have a method.

One possible approach would be to give us a name and a provisional space and let us use it. If it turns up widely used (say in the Learning Registry at least), then it would be worth bringing all the way into the standard..

[stuartasutton]

Well, it seems to me like there are two options given a perceived need to do something:

1. Deprecate useRightsUrl and create two new properties reflecting the identified needs; or
2. Add a new property that satisfies the unfulfilled need and continue using the useRightUrl property as-is but with an implied narrowing of use.

[stuartasutton]

And another option would be to utilize the ontologically "soft" schema.org/supersededBy (https://schema.org/supersededBy) with the lrmi:useRightsUrl property instead of deprecation. Thus:

lrmi:useRightsUrl schema:supersededBy schema:license

Then, we will have: (1) preserved lrmi:useRightsUrl so we don't break any systems; (2) pointed lrmi:useRightsUrl to schema:license as the general licensing property by gently noting in documentation and in the LRMI schema that useRightsUrl has been superseded; and then (3) create two new LRMI subproperties to cover the more granular aspects identified by the use cases (i.e., the suggested lrmi:accessRestrictionsUrl & lrmi:accessRightsUrl). Sound reasonable?

I've suggested a new work package for next steps in the LRMI schema development (http://wiki.dublincore.org/index.php/AB-Comm/ed/LRMI/TG#wp4) where we might move a solution forward quickly.

[stuartasutton]

Previous message not that clear...sorry. In sum:
(1) lrmi:useRightsURL superseded by the schema:license; then
(2) two new LRMI subproperties of schema:license that cover both use case needs.

[science]

Great looking. This introduces a little confusion for me: I thought that
accessRightsUrl == useRightsUrl == license. I wasn't aware there was a use
case for any of those fields that wasn't satisfied by any other field? The
idea, in my mind was as follows:

• For open content:
  • Put the URL to your open license in "license"
• For closed content
  • Put a standard URL or some standard text like "US Copyright" in the
    license field (whatever the community is doing for that)
  • Put a URL for how your content can be accessed (like a URL to the
    collection of content, or a URL to the LTI description) in
    accessRestrictionsUrl

Those are the only use-cases I'm aware of - which suggests that
"accessRightsUrl" is not necessary, and in my opinion just complicates
understand what the differences between 3 rights fields are. Having just
license and accessRestrictionsUrl would do everything I'm advocating for, I
think, and be more self-documenting.. What is the use-case for
accessRightsUrl? Other thoughts?

On Thu, Apr 9, 2015 at 6:46 AM, Stuart Sutton notifications@github.com
wrote:

Previous message not that clear...sorry. In sum:
(1) lrmi:useRightsURL superseded by the schema:license; then
(2) two new LRMI subproperties of schema:license that cover both use case
needs.

—
Reply to this email directly or view it on GitHub
#5 (comment)
.

[science]

Per our conversation, I'm proposing a new solution.

license: url

• Describes the open or closed license associated with the resource, per Schema's definition

collection: CreativeWork (and primarily url)

• Associates this resource with a larger collection. The URL points you to the collection itself. The collection may or may not be publicly accessible - this can be determined if the license field of collection is provided. Or if license is not provided, it might be inferred from the license of the resource itself.

One use-case for collection is to permit organizations to communicate the existence of a closed collection of resources. Consumer/search organizations who have access keys (such as LTI) to the collection, can determine which of their users are entitled to the keys, and display the collection in search only for users who are capable of viewing the content.

[stuartasutton]

Steve, this is timely. There has been conversation and work on a class (type) for Collection in the Bib extend community [1] & [2] with submission to schema.org with a "target date for consideration" of last Friday (April 24th).

So my immediate take away from our skype conversation and your post here, Steve, is that the use case matters driving this conversation are largely around non-public licenses enabling access to 'collections' of learning resources--e.g., through mechanisms such as LTI, licensing keys etc. that, for example, a school district or some other entity might deploy. So, the license of concern hangs off a collection of LRs:

LR===collection===>COL (LR belongs to a 'collection')
COL===license===> "some license" [text/URI](COL has a non-public license)

Am I on target, Steve, with the use case? Others folks? Brandt?

If so, this doesn't appear to me to be an immediate matter of LRMI coining some new license property if what the library community is proposing for schema.org with a Collection entity and the existing schema.or/license suffices.

[1] http://www.w3.org/community/schemabibex/wiki/Bib.schema.org-1.0
[2] http://sdo-bib.appspot.com/Collection?ext=bib

[stuartasutton]

AND, if this is correct, the matter for us becomes 'best practice" documentation on how a learning resource description can be tied to a collection to which the resource belongs.

[science]

Well very interesting! I was worried that schema.org would have a long process for adopting our suggestion of a collection as a CreativeWork array (or similar) but it looks like they have already done it!

In which case, yes, our approach should be to include Collections in LRMI somewhere as "guidance" or best practice for how to deal with things.

As far as I'm concerned, my use case can be solved with Schema "licence" and "collections" - and not additional fields. So deprecate useRightsUrl or whatever you choose. My approach will be to steer the community I'm working with to use collections to solve the problem we have.

And your depiction of how an LO connects to a collection and the collection connects to an access key like LTI is exactly right. (And how a collection can have a license itself, which can be used to signal whether the collection requires LTI or whatever or is itself open).

I know that IMS, for example, is providing GPL licensed material to its members, but through a closed portal. So the resources are open, but the collection is closed! Even that use case can be handled by this proposed approach we're discussing.

I'd say "lock it in" and move onto other problems. Let me know what I can do to help document this (or what documentation/best practices you want in LRMI itself).

[science]

Looping in @bredd to the discussion so he can take a look at the state of the state.. Thoughts @bredd?

[stuartasutton]

Steve, I think schema.org/Collection is not yet in schema.org but is inevitable. I _think_ the current status is that the Bib community has proposed it. I also notice that there is a revision in a name-change pull request from @vholland to rename the schema.org/collection property to targetCollection with type of ItemList, Thing. It still has a domainIncludes of schema.org/UpdateAction, but that should not preclude use with CreativeWorks.

[bredd]

Thanks to Steve (science) for drawing my attention to this thread.

I'll tackle the easy parts first:

• Steve has done an excellent job of outlining the Smarter Balanced use case. I don't need to elaborate more on this one other than to emphasize that I expect this to be a common need, especially if we are to enlist commercial publishers.
• I think that the Schema.org license property captures the meaning and purpose of the LRMI useRightsURL. Therefore I endorse Stuart's suggestion to indicate that lrmi:useRightsURL has been supersededBy schema:license.

Thus, open licenses (like CC-BY) would be indicated using schema:license . Restrictive licenses could also be indicated this way but they would need to be augmented with information on how to gain access.

Now for the harder part, indicating how to gain access: If I understand the thread correctly there are two propositions on the table.

Proposition 1

First is what has been variously called xyzURL, accessRestrictionsURL, useRestrictionsURL, etc. The value of this field is a lookup key that the subscribing application uses to determine whether the user has access to the resource (presumably by way of an encryption key). This is the method I've been advocating. Only, I don't like any of the proposed names since none of them adequately convey the idea of using the value to look up an access mechanism in behalf of the user.

Let's start with a clear definition of the field. Here's a draft: "The identifier of an access-controlled collection that may be licensed to a user or organization. Applications can use this identifier to look up the mechanism (including protocol and keys) needed to gain access to the content."

That leads me to nominate accessManagedCollectionURL, accessManagementURL, or some variation on this theme.

Proposition 2

This is not too dissimilar to Proposition #1 once you traverse the abstractions. Essentially you use the emerging collection attribute to indicate that the item belongs to a collection. Then, certain yet-to-be-determined properties on the collection indicate how to gain access to the collection.

The challenge with #2 as compared to #1 is maintaining a way for basic applications to determine which items have access restrictions. In Proposition #1, the mere presence of xyzURL is sufficient to detect that the item is access-controlled. In proposition #2, the collection attribute has multiple purposes. So, an application either has to know something about the nature of the collection or it has to parse the license field sufficiently to know the difference between an open and a restricted license.

Is this all making sense?