Tag Archives: Other

Pathways and learning⤴

from @ Sharing and learning

I am looking again at how to represent education and career pathways in RDF. This post is just some random nonsense that occurred to me on the way. You can see the current CTDL Handbook section for how we handle Pathways (though this is being rewritten for clarity).

It seems apt to use RDF to represent pathways because:

  1. JSON-LD and RDF, which are the technical foundation for CTDL, are both ways of representing what mathematicians call graphs, more specifically directed graphs. Graph theory was initiated by the mathematician Leonhard Euler in order to answer the question of whether he could create a pathway that crossed each of the Seven bridges of Königsberg once and only once. The use of CTDL for educational and occupational pathways seems like a pleasing echo of this origin story.
  2. Many of the words used in education are etymologically linked to the idea of travel along a route, most obviously course but also curriculum (a small carriage) and career (from the French carriere a carriageway), pedagogy (Latin, to lead a child) and education itself (from the Latin ex ducare to lead out).  Even learn is distantly derived from following a track.

The post Pathways and learning appeared first on Sharing and learning.

RDF language… beyond the data dictionary⤴

from @ Sharing and learning

My work with Credential Engine focuses on CTDL, the Credential Transparency Description Language, which is an RDF vocabulary. We often describe it as a dictionary of terms we use to describe credentials. As an ice-breaker for a recent meeting I asked

What does a language need apart from a vocabulary in order to allow communication?

We got many interesting answers, with many different takes on the question, all of them correct. Here is my answer to that question as applied to RDF. It comes with the disclaimer that my knowledge of linguistics doesn’t go much beyond the first paragraph of Wikipedia articles, and so an apology to linguists (including friends) who know better.

I took a loose interpretation on “need”, many of these are desirable rather than necessary. Working from the smallest part outwards:

Predictable Morphology, which is the way in which terms are formed (Wikipedia). In English you know that –ed at the end of a verb means it is in the past tense, or that plurals are often formed by adding –s to the end of the word. CTDL, like some RDF vocabularies is somewhat erratic rather than predictable on this score (but, hey, so is English). Perhaps the single most adhered-to morphological rule is that classes are named with UpperCamelCase and properties with lowerCamelCase. Another example of morphology in RDF is the use of hasSomething for property names (hasPart, hasParent, hasChild) indicating object to object relationship (and not, as in some other paradigms, a binary yes/no value). In CTDL we also have a convention that a property that takes its value from a controlled vocabulary has a name following the pattern somethingType, e.g. audienceType, though we use the Type suffix for other things as well where it seems natural.

Vocabulary, that’s the term definitions, the dictionary, which was our starting point, but let’s emphasize semantics, which in RDF goes beyond just textual definitions of the meaning of terms and includes encoding machine readable relationships between terms. So the term definitions will include information that can be used to make inferences beyond what is explicitly stated in the data. If you know that all Athenians and Greek, and Socrates is an Athenian, then you know that Socrates is Greek; in RDF you can encode this information into the definition of Athenian so that it can be inferred rather than stated explicitly for ever individual Athenian.

Then there are a couple of things that I think fall under grammar.

Parts of speech, different types of word fulfill different roles in a language: verbs, nouns, adjective, adverbs, some verbs are transitive, some are intransitive, and so on. In RDF we have terms that are properties and terms that are Classes. The Classes are types or groups of things; the properties express relationships between things or characteristics of them. An important class is that of Literals which comprises text, numbers, dates used to describe or provide values when providing data about some characteristic of something. OWL introduced more divisions of property; SKOS gave us Concepts.

Syntax, the rules for how words and morphemes combine to form larger units such as phrases and sentences [Wikpedia]. In English, the verb goes in between the subject and object, in German the order is subject-object-verb; in English the adjective goes before a noun (“a red book”) in Spanish it is after («un libro azule»). One of the foundational standards for RDF covers the Abstract Syntax for RDF: the use of properties and classes to make statements in the form of triples: Subject-property-Object; only non-Literals can be the Subject; from OWL object-properties are used with non-Literal values in the object position; data-properties go with Literals; and so on.

Style, grammar isn’t always 100% prescriptive: some people would rather die than split an infinitive, others are more relaxed; some people say “whom”, others only use it when they want to sound like a butler; and some people will end a sentence with with. RDF has differing styles too, largely influenced by the reason for using RDF. Formal ontologies in OWL which are designed for logical inferencing look different to loose ontologies with weak semantics designed for linked data.

