When the Learning Resource Metadata Initiative (LRMI) technical working group started its work it focused on identifying the properties and relationships that were important for educational resources but could not be adequately expressed using schema.org as it then stood. One of those important pieces of information was the licence under which a resource was released, and so the LRMI spec from the start had the property useRightsUrl “The URL where the owner specifies permissions for using the resource.” When schema.org adopted most of the LRMI properties, useRightsUrl was an exception, it was not adopted pending further consideration–not surprising really given the wide-ranging applicability of licence information beyond learning resources.
Back in June the good news came that with version 1.6 of schema.org included a license property for Creative Works that does all that LRMI wanted, and more.
What does this mean for LRMI adopters?
Some adopters of LRMI have already started using useRightsUrl. Such implementations are valid LRMI but not valid schema.org, which means that they will only be understood by applications that have been written specifically to understand LRMI and not by the general purpose web-scale search applications. This is sub-optimal.
In passing, let me mention another complication. With schema.org you have a choice of syntax: microdata and RDFa 1.1 lite. With RDFa there was already a mechanism for identifying a link to a licence, that is rel=”license”. Just to complicate a little more, RDFa allows name spacing, and the term license appears in at least three widely used namespaces: HTML5, Dublin Core Terms, and the Creative Commons Rights Expression Language–hopefully this will never matter to you. To exemplify one of these options I’ll use the HTML that you get when you use the Creative Commons License Chooser (but let’s be absolutely clear, what I am writing about applies to any type of license whether the terms be open or commercial):
<a rel="license" href="http://creativecommons.org/licenses/by/4.0/">
The good news is that all these options play nicely together, you can have the best of all worlds.
If you are already using itemprop=”useRightsUrl” to identify the link to a licence using LRMI in microdata, you can also use the license property and rel=”license”. The following LRMI microdata with a bit RDFa thrown in works:
<html> <body itemscope itemtype="http://schema.org/CreativeWork"> <a itemprop="license useRightsUrl" rel="license" href="https://creativecommons.org/licenses/by/4.0/"> Creative Commons Attribution 4.0 International (CC BY 4.0) licence </a> </body> </html>
If you are using LRMI / schema.org in RDFa, then the following is valid
<html> <body vocab="http://schema.org/" typeof="CreativeWork"> <a rel="license useRightsUrl" href="https://creativecommons.org/licenses/by/4.0/"> Creative Commons Attribution 4.0 International (CC BY 4.0) licence </a> </body> </html>
License does what LRMI asked for and more
In my opinion the schema.org license property is superior to the LRMI useRightsUrl for a few reasons. It does everything that LRMI wanted by way of identifying the URL of the licence under which the creative work is released, but also:
- It belongs to a more widely recognised namespace, especially important if you are wanting to generate RDF data
- I prefer the semantics of the name and definition: a license can include restrictions of use as well as grant rights and permissions.
- the range, i.e. the type of value that can be provided, includes Creative Works as well as Urls
That last points allows one to encode the name, url, description, date, accountable person and a whole host of other information about the licence (albeit at the cost of the not being able to do so alongside LRMI’s useRightsUrl quite so simply)
The inclusion in schema.org of the license property is good news for aims for LRMI. If you use LRMI and care about licensing you should tag the information you provide about the license with it. If you already use LRMI’s useRightsUrl or RDFa’s rel=”license” there is no need to stop doing so.