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.

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: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:

So now imagine you want to attach these statement templates to the same thing. You might imagine then fastening on like this: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: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: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: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:

The post Templates and Shapes in Dublin Core Tabular Application Profile appeared first on 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.

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.