Forms of Expression, a language can be written or spoken; if written there will be a writing system (an alphabet or a syllabary), sometimes a choice (e.g. katagana and hiragana for Japanese; or what you’re reading and Braille for English). For RDF these are called concrete syntaxes, and the expression is the serialization. Popular concrete syntaxes are N3, Turtle, JSON-LD (and RDF/XML is an unpopular syntax).

Speakers, a community of people wanting to say something. Tolkien said that his original interest was in creating new languages; the stories were his way of creating people who would use those languages. Likewise, RDF and CTDL would be nothing without users creating descriptions. There are lots of those: the Credential Finder has over 100,000 credentials described in CTDL, over 200,000 competencies, and many other resources; that’s a lot, though of course other data sets are bigger.

What do you think? Let me know if I got anything wrong, or if you would add anything.

The post RDF language… beyond the data dictionary appeared first on Sharing and learning.

Templates and Shapes in Dublin Core Tabular Application Profile⤴

from @ Sharing and learning

The Dublin Core Tabular Application Profile (DC TAP) deals with some pretty abstract stuff, this post is an attempt to address a couple of the abstract concepts in a TAP: Statement Templates and Shapes. It will probably only make sense if read alongside the DC TAP Primer.

If “metadata” is data about data, the DC TAP specification is about data about metadata. I prefer to think of metadata as structured descriptions of resources, so a TAP is data representing how to structure descriptions of resources. Not surprisingly, in the group that created DC TAP we often got ourselves lost not knowing what level of abstraction we were talking about (“when you say ‘the data…’ what do you mean by data”), so we spent time writing a “style guide” for Talking About Metadata and Application Profiles.

My view of metadata is that it is a collection of statements about the characteristics of things and the relationships of those things to other things.  A DC TAP provides templates for these statements. Merriam Webster provides some definitions of Template that are useful in this context:

a gauge, pattern, or mold (such as a thin plate or board) used as a guide to the form of a piece being made

something that establishes or serves as a pattern

a transparent sheet containing graphic matter to be superimposed on another sheet

I also found (at Wordnik) template defined as

An overlay that fits over all or part of a keyboard and has labels describing the functions of each key within a particular application.

Those fit with our intended use cases for DC TAPs to serve for the creation, explanation and validation of metadata. A template can be used to trace out new patterns, label existing ones and be used to check examples, passing only those that match.

Here are some templates for tags that I found on the web:Four outline shapes for gift tags.My visual metaphor statement templates is pretty similar to these. Imagine you wanted to state that the metadata should include a name and description—the name being a short label the description possibly being a longer piece of text—you might picture these as being suitable statement templates:

Two outline shapes for gift tags, one with a small space for text labelled as name, the other with a larger space labelled as descriptions.

So now imagine you want to attach these statement templates to the same thing. You might imagine then fastening on like this:A blue rectangle with the name and description attached a bit like jigsaw pieces.So name and description statements that match the templates we have will slot nicely into a description of something if it has a particular shape, which is currently looking something like this:The outline of the shape into which the name and description tags would "clip".That’s the shape into which statements that match the name and description templates would attach, which is fine for metadata that describes characteristics, but what about metadata statements that show the relationships between things? For this we need a tag that attaches at both end, something a template like this might produce:Outline of a fancy looking gift tag labelled "related thing" that has two holes that could be used to attach it to two things.This you can imagine as producing statement that could link between two things (that may be differently shaped). Instead of the template having an area for the data you want to provide in the statement it has a second connector which is specific to the shape you want to connect it to:Two different shapes linked by a "tag"Translating this into the terminology we use in the TAP, shapes are things that define which types of statements that may be used to describe some type of thing, and statement templates define the different tags that can be used to describe that type of thing. There in fact two different forms of statement template: those that define data types (think of it as stuff that can be written on the tag) to for characteristics of what you are describing, and those that define links to other types of thing, described their own shape. You see this in a tap as statement templates with a value type and a datatype and those with an IRI or BNode and a value shape:

shapeID shapeLabel propertyID propertyLabel valueShape mandatory repeatable
bookShape Book dct:title Book title TRUE FALSE
dct:description Book description FALSE TRUE
dct:creator Author authorShape TRUE TRUE

The post Templates and Shapes in Dublin Core Tabular Application Profile appeared first on Sharing and learning.

Credential Engine publishes rubrics⤴

from @ Sharing and learning

A few months back I helped Credential Engine extend the Credential Transparency Description Language (CTDL) to cover Rubrics. They are have now published the first batch of rubrics in the Credential Finder for viewing on the web and as linked data.

