Addition of "accessType" and "accessKey" properties

[stuartasutton]

One of the takeaways from the ongoing licening conversation (issue #5), was the addition of two properties to: (1) provide a quick means for a user to determine the category of licensed access provided; and (2) provide a property for inclusin of an accessKey. Discussion on this github issue is intended to include the general approach to accommodating the use cases. Property names are placeholders to be later/better crafted.

In the discussion, there were two viable alternatives to handling these two use cases:

Alternative 1:

1. An additional to CreativeWork (no more specific type exists for Learning Resource) of a property for type of license with enumerated list of options; and
2. License as a more specific type of CreativeWork that includes the accessKey property.

Alternative 2:

License as a more specific type of CreativeWork that includes both the accessType property (with enumeration) and the accessKey.

As usual, pros and cons for each with the first having perhaps the greatest challenges since it would require an additional property to the core CreativeWork but would allow for signaling the accessType even in the absence of a license (which could also be accomplished with Alternative 2 but is less obvious). The second has the advantage of being less a challenge in schema.org adoption since it does not extend the core CreativeWork but pushes both properties into License as a more specific type of CreativeWork.

Illustrated:

[science]

I thought option 1 was:

• Use license as-is
• Add accessType (or re-use license in this way), as an attribute of CreativeWork
• Add accessKey as an attribute of CreativeWork

In your option 1, you seem to be creating a License subclass of CreativeWork. I thought the point of this path was to avoid adding new object classes, and just adding attributes to CreativeWork?

Option 2 looks right. An important implication of option 2 is that you'll get a common structure that looks like (in simplified json):

license: {
  url: [[url]],
  accessKey: [[enuramble]],
  accessType: [[enumerable]]
}

Note: I edited the license json structure to reflect @philbarker's input on another thread.

[bredd]

I agree with Steve's (science) enhancements of Stuart's summary.

Adding to the summary, there are three pieces of information we need to convey. We discussed this on the call but I'm adding some personal embellishment.

1. What is the license under which this content is made available? This is the purpose of the existing "license" property. It could be an open license such as a Creative Commons or Open Source license. Or, it could be a more restrictive or custom license. Regardless, the presence, absence or type of license should not be taken as an indicator of whether the resource is access controlled.
2. Is this content access-controlled? That is, does it require some kind of authorization protocol before access can be gained? This is the purpose of the "accessType" property in Stuart's and Steve's examples.
3. How do applications determine how to gain access?. This corresponds to the "accessKey" property in the examples. The access key is opaque as far as the LRMI and Schema are concerned. An application that recognizes the key should be able to determine how to negotiate access. An application that does not recognize the key should assume that it does not have access.

These three pieces of information don't necessarily have to correspond to three properties in the schema. For example, presence of the access key (#3) could be an indicator that the content is access-controlled (#2).

Here are some lingering questions:

• Should these additional properties be directly on creativeWork or should they be attributes of a composite license object? (This is the issue Steve and Stuart are discussing)
• To what degree should access control information be composited into fewer properties?
• Inevitably, publishers will offer the same content under multiple "access plans". They will want to convey this through multiple access keys. Should "accessKey" be multivalued? If it is not multivalued then the publisher would presumably put a value in "accessKey" that references a list of actual access keys. Such a structure would be a publisher's implementation detail and something LRMI shouldn't have to express.

[science]

@bredd, @philbarker suggests that accessKey and accessType should be http://schema.org/Enumeration. Probably mainly enumerations of urls.

I have heard from some OER metadata consumers that they very strongly want accessType included. They don't care so much about accessKey, which we've been working on. But providing accessType for them lets them distinguish things that are closed source but free to use on the web from "register-ware" or "limited-time-only ware" and other practices that they see as deceptive to end users.

[stuartasutton]

On Fri, Oct 30, 2015 at 2:01 PM, Brandt Redd notifications@github.com wrote:

I agree with Steve's (science) enhancements of Stuart's summary.

Adding to the summary, there are three pieces of information we need to convey. We discussed this on the call but I'm adding some personal embellishment.

1.

What is the license under which this content is made available? This is the purpose of the existing "license" property. It could be an open license such as a Creative Commons or Open Source license. Or, it could be a more restrictive or custom license. Regardless, the presence, absence or type of license should not be taken as an indicator of whether the resource is access controlled. 2.

Is this content access-controlled? That is, does it require some kind of authorization protocol before access can be gained? This is the purpose of the "accessType" property in Stuart's and Steve's examples. 3.

How do applications determine how to gain access?. This corresponds to the "accessKey" property in the examples. The access key is opaque as far as the LRMI and Schema are concerned. An application that recognizes the key should be able to determine how to negotiate access. An application that does not recognize the key should assume that it does not have access.

These three pieces of information don't necessarily have to correspond to three properties in the schema. For example, presence of the access key (

3 https://github.com/dcmi/LRMI-Terms/issues/3) could be an indicator

that the content is access-controlled (#2 https://github.com/dcmi/LRMI-Terms/issues/2).

Brandt, this assumes some logical process on the part of the consuming application or user. The open metadata must be useful independent of any downstream system logic -- no relying on things like "if 'A' is present, THEN assume "B". That means all three properties would need to be present in some configuration--license, accesType, accessKey.

Here are some lingering questions:

• Should these additional properties be directly on creativeWork or should they be attributes of a composite license object? (This is the issue Steve and Stuart are discussing)

Yes, that question is the thrust of the two models.

• To what degree should access control information be composited into fewer properties?

I think my answer is entailed in the "don't assume any system logic" comment above.

• Inevitably, publishers will offer the same content under multiple "access plans". They will want to convey this through multiple access keys. Should "accessKey" be multivalued? If it is not multivalued then the publisher would presumably put a value in "accessKey" that references a list of actual access keys. Such a structure would be a publisher's implementation detail and something LRMI shouldn't have to express.

Like all of the existing LRMI properties, there are no constraints in the schema declaration of the properties (i.e., mandatory, repeatable etc.). So, I'd say accessKey is repeatable (as is license). While logic might dictate that an accessType be singular, no constraint should be placed on it either. Constraints on properties and classes beyond domain / range (or domainIncludes / rangeIncludes) seems to me to be a function of application profiles defining particular record structures and best not done in the defining vocabulary schema.

— Reply to this email directly or view it on GitHub https://github.com/dcmi/LRMI-Terms/issues/10#issuecomment-152650251.

[stuartasutton]

On Fri, Oct 30, 2015 at 9:52 AM, Steve Midgley notifications@github.com wrote:

I thought option 1 was:

• Use license as-is
• Add accessType (or re-use license in this way), as an attribute of CreativeWork
• Add accessKey as an attribute of CreativeWork

In your option 1, you seem to be creating a License subclass of CreativeWork.

Sorry, Steve, if the 'grammar' of the figure seems to indicate that result. Both figures are RDF-ish and the two entities (Learning Resource & License) are independent with the predicate License having a domainIncludes of Learning Resource and a rangeIncludes of License.

I thought the point of this path was to avoid adding new object classes, and just adding attributes to CreativeWork?

Thus the posting of my message was to double check whether we all walked away with the same impression of the result of the discussion.

Option 2 looks right. An important implication of option 2 is that you'll get a common structure that looks like (in simplified json):

license: { license: [[url]], accessKey: [[url]], accessType: [[url]] }

— Reply to this email directly or view it on GitHub https://github.com/dcmi/LRMI-Terms/issues/10#issuecomment-152584863.

[philbarker]

Closing. usageInfo may meet the requirement for "accessType". If not and if this is still felt to be an issue, we can re-open