I am somewhat late in writing this, but back in May some new properties developed by LRMI were added to schema.org that simplify and expand how schema.org can be used to describe learning resources and educational events.
The new properties are:
teaches: The item being described is intended to help a person learn the competency or learning outcome defined by the referenced term.
assesses: The item being described is intended to assess the competency or learning outcome defined by the referenced term.
These are added as properties of CreativeWork and EducationEvent, and can both be used with either a DefinedTerm or text as the value (or URL, which is an allowed value for any schema.org property).
In a related change, the domain of educationalLevel, (“the level in terms of progression through an educational or training context”), which was added last year for EducationalOccupationalCredentials was expanded so that it can also be used with CreativeWork and EducationEvent. It also can have DefinedTerms, text or URL as a value.
As well as providing a way of describing the educational characteristics of EducationEvents, which was previously not possible, these changes simplify how learning resources can be described. Previously in order to describe these characteristice one had to use the educationalAlignment property and an AlignmentObject with alignmentType property of “teaches”, “assesses” or “educationalLevel”. Not only was this a somewhat complex indirect way of saying something simple, but we think that the use the AlignmentObject had the effect of hiding the availability of these important properties.
Having DefinedTerm as a value means that one can still describe the value as being drawn from an educational framework, the framework being modeled as a DefinedTermSet, just as one could when using various properties of the AlignmantObject. In fact there is the improvement that you can now provide a URL for the framework being used, not just the url of the target term and the name of the framework. Here are a couple of examples:
The educationalAlignment and AlignmentObject are still valid terms, and indeed are still the only means of describing some other educational characteristics of learning resources. However, going forward, we suggest you use the new teaches, assesses, educationalLevel properties in preference.
We will add these new terms to the DCMI LRMI namespace shortly, I hope, giving them a stable existence independent of schema.org.
If you’re interested in what may be coming next, here’s some of what has been discussed.
A property to express “the skill, knowledge or competence a learner needs before using a learning resource” is on our list of simple properties, which would complete the trio of requires, teaches, assesses. However the name “requires” has lead to confusion over what is required (a pen and paper?) and by whom/what.
Also, take a look at the schema.org gitub issue 1401 and you will see plans and discussion around creating a class for learning resources. I hope this will be limited to CreativeWorks and will sit alongside EducationEvent acting as a convenient place to find the properties relevant to describing educational characteristics, and also allowing such properties to be used when describing Videos, Books, Products, etc as learning resources (i.e. by declaring LearningResource as an additional type) without needing to add education-specific properties higher up the schema.org hierarchy.
The project is being run by Learning Tapestry in the US, I am contracted to build the metadata specification in an iterative fashion based on experiences of content exchange between the partners (currently we are at iteration 1). I want to stress that this isn’t an authoritative description of all the project’s intents and purposes, or even all the metadata requirements, it’s a use case based on them, but I hope it gives a flavour of the work. The requirements section is more relevant if you’re interested in how to specify application profiles than for the OCX spec per se.
We wish to share relatively large amounts of content and curriculum materials relating to educational courses, for example: all the activities, student learning resources, teacher and parent curriculum guides, formative assessments, etc relating to one school-year of study in a subject such as mathematics.
We wish for the metadata to facilitate the editing, adaptation and reuse of the resources. For example teachers should be able to substitute resources/activities provided with other resources addressing the same objective as they see fit. Or course designers should be able pull out all the resources of a particular type (say activity plans), about a given topic, or addressing a specific learning outcome and use them in a new course. In some cases alternate equivalent content may be provided, for example online Vs offline content or to provide accessible provision for people with disabilities.
We wish for these to be discoverable on the open web at both broad and fine levels of granularity, i.e. whole courses and the individual parts should be discoverable via search engines.
We have decided to use the following vocabularies to describe the structure and content of the material: schema.org + LRMI, OERSchema and local extensions where necessary.
Original content providers who create and publish curriculum and course materials using existing systems and already have (local) terminology for many aspects of resource description.
Content processors take the original content and offer it through their own systems. They also have (different) terminology for many aspects of resource description
Content purchasers wish to discover and buy content that meets their requirements
Course designers and Teachers use the content that has been purchased and wish to adapt it for their students
Parents wish to understand what and how their students are being taught
Learners want a seamless experience using high quality materials and ideas, in which all the work above is invisible.
The application profile must reference evolving specifications: schema.org, OERSchema, various controlled vocabularies/concept schemes/encoding schemes and local extensions. If a local extension is adopted by one of the more widely recognised specifications it should be easy to modify the application profile to reflect this.
The application profile must include a content model that meets the following requirements for describing the structure of content:
identify the distinct types of entity involved (Course, Unit, Lesson, Supporting Material, Audience, Learning Objectives, Assessments etc)
show the hierarchy of the content (i.e. the Course comprises Units, the Units comprise Lessons, the Lessons comprise Activities)
show related content that is not part of the hierarchy but is related to (e.g. information about Units for teachers and parents, content to be used in the Activities)
show the ordering of sequential content
show options for alternative equivalent content
The application profile must specify optional (may), desired (should) and required (must) descriptive metadata as appropriate for each type of entity. For example
Activities must have a learning Time
an Activity should have a name
any resource may be associated with an Audience
The application profile must specify cardinality. for example:
Courses must have one and only one title
Units must have one or more Lesson
Units may have one or more Assessment
There may be alternative ways of satisfying a requirement
Courses must associated with either one or more Lesson or one or more Unit
If there is more than one Lesson in a Unit or Course, the Lessons must be ordered
The application profile must specify the expected type or value space for any property
this may be more restrictive than the base specification
this may extent the base specification
this may include alternatives (e.g. free text or reference concept from controlled scheme)
I’ve been experimenting with ways of putting JSON-LD schema.org metadata into HTML created by MkDocs. The result is a python-markdown plugin that will (hopefully) find blocks of YAML in markdown and insert then into the HTML that is generated. You can find the plugin on github, and you can read more about the development of it in some pages generated by MkDocs (that incidentally use the plugin).
What’s it do?
Markdown is a widely used simple text format that allows formatting of text using inline markup, it’s a bit like the markup used on mediawiki/wikpedia. MkDocs is a python program that will build HTML pages out of markdown and templates. It’s geared towards the production of software/spec documentation, and we have been using it for documenting the metadata spec we’re creating for educational materials in the K12OCX project. (You’ll see the OCX part, Open Content Exchange, made it through to the plugin name.) Steve Midgley suggested that we might go further and use markdown to create the learning resources, somehow generating the metadata along with the HTML. MkDocs can be extended in a number of ways that would facilitate this, but most relevantly it uses the python markdown module, which has an API allowing for extensions.
YAML seemed like the obvious way of putting metadata into markdown. It’s another simple text format, for expressing key-value pairs, where the values can be lists or sets of other key-value pairs. It’s already used by MkDocs for specifying the site structure, and a number of extensions to python markdown already use it.
So the ocxmd extension for python markdown will look for blocks of YAML in a markdown document and replace them with blocks of JSON-LD in the HTML that is generated. It also provides the metadata as python dict in the markdown object. Feel free to try it out (cautiously) and let me know how it goes wrong / what it doesn’t do that it should / what it does that it shouldn’t …
How’s it work?
Quite simple really. I took inspiration from an existing YAML in markdown processor written by Nikita Sivakov (who’s probably a better programmer than me, so if his plug does what you want, use it, not mine). The YAML is separated before and after by a triple dash (‘—‘) on a line by itself. The plugin extends the python markdown Preprocessor so that it goes through the mark down document line-by-line looking for a triple dash. Until it finds one the text is copied into what will be returned as the ‘pure’ markdown document for further processing. When it finds a triple dash, it instead copies the lines into what will be processed as YAML (along with a few lines that will become the JSON-LD context). When it finds the closing triple dash, it processes the YAML using a python library, and then copies it into the markdown to be returned as JSON-LD between a couple of <script> tags. It also stores the python dict generated by the YAML processor as a new property in the markdown object. Then it goes back to reading line-by-line copying the text straight into what will be returned as markdown until it meets the end of file or the next triple dash.
If installed in a suitable python environment you can add it to the extensions available to MkDocs with an entry to the mkdocs.yml markdown_extensions block.
What does JSON-LD in YAML look like?
The metadata that we use for OCX is a profile of schema.org / LRMI, OERSchema and few bits that we have added because we couldn’t find them elsewhere. Here’s what (mostly) schema.org metadata looks like in YAML:
Over the past few months we have been working systematically through the 30-or-so outline use cases for describing Educational and Occupational Credentials in schema.org, suggesting how they can be met with existing schema.org terms, or failing that working on proposals for new terms to add. Here I want to summarize the progress against these use cases, inviting review of our solutions and closure of any outstanding issues.
Use cases enabled
The list below summarizes information from the community group wiki for those use cases that we have addressed, with links to the outline use case description, the wiki page showing how we met the requirements arising from that use case, and proposed new terms on a test instance of schema.org (may be slow to load). I tried to be inclusive / exhaustive in what I have called out as an issue.
As well as the unaddressed use cases above, there are some caveats about the way other use cases have been addressed. I have tried to be inclusive / exhaustive in what I have called out as an issue,–I hope many of them can be acknowledged and left for future contributions to schema.org, we just need to clarify that they have been.
Issue 1: whether EducationalOccupationalCredential is a subtype of CreativeWork or Intangible.
Issue 2: competenceRequired only addresses the simplest case of individual required competencies.
Issue 3: whether accreditation is a form of recognition.
Issue 4: the actual renewal / maintenance requirements aren’t specified.
Issue 5: there is no way represent Assessments in schema.org
Issue 6: there is no explicit guidance on how to show required learning materials for a Course in schema.org.
There is an issues page on the wiki for tracking progress in disposing of these issues.
Summary of proposed changes to schema.org
Many of the use cases were addressed using terms that already exist in schema.org. The changes we currently propose are
Since the summer I have been working with the Credential Engine, which is based at Southern Illinois University, Carbondale, on a project to facilitate the description of educational and occupational credentials in schema.org. We have just reached the milestone of setting up a W3C Community Group to carry out that work. If you would like to contribute to the work of the group (or even just lurk and follow what we do) please join it.
Educational and occupational credentials
By educational and occupational credentials I mean diplomas, academic degrees, certifications, qualifications, badges, etc., that a person can obtain by passing some test or examination of their abilities. (See also the Connecting Credentials project’s glossary of credentialing terms.) These are already alluded to in some schema.org properties that are pending, for example an Occupation or JobPosting’s qualification or a Course’s educationalCredentialAwarded. These illustrate how educational and occupational credentials are useful for linking career aspirations with discovery of educational opportunities. The other entity type to which educational and occupational credentials link is Competence, i.e. the skills, knowledge and abilities that the credential attests. We have been discussing some work on how to describe competences with schema.org in recent LRMI meetings, more on that later.
One potential issue is collision with existing work. We’ll have to make sure that we know where the work of the educational and occupational credential working group ends, i.e what work would best be left to those other initiatives, and how we can link to the products of their work. Related to that is scope creep. I don’t want to get involved in describing credentials more widely, e.g. issues of identification, authentication, authorization; hence the rather verbose formula of ‘educational and occupational credential. That formula also encapsulates another issue, a tension I sense between the educational world and the work place: does a degree certificate qualify someone to do anything, or does it just relate to knowledge? Is an exam certificate a qualification?
The planned approach
I plan to approach this work in the same way that the schema course extension community group worked. We’ll use brief outline use cases to define the scope, and from these define a set of requirements, i.e. what we need to describe in order to facilitate the discovery of educational and occupational credentials. We’ll work through these to define how to encode the information with existing schema.org terms, or if necessary, propose new terms. While doing this we’ll use a set of examples to provide evidence that the information required is actually available from existing credentialling organizations.
If you want to help with this, please join the community group. You’ll need a W3C account, and you’ll need to sign an assurance that you are not contributing any intellectual property that cannot be openly and freely licensed.
The aim here is to illustrate the extent to which the two specifications are interoperable. Also mapping a functioning specification for advertising courses to schema.org terms will give an indication what might be lacking from the latter, or to help define a subset of schema.org that could be used as an application profile for course advertising. Finally, there is a python script that might be the start of a useful tool for people who have XCRI-CAP data and want to use schema.org to describe those courses.
Before going any further I should clear up one potential point of misunderstanding. In the UK ‘course’ is often used to describe a programme of study at University or College level lasting from one to five years, leading to an award such as an Diploma, Degree, Masters etc. These ‘courses’ also called programmes, and roughly translate to what in the US can be called a Course of Study. They typically comprise several modules, also often called courses (sorry, we made up this language as we went along). XCRI-CAP is primarily used to describe these long courses/programs of study, because in the UK that is what institutions typically advertise to potential students. However, XCRI-CAP can also be used to describe short courses. My sense from the development of the schema course extension is that many people had short courses in mind (e.g. MOOCs), however it is also applicable to long courses / programs of study. So, in short, for this discussion, if it is a “sequence of events and/or creative works that aims to build the knowledge, competence or ability of learners” then I’ll call it a course, however long or short it is.
The anatomy of an XCRI-CAP XML feed in schema.org terms
<?xml version="1.0" encoding="UTF-8"?>
Author: Alan Paull, APS Ltd, firstname.lastname@example.org
Created: 25 June 2014; modified: 21 May 2015
This is a generic XCRI-CAP 1.2 example file produced to illustrate the postgraduate format adopted by Prospects, including material that would be expected to be relevant for other aggregators.
It uses the coursedataprogramme.xsd schema.
It uses revisions to the schemas to include specific refinements for postgraduate data vocabularies.
Modified by Phil Barker <http://people.pjjk.net/phil> to show just starting tags and hints to content
<!-- list of all the university's departments that can 'own' courses. -->
<dc:identifier xsi:type="courseDataProgramme:ukprn"><!-- numerical id -->
<!-- isPartOf must match exactly with a hasPart entry -->
<!-- Note XHTML markup (concise markup version) -->
<!-- 'specialFeature' is in the XCRI-CAP 1.2 Terms schema (verbose markup version) -->
<dc:identifier xsi:type="courseDataProgramme:internalID"><!--alpha-numeric id-->
<dc:subject xsi:type="courseDataProgramme:JACS3" identifier="N200"><!--name of subject-->
<dc:subject><!--name of subject-->
<!-- Course type codes specific to PG(T) -->
<dc:type xsi:type="courseDataProgramme:courseTypeGeneral" courseDataProgramme:identifier="PG"><!--label for code-->
<dc:type xsi:type="mlo:RTCourseTypeFlag" mlo:RT-identifier="T"><!--label for code-->
<mlo:start dtf="2015-09-01"><!--text equiv-->
<end dtf="2017-07-01"><!--text equiv-->
<mlo:duration interval="P2Y"><!--text equiv-->
<applyFrom dtf="2014-09"><!--text equiv-->
<applyUntil dtf="2015-09"><!--text equiv-->
<!-- Note: in the absence of attendanceMode, consumers can assume that it is Campus, so the attendanceMode can be omitted -->
<mlo:languageOfInstruction><!--iso 639-2 code-->
<languageOfAssessment><!--iso 639-2 code-->
<mlo:places><!--iso 639-2 code-->
<mlo:cost><!--free text description-->
<!-- Note: in the absence of venue, consumers can assume that it is as per the main provider element, so the venue can be omitted -->
<!-- international convention also acceptable: +44 (0) 800 666 9999 -->
Working through this from the top (root) down (up?):
In XCRI catalog is the root element for a list of courses, the Google Developer guidance for describing course lists suggest schema.org/ItemList is a good equivalent. The catalog element has an @generated attribute which is the date on which the catalog content was generated, it also has sub elements of description and contributor. I haven’t implemented this yet, but they could be translated if the schema.org course list is double typed as an ItemList and a CreativeWork. In schema.org the relationship between the course list / catalog and the Courses is provided by the itemListElement property of the ItemList. This expects a value which is a ListItem, and so we need to double type the course entities in schema.org as a ListItem and Course.
In XCRI XML the relationship between courses and the organizations that provide them is expressed by nesting the a course element nested inside a provider element. In schema.org we use the provider property that Course inherits from CreativeWork. The information about the provider, i.e. description, title, parts, location (as a postal address), identifier, url mostly have obvious counterparts in schema.org/Organization (i.e. description, name, subOrganization (not implemented), address (as PostalAddress) and url). Identifiers take a bit of thought, see below.
XCRI makes the distinction between Course as a thing which may be offered at different times and places, and Presentation as an offering or instantiation of a course. This is the same as the distinction between schema.org/Course and schema.org/CourseInstance. So the course elements in XCRI map directly to schema.org/Course entities.
The subelements of xcri:course that map clearly to schema.org properties of Course are: title (maps to name), url, abstract (maps to description), subject (maps to about, and, when an identifier from suitable framework is specified, an educational subject alignment) and mlo:prerequiste (maps to coursePrerequisites). Identifiers take a bit of thought, see below, but if the identifier was not an http URI I took a punt at it being the schema.org/courseCode (I am especially sure of this if it had the internalID attribute).
As well as abstract there were other descriptions in the XCRI feed, formatted in XHTML giving marketing information. These I passed over, but (stripped of the formatting) they could be used as descriptions, especially if the abstract is absent.
XCRI Elements that I haven’t mapped yet are, isPartOf, dc:Type, applicationProcedure, mlo:assessment, mlo:objective, regulations, mlo:qualifications, and mlo:credit. The last two of these are known gaps in schema’s ability to describe courses; there might be mappings to some LRMI properties for some of the others in some circumstances. For example if the dc:Type is PG: Postgraduate, then this could be an alignment to some educational level.
Additionally, we use the provider property of schema.org/Course to link to the provider, a relationship that is conveyed in XCRI XML by nesting, as mentioned above.
The xcri:presentation maps to schema.org/CourseInstance, which is linked to from the Course by the hasCourseInstance property.
Elements of presentation which map directly to properties of CourseInstance are: title (maps to name), mlo:start (maps to startDate) end (maps to endDate), mlo:duration (maps to duration), studyMode, attendanceMode and attendance pattern (all mapped to courseMode). The venue element maps to CourseInstance’s location property, though the provider’s identifier turns up here in a way which requires a bit of thought, see below.
A number of other elements (namely cost, applyFrom, applyUntil and applyTo) can all be mapped to properties of a schema.org/Offer. mlo:cost maps to a description of a PriceSpecification (the costs for UKHE degrees are usually more complex than can be given with a single number/currency pair), the others map to availabilityStarts, availabilityEnds, availabilityAtOrFrom. This Offer is linked to from the CourseInstance’s offers property.
There are multiple identifiers in various formats in the XCRI XML input, and various required identifiers in the schema.org graph of the course information. As discussed above, some of the dc:identifiers provided were short alphanumeric codes, and were used as, for example, the value for schema.org/courseCode, or to identify an educational subject in an Alignment Object. There is also the mlo:url element, which I used for the schema.org/url property.
What I skipped over several times is that, as well as the mlo:url, similar (or identical) http URIs were used as values for dc:identifier. Also, as well as the schema.org url property, for linked data we need an identifier for the entities we are describing (the @id tag in JSON-LD), preferably an http URI. So, I decided to experiment with using the the dc:identifiers in XCRI XML as @id identifiers for the JSON-LD. This has an advantage over just using an arbitrary random identifier in that for larger data sets there is a chance of reducing repetition in the serialization of the graph. For example with luck many courses will share the same location, and so this could appear as a properly identified entity in the graph to which many Course Instance location properties link. I have experimented with different orders or preference for what to use for the @id, (e.g. 1. dc:identifier beginning with http, 2. mlo:url, 3. dc:identifier with text value). I immediately hit a snag with this, because the same http URI was being used for different things in the XCRI example, e.g. for course and presentation, or for institution and venue, and it troubled me that the URI I was using was actually the identifier for an Institutional web page. So to disambiguate I appended #<SchemaType> to the URI, e.g. http://example.org/course1#Course, http://example.org/course1#CourseInstance.
This is probably going to take more thinking about in the future.
Most of the above mapping is implemented (or with luck, soon will be) in a python script using xml.eTree and rdflib. You’re welcome to take a look at it on github, but please bear in mind that it is pretty much untested on any input other than the example file given above. It is certainly not production level code, so don’t use it as such.
Broadly speaking, it works. With some exceptions that didn’t surprise me the XCRI-CAP data about a course can be represented as schema.org linked data.
Credit and Qualifications seem to me to be the biggest gaps, relating to existing use cases from the schema course extension community group.
Likewise there is a gap around how to represent aims and objectives in schema.org, which might be related to work on competencies.
In several places there was coded information in the XCRI (e.g. UK Provider ID, course mode codes) which isn’t easy to represent in schema.org. But this issue is being worked on.
I’ll tidy up the code a bit, and I also want to test it more extensively. I’m also pondering putting the resulting JSON-LD into a graph database to test how well it can be queried. This would be a great test of whether the schema course extension project really did meet it’s use cases.
Do drop me a line if you have any ideas, or if you have any XCRI feeds (or similar data in another format) I could play with.
I have a new publication: “Analysing and Improving Embedded Markup of Learning Resources on the Web,” which Stefan Dietze and Davide Taibi have presented at the 2017 International World Wide Web Conference in Perth Australia. I played a minor role in the “analysing” part of this work, the heavy lifting was done by my co-authors. They analysed data from the Common Crawl to identify sites that were using LRMI terms in their schema.org markup. The analysis provides answers to important questions such as: who is using LRMI metadata and which terms are they using? How many resources have been marked up with LRMI metadata? Are the numbers of users growing? What mistakes are being made in implementing LRMI?
We also see how once a term is in schema.org it is interpreted in ways that may not have been anticipated by those who created it, with any implicit assumptions held within a community of practice being ignored. Thus terms that have a specific meaning within the learning, education and training field are construed in their more generic meaning. The result of this is that some LRMI terms are used for resources that we in LRMI did not have in mind when creating them. Consequently the presence of LRMI metadata on a web resource may not be a good indicator that a resource is intended for education–this is true of some properties more than others. To avoid this when making additions to schema.org (if you see it as a problem), the domain to which a term applies should be in the term name.
A second observation that seems important to me is the strong inverse relationship between sophisticated data structures and amount of usage. Yes, I’m talking about the AlignmentObject: potentially very expressive, but either it solves a problem no one has (which I don’t think is the case) or it is so complex that few people understand it well enough to use it. In general, properties with simple text/literal values get much more use than entity-valued properties.
The official reference is: Stefan Dietze, Davide Taibi, Ran Yu, Phil Barker, and Mathieu d’Aquin. 2017. Analysing and Improving Embedded Markup of Learning Resources on the Web. In Proceedings of the 26th International Conference on World Wide Web Companion (WWW ’17 Companion). International World Wide Web Conferences Steering Committee, Republic and Canton of Geneva, Switzerland, 283-292. DOI: 10.1145/3041021.3054160
Web-scale reuse and interoperability of learning resources have been major concerns for the technology-enhanced learning community. While work in this area traditionally focused on learning resource metadata, provided through learning resource repositories, the recent emergence of structured entity markup on the Web through standards such as RDFa and Microdata and initiatives such as schema.org, has provided new forms of entity-centric knowledge, which is so far under-investigated and hardly exploited. The Learning Resource Metadata Initiative (LRMI) provides a vocabulary for annotating learning resources through schema.org terms. Although recent studies have shown markup adoption by approximately 30% of all Web pages, understanding of the scope, distribution and quality of learning resources markup is limited. We provide the first public corpus of LRMI extracted from a representative Web crawl together with an analysis of LRMI adoption on the Web, with the goal to inform data consumers as well as future vocabulary refinements through a thorough understanding of the use as well as misuse of LRMI vocabulary terms. While errors and schema misuse are frequent, we also discuss a set of simple heuristics which significantly improve the accuracy of markup, a prerequisite for reusing learning resource metadata sourced from markup.
A balloon debate is a debate in which a number of speakers attempt to win the approval of an audience. The audience is invited to imagine that the speakers are flying in a hot-air balloon which is sinking and that someone must be thrown out if everyone is not to die. Each speaker has to make the case why they should not be thrown out of the balloon to save the remainder.
Our “balloon” is a metaphorical one, it stands for the volunteer effort that maintains LRMI (LRMI seeming somewhat like a balloon in that it is kept going by hot air), and instead of carrying people it is trying to carry out work that will help people describe learning resources. While it is by no means sinking, like a real balloon LRMI can only sustain a certain (work-)load, and so we need to be selective in the work which is taken on. This exercise was intended to provide LRMI with ideas about which work to prioritize, while providing those who take part with information about the future directions that are open to LRMI.
The debate proceeded through three rounds, the first round was about choosing candidate ideas for future work, the second eliminated those which seemed least feasible, and the third was to select the highest priority ideas. On the day we didn’t really get to the third round, but the results were nonetheless interesting.
We started with the following ideas, seeded by myself with help from other members of the LRMI task group (especially Stuart Sutton who provided several of the descriptions).
1. Structured, controlled vocabularies for LRMI properties.
Several key LRMI properties take text for their expected value type. The use of free text for properties such as learningResourceType makes it difficult to compare data from different providers. Where there are suggested values mentioned in the LRMI spec for these, the LRMI Task Group is already working to provide definitions of terms in RDF (as SKOS Concepts). This suggestion is a continuation of this work, to try as far as possible to provide controlled vocabularies for relevant LRMI properties.
2. Drop the Alignment Object for the most common alignment types
The mechanism of indicating how a resource relates to an educational framework involves a level of indirection which is both arcane and potentially powerful, however it’s full power is not fully developed. The suggestion here is that the indirection be removed by creating properties for those alignment types which are clearly important. So, for example, it is often important to state the educational level of a resource (e.g. in terms of Grade Level). Currently this would be an educationalAlignment with an AlignmentObject having alignmentType of educationalLevel. The indirection of the AlignmentObject could be removed if there were a property of a learning resource called educationalLevel referencing directly a point in a grade level framework.
Figure 1a: representing an educational alignment with an alignment object.
The alignment type property of the alignment object can set to specify the nature of the relationship, e.g. that this represents the educational level of the resource.
Figure 1b: a possible way of representing an alignment such as educational level of the resource more simply. Note: the value provided could be text or a URI; representing the relationship of the node to an educational framework is not yet solved in Schema.org.
3. Develop the Alignment Object to be more expressive
The mechanism of indicating how a resource relates to an educational framework involves a level of indirection which is both arcane and potentially powerful, however it’s full power is not fully developed. The suggestion here is that properties be added to the AlignmentObject to allow additional information about the alignment between a resource and a point in an educational framework. This additional information may include factors such as: who asserts that the alignment holds, what evidence they have for this alignment, how good is the alignment.
4. Recommendations for referring to educational frameworks
From the point of view of facilitating resource discovery the relationship between a resource and an educational framework is key. Showing how a resource relates to a framework which is understood by educators and learners allows them to find resource suitable for their needs. This may be manifest in discovery interfaces as faceted search or browse categories. One problem is identifying the relevant frameworks for different types of educational alignment in different educational contexts (e.g. what is the Scottish equivalent of K-12 for educational level?). Another problem is that variation in how these frameworks are expressed in LRMI metadata makes creation of such services more difficult than it need be (what is the framework name for K-12? What URIs are best to use?). We could help by creating an inventory of frequently used educational frameworks and recommendations on how to refer to them.
5. Declare a “Learning Resource” type
Currently, a Learning Resource is not formally declared in the schema.org schema as a subtype of CreativeWork. Instead, it is inferred that a Learning Resource is a kind of CreativeWork since the LRMI properties were included as part of the CreativeWork type. The lack of an explicit LearningResource subtype to CreativeWork makes it difficult for some doing markup or implementing systems using schema.org to recognize that schema.org in fact supports description of learning resources. They see EducationEvent as a subtype of Event, but no LearningResource as a subtype of CreativeWork.
6. Define a minimal subset of schema.org for describing learning materials
The schema.org schema is quite large and can be intimidating for some wanting to define minimally viable learning resource descriptions–e.g., where to begin, what properties are most important, how should they be used. Publishing a suggested profile of schema.org that defines a minimaly viable learning resource description while leaving open the addition of other properties needed with a particular use, might assist implementers needing a means to jumpstart development of their own profile based in schema.org.
7. Create support materials explaining LRMI properties
Recently, examples of how to use the AlignmentObject as well as the LRMI properties of CreativeWork have been added as ‘footers’ to the relevant schema pages at schema.org. While an excellent beginning, these additions are not enough. Other types of support materials for describing learning resources using the LRMI properties and classes need to be defined, developed, and published. Such materials might include a one-stop “primer” that combines narrative with examples and covers the inevitable points in usage where subjective decisions must be made where there are alternative legitimate paths forward.
8. Collate information about existing LRMI implementations
Specifications always need to be interpreted in order to be used in specific contexts, and however much normative and informative material is provided, we cannot hope to cover all contexts. One way that people implementing a specification can make choices that do not lead to unnecessary divergence is by referring to other implementations from similar contexts. LRMI could facilitate this by collating information about where these implementations can be found. This may also be useful in monitoring the uptake of the specification, identifying problems commonly encountered and providing examples of good practice.
9. Create an editor for LRMI metadata
Several tools exist that can create LRMI metadata within the scope of a single project or service’s needs. What is suggested here is that LRMI create, assist or promote the creation of an editor that can serve as a reference implementation: independent of the choices that would need to be made for any use in practice but flexible enough to be tailored practical use and, importantly, illustrating good practice in the implementation of LRMI.
In the end we discussed and voted on the issues of which ideas seemed most appealing and then, after eliminating those ideas which were not popular, we discussed and voted on the ideas that seemed least feasible, then had a short discussion about the results. We kept a tally of the votes on a flip chart: green ticks for ideas we thought attractive, red ticks for those we thought least feasible.
The ideas most liked were:
Structured, controlled vocabularies for LRMI properties,
Define a minimal subset of schema.org for describing learning materials, and
Collate information about existing LRMI implementations.
As was pointed out in the discussion, there are relationships between the ideas which mean that some other ideas become easier if these are achieved first (e.g. a general purpose editor becomes easier if you have agreed a general purpose subset of schema for it to edit).
Those ideas which we thought most difficult to achieve were
Structured, controlled vocabularies for LRMI properties and
Declare a “Learning Resource” type.
The specific issues with both of these centred around achieving agreement or consensus on terms and definitions.
I’m pretty sure that everyone involved in LRMI will see something in these results that they think a sensible outcome and something which raises an eyebrow or two. I’m also fairly sure that it won’t be the same things for everyone.. which is to say, the discussions will continue.
So what now?
Some of the ideas discussed are based on work that individuals or groups involved in LRMI are already scoping out. As a group we have made a start on formally describing some values for use with LRMI terms as SKOS concepts (see the DCMI/LRMI Github repository). I have had a masters student work on creating a subset of schema.org for learning resources. There is an editor for LRMI in the works, which looks like it could meet the sort of requirements described above. And as I described in the presentation I gave at the workshop, there is work describing how LRMI is used. So hopefully we will be able to make progress on some of these ideas.
As I said during the workshop, LRMI is a volunteer effort. People work on whichever aspects of it interests them. If you are interested in any of the ideas described above, or have some other ideas that you think would be valuable, please join us and I hope will be able to achieve more together.
This progress update on the work to extend schema.org to support the discovery of any type of educational course is cross-posted from the Schema Course Extension W3C Community Group. If you are interested in this work please head over there.
What aspects of a course can we now describe?
As a result of work so far addressing the use cases that we outlined, we now have answers to the following questions about how to describe courses using schema.org:
How to identify a course which is a prerequisite of the course being described or to link to or describe other prerequisites.
As with anything in schema.org, many of the answers proposed are not the final word on all the detail required in every case, but they form a solid basis that I think will be adequate in many instances.
What new properties are we proposing?
In short, remarkably few. Many of the aspects of a course can be described in the same way as for other creative works or events. However we did find that we needed to create two new types Course and CourseInstance to identify whether the description related to a course that could be offered at various times or a specific offering or section of that course. We also found the need for three new properties for Course: courseCode, coursePrerequisites and hasCourseInstance; and two new properties for CourseInstance: courseMode and instructor.
There are others under discussion, but I highlight these as proposed because they are being put forward for inclusion in the next release of the schema.org core vocabulary.
More good news: the Google search gallery documentation for developers already includes information on how to provide the most basic info about Courses. This is where we are going
I am chair of the Schema Course Extension W3C Community Group, which aims to develop an extension for schema.org concerning the discovery of any type of educational course. This progress update is cross-posted from there.
Course, a subtype of CreativeWork: A description of an educational course which may be offered as distinct instances at different times and places, or through different media or modes of study. An educational course is a sequence of one or more educational events and/or creative works which aims to build knowledge, competence or ability of learners.
CourseInstance, a subtype of Event: An instance of a Course offered at a specific time and place or through specific media or mode of study or to a specific section of students.
hasCourseInstance, a property of Course with expected range CourseInstance: An offering of the course at a specific time and place or through specific media or mode of study or to a specific section of students.
The wiki is working to a reasonable extent as a place to record the outcomes of the discussion. Working from the outline use cases page you can see which requirements have pages, and those pages that exist point to the relevant discussion threads in the mail list and, where we have got this far, describe the current solution. The wiki is also the place to find examples for testing whether the proposed solution can be used to mark up real course information.
The next phase of the work should see us performing, working through the requirements from the use cases and showing how they can be me. I think we should focus first on those that look easy to do with existing properties of schema.org/Event and schema.org/CreativeWork.