From the top, a heading on a dark blue background with the rubric title and the name of the organization that created it. Below: left, descriptive text in a blue box; right information about the creator of the rubric and what it was created for. Below these, a black "tear" across the page indicates a discontinuity. Below that a table showing the rubric criteria (rows), levels of attainment (columns) and in each cell a description of the expect performance for that criterion-level.
Rubric information as displayed by the credential finder, edited to remove the middle of a long page.

Rubrics are or course useful when marking assessments, but transparency of rubrics is important in describing educational attainment because if you don’t know what criteria were used in assessing a skill then you don’t know whether an assertion of some level of proficiency in that skill is sufficient for the task you have in mind. This matters to anyone learning (or thinking of learning) a new skill, or applying for a job, and to employers looking to hire someone.

From early last year Credential Engine ran a task group for Rubrics which, as task groups do for any major update to CTDL, looked at use cases, existing practice, data models(*) and how they all related to what was already in CTDL before proposing new terms for the description of rubrics. (* Incidentally, as part of this Stuart Sutton used the Data Ecosystem Schema Mapping tool (DESM) to create a mapping of existing Rubric standards, available from the Credential Engine DESM page, select Rubrics). The outcome was the ability to describe in detail rubrics, the criteria they use and the levels expected against those criteria. You can also relate rubrics (and their criteria) to credentials, assessments, learning opportunities, tasks, jobs, occupations and industries, and provide information about who created the rubric and what for. This is described in the relevant section of the CTDL Handbooks.

And now there are the first 25 rubrics in the registry. You can access them through the Credential Finder, which as well as having the descriptive information for the rubrics as a whole has all the details of the criteria used. I hope this will aid discovery and reuse of the best rubrics, and that the availability as linked data (warning, raw JSON-LD file for applications and coders) will bring clarity to assertions made in credentials and job requirements. In future maybe learning outcome descriptions, credentials and job adverts will be able to be more precise about what is meant by “ability to weave baskets”.

The post Credential Engine publishes rubrics appeared first on Sharing and learning.

Some recent Work (Expression, Manifestation, Item)⤴

from @ Sharing and learning

I blame John. He got me interested in FRBR, and long ago he helped me with a slightly mad attempt at FRBRizing Learning Resources. Of course FRBR is for Bibliographic Records, isn’t it? and according to several people I respect it doesn’t work (though other people whom I respect equally say that it does). Personally I always struggled around the expression/manifestation distinction for many types of resource, and always wanted it to play more nicely with the resource/representation approach of the WWW Architecture. But I did keep coming back to it when trying to explain the need to be clear about what exactly was being described in RDF, for example. If you’ve heard me go off on one about Romeo and Juliet, and the play-on-the-stage vs play-on-the-page, or the difference between novels and books, then you’ll know what I mean. So that’s why I got involved in the W3C OpenWEMI working group, certainly I didn’t contribute any expertise on WEMI that wasn’t already covered, but I hope I helped with some of the RDF stuff because I’ve certainly learnt a lot, and now:

Dublin Core announces openWEMI for community review

openWEMI is an RDF vocabulary based on the concepts of Work, Expression, Manifestation, and Item (WEMI) that were first introduced in the Functional Requirements for Bibliographic Records (FRBR) document produced by a working group of the International Federation of Library Associations (IFLA). That work and subsequent versions form the theoretical basis for library catalog metadata.

This DCMI work product defines a minimally constrained set of classes and properties that can be used in a variety of contexts. Unlike the IFLA work, openWEMI elements are purposely defined without reference to library catalog functions….

See the news item on the Dublin Core website for more information about how you can comment on the work.

Kudos to Karen Coyle for leading us through this work, and thanks to all the other working group members.

The post Some recent Work (Expression, Manifestation, Item) appeared first on Sharing and learning.

When RDF breaks records⤴

from @ Sharing and learning

In talking to people about modelling metadata I’ve picked up on a distinction mentioned by Staurt Sutton between entity-based modelling, typified by RDF and graphs, and record-based structures typified by XML; however, I don’t think making this distinction alone is sufficient to explain the difference, let alone why it matters.  I don’t want to get into the pros and cons of either approach here, just give a couple of examples of where something that works in a monolithic, hierarchical record falls apart when the properties and relationships for each entity are described separately and those descriptions put into a graph. These are especially relevant when people familiar with XML or JSON start using JSON-LD. One of the great things about JSON-LD is that you can use instance data as if it were JSON, without really paying much regard to the “LD” part; that’s not true when designing specs because design choices that would be fine in a JSON record will not work in a linked data graph.

1. Qualified Instances

It’s very common in a record-oriented approach when making statements about something that many people may have done, such as attending a specific school, earning a qualification/credential, learning a skill etc, to have a JSON record that looks something like:

