Licenses

[Phil Barker]

Hello all,
version 1.6 of schema.org has been released, and in it creative works <http://schema.org/CreativeWork> have a property :

license    (URL  or CreativeWork)     A license document that applies to this content, typically indicated by URL. <http://schema.org/license>

You'll remember that proposed a property useRightsUrl "The URL where the owner specifies permissions for using the resource"... well the new license property will do what we wanted useRightsUrl to do (with some advantages, it fits better in the to schema.org model and the name matches existing RDFa/HTML5 approaches of using <link rel="license"...>

Let's count this as good news.

Phil

-- 
--  
Phil Barker           @philbarker
LRMI, Cetis, ICBL     http://people.pjjk.net/phil
Heriot-Watt University

Ubuntu: http://xkcd.com/456/
  not so much an operating system as a learning opportunity.

[Paul Libbrecht]

version 1.6 of schema.org has been released, and in it creative works <http://schema.org/CreativeWork> have a property :

license    (URL  or CreativeWork)     A license document that applies to this content, typically indicated by URL. <http://schema.org/license>

You'll remember that proposed a property useRightsUrl "The URL where the owner specifies permissions for using the resource"... well the new license property will do what we wanted useRightsUrl to do (with some advantages, it fits better in the to schema.org model and the name matches existing RDFa/HTML5 approaches of using <link rel="license"...>

Let's count this as good news.

To me it looks to it indeed like good news.

And now, where is the axiom that says that such property-statements are equivalent?

paul

[Joshua Marks]

Cool, that will do I think.

-Joshua

Fat fingered from my iPhone

--
You received this message because you are subscribed to the Google Groups "Learning Resource Metadata Initiative" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lrmi+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lisa McLaughlin]

Thanks for sharing Phil, this seems like a more sustainable solution. 

[Steve Midgley]

Hi,