{ "studentID": "Person1",
  "studentName": "Betty Rizzo",
  "schoolsAttended": [
    { "schoolID": "School1",
      "schoolName": "Rydell High School",
      "schoolAddress" : {...}
      "startDate": "1954",
      "endDate": "1959"
    }
  ]
}

It’s tempting to put a @context on the top of this to map the property keys to an RDF vocabulary and call it linked data. That’s sub-optimal. To see why consider two students Betty, as above, and Sandy who joined the school for her final academic year, 1958-59. Representing her data and Betty’s as RDF graphs we would get something like:

Two RDF graphs for two people attending the same school at different dates

The upper  graph is a representation of what you might get for the record about Rizzo shown above, if you choose a suitable @context. The lower is similar data about Sandy. When this data is loaded into an RDF triple store, the statements will be stored separately, and duplicates removed. We can show that data as a single merged graph:

RDF graph showing two people attending the same school with start dates and end dates as properties of the school.

Whereas in a record the hierarchy preserves the scope for statements like startDate and endDate so that we know who they refer to, in the RDF graph statements from the JSON object describing the school attended are taken as being about the school itself. The problem arises because the information about the school is treated as data that can be linked to by anything that relates to the school, not just the entity in whose record it was found, which makes sense in terms of data management.

There are options for fixing this: one is not to merge the graphs about the Betty and Sandy, but that means repeating all the data about the school in every record that mentions it; another possible solution is to use the property-graph or RDF-star approach of annotating the schoolAttended property directly with startDate and endDate; but often the answer lies in better RDF modelling. In this case we could create an entity to model the attendance of a person at a school:

Separate RDF graphs showing attendance of two individuals at a school

and when these are merged:Single RDF graph showing attendance of two individuals at a school

which keeps the advantage of not duplicating information about the school while maintaining the information about who attended which school when. In JSON-LD this conbined graph would look something like

{ "@context": {...},
  "@graph": [
    { "@id": "Person1",
      "name": "Betty Rizzo",
      "schoolAttended": { 
        "startDate": "1953",
        "endDate": "1959",
        "at": {"@id": "School1"}
      }
    },{
      "@id": "Person2",
      "name": "Sandy Olsson",
      "schoolAttended": {
        "startDate": "1953",
        "endDate": "1959",
        "at": {"@id": "School1"}
      }
   },{
     "@id": "School1",
     "name": "Rydell High",
     "address": {
       "@type": "PostalAddress",
       "...": "..."
     }
   }]
}

 

Finally, those who just want a JSON record for an individual student that could easily be converted to LD could use something like:

 
{ "studentID": "Person1", 
  "schoolsAttended": [ 
    { "startDate": "1954", 
      "endDate": "1959",
      "at": {
          "schoolID": "School1",
          "schoolName": "Rydell High School",
          "schoolAddress" : {...}
      } 
  ] 
}

You might think that the “attendance” object sitting between a person and the school is a bit artificial and unintuitive, which it is, but it’s no worse than the tables that RDBM systems need for many-to-many relationships.

2. Lists

Another pattern that comes up a lot is when logically separate resource may be ordered in different ways for different reasons. This may be people in a queue, journal articles in a volume, or learning resources in a larger learning opportunity; anywhere that you might want to say “this” comes before “that”. Say we have an educational program that has a number of courses in it that should be taken in sequential order. JSON lists are ordered, so as a record this seems to work:

{
  "name": "My Program",
  "hasCourse": [
    {"name": "This"},
    {"name": "That"},
    {"name": "The other"}
  ]
}

So we sprinkle on some syntactic sugar for JSON-LD:

{
 "@context": {"@vocab": "http://schema.org/", 
               "@base": "http://example.org/resources/"},
 "@type": "EducationalOccupationalProgram",
 "name": "My Program",
 "hasCourse": [
   {"@type": "Course",
    "@id": "Course1",
    "name": "This"},
   {"@type": "Course",
    "@id": "Course2",
    "name": "That"},
   {"@type": "Course",
    "@id": "Course3",
    "name": "The other"}
 ]
}

But there is no RDF statement in there about ordering, and  the ordering of JSON’s arrays is not preserved in other RDF syntaxes (unless there is something in the @context to say the value of hasCourse is an @list, it wouldn’t be appropriate to say that every value of hasPart is an ordered list because not every list of parts will be an ordered list). So if we convert the JSON-LD into triples and store them, there is no saying how to order the results returned by a query.

The simple solution would be to have a property to state the position of the course in an ordered list (schema.org/position is exactly this)—but don’t be too hasty: if these courses are taken in more than one program, is Course 2 always going to be second in the sequence? Probably not. In general when resources are reused in different contexts they will probably be used in different orders, “this” may not always come before “that”. That’s why the ordering is best specified at one remove from resources themselves. For example, one of the suggestions for ordering content in K12-OCX is to create a table of contents as an ordered list of items that point to the content, something like:

{
  "@context": {
    "@vocab": "http://schema.org/",
    "ocx": "http://example.org/ocx/",
    "@base": "http://example.org/resources/",
    "item": {"@type": "@id"}
  },
  "@type": "EducationalOccupationalProgram",
  "name": "My Program",
  "ocx:hasToC": {
    "@type": "ItemList",
    "name": "Table of Contents",
    "itemListOrder": "ItemListOrderAscending",
    "numberOfItems": "3",
    "itemListElement": [
      { "@type": "ListItem",
        "item": "Course1",
        "position": 1},
      { "@type": "ListItem",
        "item": "Course2",
        "position": 2 },
      { "@type": "ListItem",
        "item": "Course3",
        "position": 3 }
    ]
  },
 "hasCourse": [
   {"@type": "Course",
    "@id": "Course1",
    "name": "This"},
   {"@type": "Course",
    "@id": "Course2",
    "name": "That"},
   {"@type": "Course",
    "@id": "Course3",
    "name": "The other"}
 ]
}

or if you prefer to use built-in RDF constructs there is that @list option:

{ "@context": {
    "@vocab": "http://schema.org/", 
    "ocx": "http://example.org/ocx/", 
    "@base": "http://example.org/resources/", 
    "ocx:hasToC": {"@container": "@list"}
  },
  "@type": "EducationalOccupationalProgram",
  "@id": "Program",
  "name": "My Program",
  "ocx:hasToC": ["Course1", "Course2", "Course3"],
  "hasCourse": [
  { "@id": "Course1",
    "@type": "Course",
    "name": "this"
  },{
    "@id": "Course2",
    "@type": "Course",
    "name": "that"
  },{
    "@id": "Course3",
    "@type": "Course",
    "name": "the other"
  }]
}

When this is processed by something like JSON-LD playground you will see that the list of values for hasToC is replaced by a set of statements about blank-nodes which mean this comes before the others:

<ocx:hasToC> _:b0 .
_:b0 <rdf:first> "http://example.org/resources/Course1" .
_:b0 <rdf:rest> _:b1 .
_:b1 <rdf:first> "http://example.org/resources/Course2" .
_:b1 <rdf:rest> _:b2 .
_:b2 <rdf:first> "http://example.org/resources/Course3" .
_:b2 <rdf:rest> <rdf:nil> .

Conclusion

If you’ve made it this far you deserve the short summary advice. The title for this post was meant literally. Representing a record in RDF will break the record down into separate statements, each about one thing, each saying one thing, with the assumption that those statements are each valid on their own. In modelling for JSON-LD you need to make sure that everything you say about an object is true even when that object is separated from the rest of the record.

The post When RDF breaks records appeared first on Sharing and learning.

Strings to things in context⤴

from @ Sharing and learning

As part of work to convert plain JSON records to proper RDF in JSON-LD I often want to convert a string value to a URI that identifies a thing (real world concrete thing or a concept).

Simple string to URI mapping

Given a fragment of a schedule in JSON

{"day": "Tuesday"}

As well as converting "day" to a property in an RDF vocabulary I might want to use a concept term for “Tuesday” drawn from that vocabulary. JSON-LD’s @context lets you do this: the @vocab keyword says what RDF vocabulary you are using for properties; the @base keyword says what base URL you are using for values that are URIs; the @id keyword maps a JSON key to an RDF property; and, the @type keyword (when used in the @context object) says what type of value a property should be, the value of @type that says you’re using a URI is "@id" (confused by @id doing double duty? it gets worse). So:

[code]
{
"@context": {
"@vocab": "http://schema.org/",
"@base": "http://schema.org/",
"day": {
"@id": "dayOfWeek",
"@type": "@id"
}
},
"day": "Tuesday"
}
[/code]

Pop this in to the JSON-LD playground to convert it into N-QUADS and you get:

_:b0 <http://schema.org/dayOfWeek> <http://schema.org/Tuesday> .

Cool.

What type of thing is this?

The other place where you want to use URI identifiers is to say what type/class of thing you are talking about. Expanding our example a bit, we might have

{
  "type": "Schedule",
  "day": "Tuesday"
}

Trying the same approach as above, in the @context block we can use the @id keyword to map the string value "type" to the special value "@type"; and, use the @type keyword with special value "@id" to say that the type of value expected is a URI, as we did to turn the string “Tuesday” into a schema.org URI. (I did warn you it got more confusing). So:

[code]
{
"@context": {
"@vocab": "http://schema.org/",
"@base": "http://schema.org/",
"type": {
"@id": "@type",
"@type": "@id"
},
"day": {
"@id": "dayOfWeek",
"@type": "@id"
}
},
"type": "Schedule",
"day": "Tuesday"
}
[/code]

Pop this into the JSON-LD playground and convert to N-QUADS and you get

_:b0 <http://schema.org/dayOfWeek> <http://schema.org/Tuesday> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Schedule> .

As we want.

Mixing it up a bit

So far we’ve had just the one RDF vocabulary, say we want to use terms from a variety of vocabularies. For the sake of argument, let’s say that no one vocabulary is more important than another, so we don’t want to use @vocab and @base to set global defaults. Adding  another term from a custom vocab in to the our example:

{ 
  "type": "Schedule",
  "day": "Tuesday",
  "onDuty": "Phil" 
}

In the context we can set prefixes to use instead of full length URIs, but the most powerful feature is that we can use different @context blocks for each term definition to set different @base URI fragments. That looks like:

[code]
{
"@context": {
"schema": "http://schema.org/",
"ex" : "http://my.example.org/",
"type": {
"@id": "@type",
"@type": "@id",
"@context": {
"@base": "http://schema.org/"
}
},
"day": {
"@id": "schema:dayOfWeek",
"@type": "@id",
"@context": {
"@base": "http://schema.org/"
}
},
"onDuty": {
"@id": "ex:onDuty",
"@type": "@id",
"@context": {
"@base": "https://people.pjjk.org/"
}
}
},
"type": "Schedule",
"day": "Tuesday",
"onDuty": "phil"
}
[/code]

Translated by JSON-LD Playground that gives:

_:b0 <http://my.example.org/onDuty> <https://people.pjjk.org/phil> .
_:b0 <http://schema.org/dayOfWeek> <http://schema.org/Tuesday> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://json-ld.org/playground/Schedule> .

Hmmm. The first two lines look good. The JSON keys have been translated to URIs for properties from two different RDF vocabularies, and their string values have been translated to URIs for things with different bases, so far so good. But, that last line: the @base for the type isn’t being used, and instead JSON-LD playground is using its own default. That won’t do.

The fix for this seems to be not to give the @id keyword for type the special value of "@type", but rather treat it as any other term from an RDF vocabulary:

[code]
{
"@context": {
"schema": "http://schema.org/",
"ex" : "http://my.example.org/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"type": {
"@id": "rdf:type",
"@type": "@id",
"@context": {
"@base": "http://schema.org/"
}
},
"day": {
"@id": "schema:dayOfWeek",
"@type": "@id",
"@context": {
"@base": "http://schema.org/"
}
},
"onDuty": {
"@id": "ex:onDuty",
"@type": "@id",
"@context": {
"@base": "https://people.pjjk.org/"
}
}
},
"type": "Schedule",
"day": "Tuesday",
"onDuty": "phil"
}
[/code]