This seems like good news, and I think eliminates my (and a few other orgs') need to request to LRMI for an accessRestrictionsURL field from LRMI?

A group of us are going to meet by phone tomorrow to discuss whether license field works for that purpose (seems promising). Anyone from this list who wants to join is welcome - it's our weekly learning registry community call. It takes place at 1pm pacific / 4pm eastern every Wednesday (though we do sometimes cancel so subscribe to learningreg-dev list on google groups to get updates - we are meeting tomorrow).

https://www.speek.com/LearningRegistry
571-297-3003  Pin 86571878

Steve

[Phil Barker]

Hi Steve, I would join the call to discuss this, but I will be travelling through rural areas at the time, out of reach of reliable cell phone signal. I think a license can express rights, permissions, conditions and restrictions. The URL can point to a machine and/or human readable document; the embedded creative work can encode a Url, name and an inline (human readable) description. So yes, probably that covers what you want in that it pushes the issue of describing access restrictions out of schema and into to the license document.

Phil


Sent from my ASUS Pad

[Brandt Redd]

I will try to join tomorrow’s call. Before then, however, I want to raise a concern. In our previous discussions we had distinct meanings and purposes for the existing useRightsUrl and the proposed accessRestrictionsUrl. The LRMI “license” property seems more like useRightsUrl. I’m not sure it can take on both roles (though I would be really happy to be convinced otherwise).

 

Thanks,

Brandt

[Phil Barker]

My take on that is that the information about both useRights and useRestrictions can both go into the license. Sure, that's just shunting the problem one step further away, but ccREL (as one example) has properties of cc:permits, cc:prohibits, cc:requires (see http://wiki.creativecommons.org/images/d/d6/Ccrel-1.0.pdf section 3.2 ) where cc:requires is for the actions required by a user in order to enjoy the permissions described in cc:permits.

Phil


Sent from my ASUS Pad

[Brandt Redd]

The advantage of two properties is that a consuming application can determine default behavior without interpreting metadata at the other end of the URL. Presence of useRights means that default behavior is to list the item. Presence of useRestrictions means that default behavior is to filter the item.

 

-Brandt

[Steve Midgley]

Maybe I misunderstood - is LRMI going to remove useRightsURL from it's vocabulary? I thought we could keep using that and then also use license for other purposes? Does license in schema deprecate useRightsURL? 

If so, then I'd agree with Brandt that having a second field would be very beneficial, so I'd continue to advocate for some kind of new field in schema to be added, after useRightsURL is deprecated in favor of license (assuming that's what's happening).

We spent a fair bit of time in the LR community discussing whether we need one field or two, and it was pretty compelling technically that two fields makes life a *lot* easier for the consumers of metadata. One field indicates that something is licensed and you should dereference the URL to figure what the license terms/restrictions are (aka useRightsURL or license). But generally speaking a user will be able to view/interact with the resource if they follow the resource URL; barring the following:

The other field indicates that access to the resource is restricted. You will not, by default, be able to access a resource just by following its resource URL. The accessRestrictionsURL (or whatever) gives you metadata about who can access and how they can access a resource. Which is pretty different information from a license field..

All input welcome..

Thanks,

Steve

[sasu...@dublincore.net]

Steve, my apologies for this very, very late response. In my opinion, LRMI can never just remove the useRightsUrl from the specification. Never!  LRMI 1.1 is what it is. Subsequent formal action based on community discussion might be taken, but such actions would be in response to community expressed needs for the specification to evolve. One aspect of any principled evolution of a specification is an serious examination of how change impacts existing applications that depend on the then existing specification. Unvarnished removal of classes/properties from of a spec risks breaking systems. My assumption is that 1.1 is, and will remain, as is. Any subsequent developments of the specification build on this fact. 

Stuart

[Steve Midgley]

Thanks. Would your advice be to continue to pursue a separate accessRestrictionsURL per my previous email, or try to overload useRightsURL, since with the addition of license in schema.org, the useRightsURL isn't going to be terribly widely deployed in the future? 

Thanks for any advice!

Steve

[Stuart Sutton]

Steve, we are both gazing into the same crystal ball. I absolutely agree that given the imprimatur of schema.org, its license property will be more understood and used than any non-schema.org-adopted LRMI property. I personally have very serious doubts that schema.org is interested in adopting properties for richer, more refined descriptions than currently enabled in LRMI 1.1. But I could well be wrong in that "crystal ball" assessment.

If my observation is correct, then I have have a separate set of questions for you, Steve (actually the community). Is there a demonstrable need and interest on the part of the LRMI community (however mysteriously defined) in reaching for deeper description as a means of augmenting schema.org markup knowing that the non-schema.org aspects of that markup would be less "known" or even "unknown" except for those applications "in the know"?   Given that LRMI 1.1 is a fait accompli, is there an unfilled need within the community for richer description for markup even if new properties/classes haven't a ghost of a chance of adoption by schema.org?

If there is, what are the use cases? What are the needs and are they actually unfilled? Do those needs shift the focus of LRMI's efforts away from a terse vocabulary of terms for the purpose of markup that the "webmaster can understand" in support of enhanced discovery by search engines toward definition of a metadata record for rich description?

Stuart

[Steve Midgley]

I am interested in deeper descriptions and hopefully using LRMI as a vehicle, and I think a number of others are also. There are already profiles of LRMI that are out there -- some states in the US are defining narrowed vocabularies and best practices on how use schema/lrmi to tag US K12 learning content. Some of that work would certainly be useful and generalizable. 

I do worry about reinventing old wheels - there's so much that has been accomplished in Dublin Core and LOM (for example), so I personally want to be sure we don't just cycle the same solutions again, but use the work that's been done. 

I am really excited about the microdata and json representations of LRMI as an easy way to share this metadata and I don't want to lose that in any future work -- this approach feels very "internet & web compatible" to me - I'm trying to hang onto that stuff as a design principle..

But we've lost a ton of precision by going this route (and stepped way back from some capabilities of other metadata formats), and I'm sure it's going to hard work to fix that. Just some examples:

• How to corral the diversity of curriculum standards into an alignment object?
• How to support licensed content in a way that permits non-centralized/diverse search tools?
• How to handle subject taxonomies?
• How to describe resource quality?
• Do we even want to describe paradata/usage data in this framework?

I'm sure there are more, but that's what's on my mind at the moment.. I personally don't care so much if we get any of these solutions adopted by schema.org. Generally speaking I think where we build solutions that work, are widely used and "web compatible" we'll see them adopted by schema later, but that's not the goal for me.

Steve

[Renato]

Some previous metadata standards (LOM for example) are obviously richer than schema.org. One reason is that schema.org is more limited in scope.

I agree with the limitations Steve identified, especially the first one (alignment to many different educational frameworks).

But I would like to ask, having limited experience with previous standards: could those standards properly address these problems (excluding the missing paradata)?

As an example, educationalAlignment maps (approx) to conformsTo in DC, nothing in LOM...

Thanks,
Renato

[Steve Midgley]

I think LOM and Dublin Core offer pretty concrete roadmaps for how to handle things in future iterations of LRMI. I think the key is making those definitions work in the wild/woolly schema/lrmi approach. We are regularly binding schema.org/LRMI to several different formats such as JSON-LD, HTML-embedded microdata and RDFa (both HTML-embedded and expressed in json and xml). 

I think any solution needs to be not just compatible, but hopefully friendly/readable to those different approaches. We've seen some schemas that can be expressed in JSON-LD (generally coming from XML) but it's super ugly and unreadable (which biases me against them anyway).

On the semantic level, we still have a lot of work to do, as there are tons of different kinds of standards alignments (not to mention workforce pathways, skill certification levels etc) out there. The only two publicly released/licensed definitions for standards are ASN and GIM. I think way more people are using ASN over GIM (if anyone is using GIM?). (I'm not talking about standard IDs, but just the way that standards get defined so they can be referred to within LRMI alignmentObjects).

At the very least we need more examples of how to express standards, represent them in alignmentObjects and structure them into sequences..

Steve

[Renato]

Thank you Steve for your appreciated input.

On the semantic level, we still have a lot of work to do, as there are tons of different kinds of standards alignments (not to mention workforce pathways, skill certification levels etc) out there.

I agree. I am interested in further analyzing this aspect, but I am posting under the thread “Explaining the LRMI Alignment Object”, as it looks more appropriate.

Renato

 

[sasu...@dublincore.net]

Steve, sorry so many days have passed since your response to my question. I've interspersed a few follow-up responses below and then try to summarize with a graphic that may or may not help the two of us getter a better handle on where you see LRMI going now that v1.1 is complete and (nearly all) adopted as part of schema.org.  More below ...

On Thursday, August 21, 2014 12:19:28 PM UTC-7, Steve Midgley wrote:

I am interested in deeper descriptions and hopefully using LRMI as a vehicle, and I think a number of others are also. There are already profiles of LRMI that are out there -- some states in the US are defining narrowed vocabularies and best practices on how use schema/lrmi to tag US K12 learning content. Some of that work would certainly be useful and generalizable.

Yes, I noted Elizabeth Neuman's post to this list at [1] regarding Wisconsin's profile and definition of value vocabulary constraints. My assumption is that there have been more such profiles posted to the Learning Registry list.  Soliciting as many examples of such profiling as is possible would be useful in many ways including the provision of a means of exploring potential extensions to properties/classes of general community value as well as value constraints from which candidate concepts for more general vocabularies might be derived. I.e., they are very useful.

[1] https://groups.google.com/d/msg/lrmi/HRPY9QUchpc/l1XKAfmMN6oJ

 

I do worry about reinventing old wheels - there's so much that has been accomplished in Dublin Core and LOM (for example), so I personally want to be sure we don't just cycle the same solutions again, but use the work that's been done. 

I strongly agree. Reusing and not reinventing are core tenets of metadata interoperability and harmonization in the open. So, there are very, very good reasons to reuse and not reinvent and then declaring that reuse at the schema level through formal constructs now available such as owl:sameClassAs and owl:samePropertyAs as well as useful declaration of new properties and classes as subproperties and subclasses of existing properties and classes. Such good practices provide web "glue" and help developers (and applications) interoperate. It is my understanding that schema.org is intending to incorporate such relationship declarations directly in the schema.org schema because it is extremely useful to do so. 

 

I am really excited about the microdata and json representations of LRMI as an easy way to share this metadata and I don't want to lose that in any future work -- this approach feels very "internet & web compatible" to me - I'm trying to hang onto that stuff as a design principle..

Yes.  But, I do have a question. Do you mean microdata and json representations of LRMI instance data (resource descriptions)? As far as I am aware, there are no canonical representations of the LRMI properties and classes canonically serialized in any format--http://lrmi.net/the-specification is all there is (i.e., a pretty web page). 

But we've lost a ton of precision by going this route (and stepped way back from some capabilities of other metadata formats), and I'm sure it's going to hard work to fix that.

And, this is the crux of the question I asked of you, Steve, whether fixing that lost "ton of precision" through developing LRMI properties, classes, value spaces to achieve richer description is or is not within what the LRMI community deems its scope. You have been clear, Steve, in your response that you say "yes" it should be within  (a revised) explicit scoping. I do wish others had responded to your post in regards to this key question. My sense is that some education community consensus on such future development is a prerequisite to doing anything past LRMI 1.1. If there aren't sufficient people who: (1) want it, (2) who are willing to contribute to the work of getting it done, and, (3) then using it (adopting) and promoting its use, then it is a waste of time and effort to push forward at the community level. 

 

Just some examples:

• How to corral the diversity of curriculum standards into an alignment object?
• How to support licensed content in a way that permits non-centralized/diverse search tools?
• How to handle subject taxonomies?
• How to describe resource quality?
• Do we even want to describe paradata/usage data in this framework?

I'm sure there are more, but that's what's on my mind at the moment.. I personally don't care so much if we get any of these solutions adopted by schema.org. Generally speaking I think where we build solutions that work, are widely used and "web compatible" we'll see them adopted by schema later, but that's not the goal for me.

Steve, my (embellished) take away from our exchanges look something like the following graphic where I have tried to attach some labels to aspects:

Thoughts?

Stuart 

[Brandt Redd]

Hi Stuart:

 

I took part of your response as a repeated call for others in the community to answer your question:

 

“… whether fixing that lost "ton of precision" through developing LRMI properties, classes, value spaces to achieve richer description is or is not within what the LRMI community deems its scope.”

 

I answer, “Yes.”

 

Thanks for keeping the dialog going.

-Brandt

[Jim Goodell]

I'd agree with Brandt on the technical level about more precision, but recognize that some audiences may not want a LRMI with "more technical precision" if that were to add complexity. For example, the common state tagging initiative has focussed on a limited number of tags for sharing resources. I think we can have it both ways as long as the path forward takes into account the full range of stakeholders.

Jim

[Steve Midgley]

Others have more experience with implications of decisions like these, but in my opinion as long as simple things remain simple to express, adding complexity/richness for sophisticated metadata publishers is OK.

Steve

On Tue, Nov 4, 2014 at 4:37 PM, Jim Goodell <james.dona...@gmail.com> wrote:

I'd agree with Brandt on the technical level about more precision, but recognize that some audiences may not want a LRMI with "more technical precision" if that were to add complexity. For example, the common state tagging initiative has focussed on a limited number of tags for sharing resources. I think we can have it both ways as long as the path forward takes into account the full range of stakeholders.

Jim