Which gives:

_:b0 <http://my.example.org/onDuty> <https://people.pjjk.org/phil> .
_:b0 <http://schema.org/dayOfWeek> <http://schema.org/Tuesday> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://schema.org/Schedule> .

That’s better, though I do worry that the lack of a JSON-LD @type key might bother some.

Extensions and Limitations

The nested context for a JSON key works even if the value is an object, it can be used to specify the @vocab and @base and any namespace prefixes used in the keys and values of the value object. That’s useful if title in one object is dc:title and title in another needs to be schema:title.

Converting string values to URIs for things like this is fine if the string happens to match the end of the URI that you want. So, while I can change the a JSON key "author" into the property URI <https://www.wikidata.org/prop/direct/P50> I cannot change the value string "Douglas Adams" into <https://www.wikidata.org/entity/Q42>. For that I think you need to use something a bit more flexible, like RML, but please comment if you know of a solution to that!

Also, let me know if you think the lack of a JSON-LD @type keyword, or anything else shown above seems problematic.

The post Strings to things in context appeared first on Sharing and learning.

Reading one of 25 years of EdTech⤴

from @ Sharing and learning

I enjoyed Martin Weller‘s blog post series on his 25 years of Ed Tech, and the book that followed, so when Lorna said that she had agreed to read the chapter on e-Learning Standards, and would I like to join her and make it a double act I thought… well, honestly I thought about how much I don’t enjoy reading stuff out loud for other people. But, I enjoy working with Lorna, and don’t get as many chances to do that as I would like, and so it happened.

I think the reading went well. You decide. Reading the definitions of the Dublin Core metadata element set  I learnt one thing: I don’t want to be the narrator for audiobook versions of tech standards.

And then there’s the “between the chapters” podcast interview, which Lorna and I have just finished recording with Laura Pasquini, which was fun. We covered a lot of the things that Lorna and I wanted to: that we think Martin was hard on Dublin Core Metadata, I think his view of it was tarnished by the IEEE LOM; but that we agree with the general thrust of what Martin wrote. Many EdTech Standards were not a success, certainly the experience that many in EdTech had with standards was not a good one. But we all learnt from the experience and did better when it came to dealling with OER (Lorna expands on this in her excellent post reflecting on this chapter). Also, many technical standards relevant to education were a success, and we use them every day without (as Martin says) knowing much about them. And there’s the thing: Martin probably should never have been in the position knowing about Dublin Core, IEEE LOM and UK LOM Core, they should just have just been there behind that systems that he used, making things work. But I guess we have to remember that back then there weren’t many Learning Technologists to go round and so it wasn’t so easy to find the right people to get involved.

We did forget to cover a few things in the chat with Laura.

We forgot how many elephants were involved in UK LOM Core.

We forgot “that would be an implementation issue”.

But my main regret is that we didn’t get to talk about #EduProg, which came about a few years later (the genesis story is on Lorna’s blog) as an analysis of a trend in Ed Tech that contrasted with the do-it-yourself-and-learn approach of EduPunk. EduProg was exemplified in many of the standards which were either “long winded and self-indulgent” or “virtuoso boundary pushing redefining forms and developing new techniques”, depending on your point of view. But there was talent there — many of the people behind EduProg were classically trained computer scientists. And it could be exciting. I for one will never forget Scott plunging a dagger into the keyboard to hold down the shift key while he ran arpeggios along the angle brackets. I hear it’s still big in Germany.

Thank you to Martin, Laura, Clint, Lorna and everyone who made it the reading & podcast possible.

Added 5 Jan: here’s Lorna’s reflections on this recording.

[Feature image for this post, X-Ray Specs by @visualthinkery, is licenced under CC-BY-SA]

The post Reading one of 25 years of EdTech appeared first on Sharing and learning.

LRMI Metadata in use⤴

from @ Sharing and learning

There was no Dublin Core conference this year, but there was the DCMI Virtual Event over the second half of September, and for the last session of that I hosted a panel session on LRMI Metadata in use. The recordings for many of the sessions are now available, including our LRMI panel.

Further Details

We had four presentations, each fifteen minutes long, and a discussion at the end. Here’s an index for the recording and links to further resources mentioned. The four presentations were:

The discussion follows.

I have linked the title of each presentation to its starting point in the YouTube video.

About LRMI

You can find many of the LRMI properties in schema.org under the LearniningResource type, but you can also find LRMI Specifications on DCMI Website, including the version 1.1 of the specification as it was handed to DCMI, the terms in RDF (currently being updated), and concept schemes to provide controlled vocabularies for the values for some of those terms.

The DCMI LRMI Task Group curates LRMI and liases with other standards bodies that use the properties (notably schema.org). We meet the first Tuesday of every month. To join us, simply join the task group Mailing list.

If you’re interested in LRMI, join the google group for occasional updates about the spec, or to ask questions of the wider community.

Reflections

I’ve not had any formal feedback from attendees, but I felt it went well and kind people are telling me similar (or not saying anything). A colleague on LRMI made a useful comment, that we should have had a few questions for audience at the start that would have helped us understand their background. That would help us gauge whether we had got the technical level of the content right.

I’m quite happy with the structure of the session, starting with design priniciples for LRMI as a whole, looking at how it has been applied to the description of learning resources, and finally how it has been applied to a search solution.  I hope there is enough of a logical flow there to give some coherence to what is a fairly long session. I was also happy with the discussion session afterwards, and the overall balance of how we used the time. Hopefully the recording and slides will be useful resources themselves, and in our latest LRMI call we agreed that it would be useful to repeat this type of presentation for other audiences (though I hope not as a manel). Many thanks to the presenters and others who took part.

Finally, I had a small role in organizing the event as a whole, enough to recognise how much effort Paul Walk and the other people on the organizing committee put in to making this a successful event–thank you.

The post LRMI Metadata in use appeared first on Sharing and learning.

LearningResource added to schema.org⤴

from @ Sharing and learning

A new type was added to the ‘pending’ terms in schema.org in the July release (release 9.0), LearningResource. It sits in the type hierarchy as a subtype of CreativeWork, and the definition and notes read:

The LearningResource type can be used to indicate CreativeWorks (whether physical or digital) that have a particular and explicit orientation towards learning, education, skill acquisition, and other educational purposes.

LearningResource is expected to be used as an addition to a primary type such as Book, Video, Product etc.

EducationEvent serves a similar purpose for event-like things (e.g. a Trip). A LearningResource may be created as a result of an EducationEvent, for example by recording one.

The properties in the domain of LearningResource are those that come from LRMI, nameley:  assesses, educationalAlignment, educationalLevel, educationalUse, and teaches. [Oops, learningResourceType is missing]

Although listed as pending, people using schema.org to describe educational resources are encouraged to use the term and report any issues. The only way terms can move from pending to the core of schema.org is if there is sufficient evidence of use.

The Whys and Why Nots

Before saying something about why LearningResource has been added, perhaps it’s worth saying why it wasn’t added before. After all LRMI is the Learning Resource Metadata Initiative, wouldn’t the first thing it did be say what is and isn’t a learning resource? Well, yes and no. In answering that question we acknowledged two facts. First, learning resources can be of any of the subtypes of Creative Work: Books, Videos, Articles, Atlases, Games and so on. Would  we add a “learning resource” subtype to each of these for Book-as-a-learning-resource, Video-as-a-learning-resource…? Secondly, what is and isn’t a learning resource often depends on use (a common definition for learning resource is “anything that can be used for learning”). So while a textbook is a learning resource by design, who would say you don’t learn something by reading Shakespeare? or reading a newspaper? or a recipe? I’ve seen custard used to help learning two distinct topics in physics (crystal nucleation when making ice cream, and thixotropic fluids)–does that make custard a learning resource? So the decision was made not to create learning resource as a separate type, but to add properties to all types of CreativeWork that allowed you to describe its educational characteristics and how it might be used for learning.

So why change now? It’s not because the argument above is wrong, especially not in pedagogic terms. However, such arguments have been seen to have a detrimental effect on efforts to curate learning resources. We are not teaching here, we are trying to help people find resources, and a different type of thinking is required. Creating a collection policy based on the definition of “anything can be a learning resource” has lead to unfocused, unsustainable collections, for example OER repositories that are 90% images, badly described because the description schema wasn’t set up for images, and swamping all other types of resources. Yes, images are useful for learning, but there are better ways to curate images than in a system designed fo learning resources. So the schema.org LearningResource type is for those resources that “that have a particular and explicit orientation towards learning, education, skill acquisition, and other educational purposes”. Although I wouldn’t want to put a hard boundary around this definition there are instances that clearly meet it–text books, instructional videos, assessments, lesson plans, online courses, infographics and so on. As an analogy: many things can be used as a hammer, or as a paperweight, you can even use hammers as paperweights and vice versa (with varying degress of success); that does not mean that there are things that are definitely hammers, or paperweights. Imagine what would happen if you set up a hammer store and all people could see in it were rocks (because, you know, who would say a rock can’t be used as a hammer?) Would that help anyone find your wonderfully specialized peen hammers, maul hammers, sledge hammers, soft-headed hammers, claw hammers and gavels?

We also found that, without a LearningResource type, we could not say that there is a schema for describing learning resources in the way that there is a schema for describing recipes.  This made it unneccesarily difficult for people wanting to describe educational charcteristics of resources to find the properties that would be useful. We hope this new type will improve the visibility and uptake of LRMI properties in schema.org

Finally, does this mean that a schema.org:Video cannot be a Learning Resource? After all LearningResource comes under CreativeWork not Video. Fortunately multiple typed entities are now well supported, so the best approach is to declare your instruction video as being both a Video and a LearningResource:

{
    "@context": "https://schema.org/",
    "@type": ["Video", "LearningResource"],
    "url": "https://www.youtube.com/watch?v=TIsUte5kfNw"
    "about": "Thixotropic liquids"
}

This has the added advantage that the use of LRMI properties is not limited to CreativeWorks, so if you have a Product that is designed “a particular and explicit orientation towards learning”, for example an educational toy, you can declare it as a schema:Product and a schema:LearningResource. As in noted in defintion about, some educational things are not really like CreativeWorks at all, for example lectures, museum visits, educational trips; for these the EducationEvent type serves a similar purpose to LearningResource.

The post LearningResource added to schema.org appeared first on Sharing and learning.