Tag Archives: resource description

What am I doing here? 3. Tabular Application Profiles⤴

from @ Sharing and learning

The third thing (of four) that I want to include in my review of what projects I am working on is the Dublin Core standard for Tabular Application Profiles. It’s another of my favourites, a volunteer effort under the DCMI Application Profiles Working Group.

Application profiles are a powerful concept, central to how RDF can be used to create new data models without creating entirely new standards. The DCTAP draft says this about them:

An application profile defines metadata usage for a specific application. Profiles are often created as texts that are intended for a human audience. These texts generally employ tables to list the elements of the profile and related rules for metadata creation and validation. Such a document is particularly useful in helping a community reach agreement on its needs and desired solutions. To be usable for a specific function these decisions then need to be translated to computer code, which may not be a straightforward task.

About the work

We have defined an (extensible) set of twelve elements that can be used as headers in a table defining an application profile, a primer showing how they can be used, and along the way we wrote a framework for talking about metadata and application profiles. We have also worked on various implementations and are set to create a cookbook showing how DC TAP can be used in real world applications. The primer is the best starting point for understanding the output as a whole.

The framework for talking about metadata came about because we were struggling to be clear when we used terms like property or entity. Does “property” refer to something in the application profile or in the base standard or in as used in some metadata instance or does it refer to a property of some thing in the world? In short we decided that the things being described have characteristics and relationship to each other which are asserted in RDF metadata using statements that have a predicates in them, those predicates reference properties that are part of a pre-defined vocabulary, and an application profile defines templates for how the property is used in statements to create descriptions. There is a similar string of suggestions for talking about entities, classes and shapes as well as some comments on what we found too confusing and so avoid talking about. With a little care you can use terms that are both familiar in context and not ambiguous.

About my role

This really is a team effort, expertly lead by Karen Coyle, and I just try to help. I will put my hand up as the literal minded pedant who needed a framework to make sure we all understood each other. Otherwise I have been treating this a side project that gives me an excuse to do some python programming: I have documented my TAP2SHACL and related scripts on this blog, which focus on taking a DCMI TAP and expressing it as SHACL that can be used to validate data instances. I have been using this on some other projects that I am involved in, notably the work with PESC looking at how they might move to JSON-LD.

The post What am I doing here? 3. Tabular Application Profiles appeared first on Sharing and learning.

Learning Resource Types in LRMI⤴

from @ Sharing and learning

It took a while, but we now have in LRMI a Learning Resource Type concept scheme that defines a controlled vocabulary of terms that you might use to describe the type or nature of a learning resource.

Why it took a while: what is a learning resource, and what is a type?

Aside from everything in metadata being harder than you first think, and having less time than we would like, the main reason it took so long (and it took, like, a few years) comes down to aspects of what is a learning resource? and what it a type? Some folk maintain that there is no well-defined class of “learning resources”, anything can be used for learning and teaching, and that trying to describe different sub-types of “anything” is going to be a fruitless task. Pedagogically, I have no argument with the statement that anything can be used for learning and teaching, but for information systems that is not a useful starting point. I have seen repositories crash and burn because they took that as their collection policy. Telling people who are looking for resources to help them learn maths that they can use anything, just be imaginative in how you use it, is not helpful.

By way of analogy, pretty much anything can be used as a hammer. Somethings will be better than others, the ones that are the right weight, hard and not brittle, but I’ve used stones, shoes, lumps of wood, monkey wrenches and so on as hammers with some success.  That doesn’t mean that “hammer” doesn’t exist as a category, not does it mean that it isn’t useful to distinguish a peen hammer from a sledgehammer from a copper-headed mallet. Not that I am easily distracted, but I have found plenty of shops that not only sell hammers as a distinct type of tool but they have a fascinating array of different types of specialist hammers.

Our first step to resolving this discussion was a couple of years back when we agreed to define a class of Learning Resource as:

A persistent resource that has one or more physical or digital representations, and that explicitly involves, specifies or entails a learning activity or learning experience.

So, not just anything that can be used for learning and teaching, but something that is meant to be used for learning and teaching.

Intuitively it seems clear that there are different types of learning resource: lesson plans are different to textbooks, video lectures are different to assessment items. But how to encapsulate that? Is something an assessment because it is used for assessment, or is there something inherent in some resources that makes them assessments? Likewise is a video lecture a different type of thing from a lecture or just a different format? The answer in each case is sometimes yes to both. The use of something may be strongly correlated to what it is but use and type are still distinct. That is fine: we have in LRMI a property of educationalUse, which can be assessment, and now learningResourceType which can also be assessment. Likewise, the format of something may be correlated to what it is: textbooks tend to include text; a video recording of a lecture will be a video. Again that is fine, we have mime types and other ways of encoding format to convey that information, but they won’t tell you whether something is a text book or a children’s picture book, and not all recordings of lectures will be videos. So learning resource type may be correlated to to educational use and format without being the same.

Principles adopted for the LRMI Learning Resource Type vocabulary

As with all our work in LRMI, we adopted a couple of principles. First it should focus solely on what was relevant to learning, education and training: other vocabularies deal well with other domains or generic terms. Second, create small vocabulary of broad, a high level terms to which other people can map their special cases and similar terms: those special cases are often so context dependent that they frequently don’t travel well. Related to both of these, we mapped our vocabulary to terms in two others: CEDS and the Library of Congress Genre/Form terms. The links to CEDS terms are useful because CEDS is well established in the US system, and we provided pre-existing terms many of which we adopted. The link to the LoC terms is useful because it links our terms into a comprehensive list of generic terms. LoC terms are an example of one of the vocabularies that you might want to use if you are describing things like data as learning resources: we don’t cover it because data as a learning resource is not distinct from data in general, but we are all linked data here, and when providing resource descriptions you can mix terms from our scheme with those from others.

Using the LRMI Learning Resource Type vocabulary

The vocabulary is expressed in SKOS, and so it ready for linked data use.

If you manage your own list of learning resource types using SKOS, we invite you create links to the LRMI concepts and thus improve interoperability of learning resource descriptions. We would be interested in hearing from you if you are in this situation. Perhaps you have suggestions for further concepts; you can raise an issue about the concept scheme if that is the case.

If you create learning resource descriptions you may reference this vocabulary in several ways, for example in JSON-LD you may have:

  { "@context": {
      "lrmi"    : "http://purl.org/dcx/lrmi-terms/",
      "lrt"     : "http://purl.org/dcx/lrmi-vocabs/learningResourceType/",
      "dcterms" : "http://purl.org/dc/terms/",
      "lrmi:learningResourceType" : {
         "@type": "@id"
      }
    },
    "@type": "lrmi:LearningResouce",
    "@id": "http://example.edu/textbooks/0001",
    "dcterms:name": "Example Textbook",
     "lrmi:learningResourceType": "http://purl.org/dcx/lrmi-vocabs/learningResourceType/textbook"
  }

Or, if you don’t want to rely on consumers understanding/dereferencing that URI to get vital information, you may prefer:

{ "@context": {
    "lrmi" : "http://purl.org/dcx/lrmi-terms/",
    "lrt" : "http://purl.org/dcx/lrmi-vocabs/learningResourceType/",
    "dcterms" : "http://purl.org/dc/terms/",
    "skos" : "http://www.w3.org/2004/02/skos/core#"
  },
  "@type": "lrmi:LearningResouce",
  "@id": "http://example.edu/textbooks/0001",
  "dcterms:name": "Example Textbook",
  "lrmi:learningResourceType": {
    "@id": "http://purl.org/dcx/lrmi-vocabs/learningResourceType/textbook",
    "skos:prefLabel": "textbook"
  }
}

In schema.org, you may use the labels defined as simple string values, but you could include a link to our full definition (and hence provide access the links to other schemes that we define — after all this is linked data), by using a defined term as the value for learning resource type

{ "@context": "https://schema.org/",
  "@type": "LearningResouce",
  "@id": "http://example.edu/textbooks/0001",
  "name": "Example Textbook",
  "learningResourceType": {
    "@type": "DefinedTerm",
    "@id": "http://purl.org/dcx/lrmi-vocabs/learningResourceType/textbook",
    "name": "textbook"
  }
}

The post Learning Resource Types in LRMI appeared first on Sharing and learning.

Graphical Application Profiles?⤴

from @ Sharing and learning

In this post I outline how a graphical representation of an application profile can be converted to SHACL that can be used for data validation.

My last few posts have been about work I have been doing with the Dublin Core Application Profiles Interest Group on Tabular Application Profiles (TAPs). In introducing TAPs I described them as “a human-friendly approach that also lends itself to machine processing”. The human readability comes from the tabular format, and the use of a defined CSV structure makes this machine processable. I’ve illustrated the machine processability through a python program, tap2shacl.py, that will convert a TAP into SHACL that can be used to validate instance data against the application profile, and I’ve shown that this works with a simple application profile and a real-world application profile based on DCAT. Once you get to these larger application profiles the tabular view is useful but a graphical representation is also great for providing an overview. For example here’s the graphic of the DCAT AP:

Source: join-up DCAT AP

Mind the GAP

I’ve long wondered whether it would be possible to convert the source for a graphical representation of an application profile (let’s call it a GAP) into one of the machine readable RDF formats. That boils down to processing the native format of the diagram file or any export from the graphics package used to create it. So I’ve routinely been looking for any chance of that whenever I come across a new diagramming tool. The breakthrough came when I noticed that lucid chart allows CSV export. After some exploration this is what I came up with.

As diagramming software, what Lucid chart does is quite familiar from Visio, yEd, diagrams.net and the like: it allows you to produce diagrams like the one below, of the (very) simple book application profile that we use in the DC Application Profiles Interest Group for testing:

two boxes, one representing data about a book, the other data about a person, joined by an arrow representing the author relationship. Lots of further detail about the book an author data is provided in the boxes, as discussed in the text of the blog post.

One distinctive feature of Lucid chart is that as well as just entering text directly into fields in the diagram, you can enter it into a data form associated with any object in the diagram, as shown below, first for the page and then for the shape representing the Author:

A screen shot of the Lucid Chart software showing the page and page data

A screen shot of the Lucid Chart software showing the Auhtor Shape and the data for it.

In the latter shot especially you can see the placeholder brackets [] in the AuthorShape object into which the values from the custom data form are put for display. Custom data can be associated with the document as a whole, any page in it and any shape (boxes, arrows etc) on the page;  you can create templates for shapes so that all shapes from a given template have the same custom data fields.

I chose a template for to represent Node Shapes (in the SHACL/ShEx sense, which become actual shapes in the diagram) that had the the following data:

  • name and expected RDF type in the top section;
  • information about the node shape, such as label, target, closure, severity in the middle section; and,
  • a list of the properties that have the range Literal is entered directly in the lower section (i.e. these don’t come from the custom data form).

Properties that have a range of BNode or URI are represented as arrows.

By using a structured string for Literal valued properties, and by adding information about the application profile and namespace prefixes and their URIs into the sheet custom data, I was able to enter most of the data needed for a simple application profile. The main shortcomings are that format for Literal valued properties is limited, and that complex  constraints such as alternatives (such as: use this Literal valued property or that URI property depending on …) cannot be dealt with.

The key to the magic is that on export as CSV, each page, shape and arrow gets a row, and there is a column for the default text areas and for the custom data (whether or not the latter is displayed). It’s an ugly, sparsely populated table, you can see a copy in github, but I can read it into a python Dict structure using python’s standard CSV module.

GAP2SHACL

When I created the TAP2SHACL program I aimed to do so in a very modular way: there is one module for the central application profile python classes, another to read csv files and convert them into those python classes, another to convert the python classes into SHACL and output them; so tap2shacl.py is just a wrapper that provide a user interface to those classes. That approach paid off here because having read the CSV file exported from lucid chart all I had to do was create a module to convert it into the python AP classes and then I could use AP2SHACL to get the output. That conversion was fairly straightforward, mostly just tedious if ...  else statements to parse the values from the data export. I did this in a Jupyter Notebook so that I could interact more easily with the data, that notebook is in github.

Here’s the SHACL generated from the graphic for the simple book ap, above:

# SHACL generated by python AP to shacl converter
@base <http://example.org/> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sdo: <https://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<BookShape> a sh:NodeShape ;
    sh:class sdo:Book ;
    sh:closed true ;
    sh:description "Shape for describing books"@en ;
    sh:name "Book"@en ;
    sh:property <bookshapeAuthor>,
        <bookshapeISBN>,
        <bookshapeTitle> ;
    sh:targetClass sdo:Book .

<AuthorShape> a sh:NodeShape ;
    sh:class foaf:Person ;
    sh:closed false ;
    sh:description "Shape for describing authors"@en ;
    sh:name "Author"@en ;
    sh:property <authorshapeFamilyname>,
        <authorshapeGivenname> ;
    sh:targetObjectsOf dct:creator .

<authorshapeFamilyname> a sh:PropertyShape ;
    sh:datatype xsd:string ;
    sh:maxCount 1 ;
    sh:minCount 1 ;
    sh:name "Family name"@en ;
    sh:nodeKind sh:Literal ;
    sh:path foaf:familyName .

<authorshapeGivenname> a sh:PropertyShape ;
    sh:datatype xsd:string ;
    sh:maxCount 1 ;
    sh:minCount 1 ;
    sh:name "Given name"@en ;
    sh:nodeKind sh:Literal ;
    sh:path foaf:givenName .

<bookshapeAuthor> a sh:PropertyShape ;
    sh:minCount 1 ;
    sh:name "author"@en ;
    sh:node <AuthorShape> ;
    sh:nodeKind sh:IRI ;
    sh:path dct:creator .

<bookshapeISBN> a sh:PropertyShape ;
    sh:datatype xsd:string ;
    sh:name "ISBN"@en ;
    sh:nodeKind sh:Literal ;
    sh:path sdo:isbn .

<bookshapeTitle> a sh:PropertyShape ;
    sh:datatype rdf:langString ;
    sh:maxCount 1 ;
    sh:minCount 1 ;
    sh:name "Title"@en ;
    sh:nodeKind sh:Literal ;
    sh:path dct:title .

I haven’t tested this as thoroughly as the work on TAPs. The SHACL is valid, and as far as I can see it works as expected on the test instances I have for the simple book ap (though slight variations in the rules represented somehow crept in). I’m sure there will be ways of triggering exceptions in the code, or getting it to generate invalid SHACL, but for now, as a proof of concept, I think it’s pretty cool.

What next?

Well, I’m still using TAPs for some complex application profile / standards work. As it stands I don’t think I could express all the conditions that often arise in an application profile in an easily managed graphical form. Perhaps there is a way forward by generating a tap from a diagram and then adding further rules, but then I would worry about version management if one was altered and not the other. I’m also concerned about tying this work to one commercial diagramming tool, over which I have no real control. I’m pretty sure that there is something in the GAP+TAP approach, but it would need tighter integration between the graphical and tabular representations.

I also want to explore generating other outputs that SHACL from TAPs (and graphical representations). I see a need to generate JSON-LD context files for application profiles, we should try getting ShEx from TAPs, and I have already done a little experimenting with generating RDF-Schema from Lucid Chart diagrams.

The post Graphical Application Profiles? appeared first on Sharing and learning.

DCAT AP DC TAP: a grown up example of TAP to SHACL⤴

from @ Sharing and learning

I’ve described a couple of short “toy” examples as proof of concept of turning a Dublin Core Application Profile (DC TAP) into SHACL in order to validate instance data: the SHACL Person Example and a Simple Book Example; now it is time to see how the approach fares against a real world example. I chose the EU joinup Data Catalog Application Profile (DCAT AP) because Karen Coyle had an interest in DCAT, it is well documented (pdf) with a github repo that has SHACL files, there is a Interoperability Test Bed validator for it (albeit a version late) and I found a few test instances with known errors (again a little dated). I also found the acronym soup of DCAT AP DC TAP irresistable.

You can see the extended TAP as Google sheets.  The tap tab is the DCTAP, the other tabs are information about the Applicaiton profile, namespace prefixes and shapes that are needed by tap2shacl. You can also see the csv export files, test instances and generated SHACL for DCATAPDCTAP in my TAPExamples github repo. The actual TAP is maybe a little ragged around the edges. Partly I got bored, partly I wasn’t sure how far to go: for example, should every reference to a Catalog be a description that conforms to all the DCAT AP rules for a catalog, or is it sufficient to just have an IRI in the instance data? At the other extreme what to do about properties where the only requirement was that an entity of a certain type be referenced — should the SHACL demand the type be explicitly declared or is the intent that an IRI in the instance data is enough and the type may be inferred?

Reflections

I had to add a little functionality where I wanted a shape to be used against two targets, objects of a property and instances of a class. This actually prompted a fairly significant rewrite of how shape information is handled, and I have thought of further extensions.

It works in that valid SHACL is produced. The SHACL is more verbose than the hand crafted SHACL produced by the DCAT AP project, but I think that is to be expected from a general purpose conversion script. It also works in that when I run the test instances through the itb SHACL validator with my SHACL and through the DCAT AP specific validator they both flag the same errors. My shacl actually raises more error messages, but that is a result of  it being more verbose, sometimes it gives two errors (one that the value of a predicate does not match the expecterd shape, the second about how the shape is not matched). The important thing is that the same fixes work on both.

I’m quite happy with this. There may be some requirements in the DCAT AP that I haven’t checked for, but this will do for now. Next I want to work out how best to require a specific skos concept scheme be used.

The only niggle that I have is that the TAP sheet in Google docs isn’t as easily human readable as the corresponding tables in the DCAT AP documentation. There’s a balance we’re working on between keep the necessary precision while weighing technical correctness against human friendliness, and it is hard to strike.

The post DCAT AP DC TAP: a grown up example of TAP to SHACL appeared first on Sharing and learning.

Application Profile to Validation with TAP to SHACL⤴

from @ Sharing and learning

Over the past couple of years or so I have been part of the Dublin Core Application Profile Interest Group creating the DC Tabular Application Profile (DC-TAP) specification. I described DC-TAP in a post about a year ago as a “human-friendly approach that also lends itself to machine processing­”, in this post I’ll explore a little about how it lends itself to machine processing.

A metadata application profile represents an implementor’s or a community’s view on how a metadata description should be formed: which terms should be used from which vocabularies, are they required or optional? may they be repeated? what range of values do expect each of them to have? and so on [see Heery and Patel and the Singapore Framework for more details]. Having created an application profile it is fairly natural to want to ask whether specific instance data conforms with it — does it have the data required in the form required by the implementor or community’s application(s)? I have been using the EU-funded joinup Interoperability Test Bed‘s SHACL Validator for this, and so I would like to generate SHACL for my validation.

The simple book application profile.

There are several current and potential application profiles that I am interested in, including the Credential Engine minimum data requirements for using CTLD to describe the various types of resource in the Credential Registry. I also have a long standing interest in application profiles of schema.org and LRMI for describing learning resources, which is currently finding an outlet in the IEEE P2881 Standard for Learning Metadata working group. But these and any other real application profile tend to be long and can be complex. A really short simple application profile is more useful for illustrative purposes, and we in the DC-TAP group have been using various iterations around a profile describing books (even for such a simple application profile the table doesn’t display well with my blog theme, so please take a look at it on github). Here’s a summary of what it is intended to encode:

  • Line 1: Book instance data must have one and only one dct:title of type rdf:langString.
  • Line 2: Book instance data may have zero or more dct:creator described as an RDF instance with a URI or a BNODE, matching the #Author shape.
  • Line 3: Book instance data may have zero or one sdo:isbn with Literal value being an xsd:string composed of 13 digits only.
  • Line 4: Book instance data must have rdf:type of sdo:Book.
  • Line 5: Author instance data may have zero or more foaf:givenName with Literal value type xsd:string.
  • Line 6: Author instance data may have zero or more foaf:familyName with Literal value type xsd:string
  • Line 7: Author instance data must have rdf:type of foaf:Person

(Let’s leave aside any questions of whether those are sensible choices, OK?)

A SHACL view of the TAP

Looking at the TAP through the lens of SHACL, we can draw a parallel between what in TAP we call statement constraints, i.e. the rows in the TAP, which each identify a property and any rules that constrain its use, and what SHACL calls property shapes. Likewise what  in TAP we call shapes  (a group of statement constraints) aligns with what SHACL calls a Node Shape. The elements of a statement constraint map more or less directly to various SHACL properties that can be used with Node and Property Shapes. So:

Construct in TAP Rough equivalent in SHACL
Statement Constraint Property Shape
Shape Node Shape
propertyID sh:path of a sh:PropertyShape
propertyLabel sh:name on a sh:PropertyShape
mandatory = TRUE sh:minCount = 1
repeatable = FALSE sh:maxCount = 1
valueNodeType sh:nodeKind
valueDataType sh:dataType
valueShape sh:node
valueConstraint depends on valueConstraintType and valueNodeType

Processing valueConstraints can get more complex than other elements. If there is no valueNodeType and a single entry, then it is used as the value for sh:hasValue, either as a Literal or IRI depending on valueNodeType. If the valueConstraintType is “pickList” or if there are more than one entries in valueConstraint then you need to create a list to use with the sh:or property. If the  valueConstraintType is “pattern” then the mapping to sh:pattern is straightforward, and that should only apply to Literal values. Some other SHACL constraint components are not in the DCTAP core set of suggested entries for valueConstraint, but it seems obvious to add “minLength”, “maxLength” and so on to correspond to sh:minLength, sh:maxLength etc.; lengthRange works too if you specify the range in a single entry (I use the format “n..m”). I do not expect DC TAP will cover all of what SHACL covers, so don’t expect to find sh:qualifiedValueShape or other complex constraint components.

As alluded to above, TAP allows for multiple entries in a table cell to provide alternative ways of fulfilling a constraint. These lists of entries need to be processed in different ways depending on which element of statement constraint they relate to. Often they need turning into a list to be used with sh:or or sh:in; lists of alternative valueNodeType need turning into the corresponding value for sh:nodeType, for example IRI BNODE becomes  sh:BlankNodeOrIRI.

Extended TAPs to provide other SHACL terms

Some things needed by SHACL (and other uses of application profiles) are not in DC TAP. We know that TAP only covers a core and we expect different solutions to providing other information to emerge depending on context. For some people providing some of the additional information as, say, a YAML file will work; for other people or other data, further tables may be preferable. So while we know that metadata about the application profile and a listing of the IRI stems for any prefixes used for compact URI encodings in the TAP need to be provided, we don’t specify how. I chose to use additional tables for all this data.

I’ve already touched on how additional constraints useful in SHACL, like minLength that are easily provided if we extend the range of allowed valueConstraintType. Another useful SHACL property is sh:severity, for this I added an extra column to the TAP table.

However the biggest omission from the TAP of data useful in SHACL is data about sh:NodeShapes. From the “Shape” column we know which shapes the properties relate to, but we have no way of providing descriptions for these shapes, or, most crucially, specifying what entities in the instance data should conform to which shapes. I use a table to provide this data as well. Currrently(*),  it has columns for shapeID, label, comment, target, targetType (these last two can be used to set values of sh:targetObjectsOf, sh:targetClass, sh:targetNode, sh:targetSubjectsOf as appropriate), closed (true or false, to set  sh:Closed), mandatory, severity and note. (*This list of columns is somewhat in flux, and the program described below doesn’t process all of them).

A Google Sheets template for extended TAPs

So, for my application profile I have four tables: the DC TAP, plus tables for: metadata about the application profile; prefixes/namespaces used; information about TAP Shapes / sh.NodeShapes. All these tables can be generated as spreadsheet tabs in a single workbook. The details are still a little fluid, but I have created a template for such in Google Sheets, which also includes some helpful additions like data validation to make sure that the values in cells make sense. You are welcome to make a copy of this template and try it out, it includes a sheet with further information and details of how to leave feedback.

Processing TAP to SHACL

I have also written a set of python classes to convert CSV files exported from the extended TAP into SHACL. These are packaged together as tap2shacl, available on Github — it is very much an alpha-release proof of concept, that doesn’t cover all the things discussed above let alone some of the things I have glossed over, but feel free to give it a try.

The architecture of the program is as follows:

  • I have data classes for the application profile as a whole and individual property statements. This includes methods to read in Metadata, shape information and prefix/namespace information from CSV files as exported from Google Sheets (or other editor with the same column headings)
  • I use Tom Baker’s dctap-python program to read the CSV of the TAP. This does lots of useful validity checking and normalization as well as handling a fair few config options, and generally handles the variation in CSVs better than the methods I wrote for other tables. TAP2AP handles the conversion from Tom’s format to my python AP classes.
  • The AP2SHACL module contains a class and methods to convert the python AP classes into a SHACL RDF Graph and serialize these for output (leaning heavily on rdf-lib).
  • Finally the TAP2SHACL package pulls these together and provides a command line interface.

If that seems like more modules and github repos that necessary, you may be right, but I wanted to be hyper-granular because I have use cases where the input isn’t a TAP CSV and the output isn’t SHACL. For example, the Credential Engine minimum data requirements are encoded in JSON, for other sources YAML is another possibility, and I have ideas about converting Application Profile diagrams; and I can see sense in outputting ShEx and JSON-Schema as well as SHACL. I also want to keep the number of imported third-party modules down to a minimum: why should someone wanting to create JSON-Schema have to import the rdf-lib classes needed for SHACL?

Does it work?

Well, it wouldn’t have been fair to let you read this far if the answer wasn’t broadly “yes” 🙂 Checking that it works is another matter.

There are plenty of unit tests in the code for me to be confident that it can read some files and output some RDF, albeit with the caveat that it is alpha-release software so it’s not difficult to create a file that it cannot read, often because the format is not quite right.

There are even some integration tests so that I know that the RDF output from some TAPs matches the valid SHACL that I expect, at least for simple test cases. Again, it is not difficult to generate invalid SHACL or not produce the terms you would expect if there happens to be something in the TAP that I haven’t yet implemented. TAP is quite open, and the software is still developing, so I’ll not attempt to list the potential mismatches here, but I’ll be working documenting them in github issues.

But then there’s the question of whether the SHACL that I expect correctly encodes the rules in the application profile. That takes testing itself, so for each application profile I work on I need test cases of instance data that either matches or doesn’t match the expectations in mind when creating the application profile. I have a suite of 16 test cases for the simple book profile. These can be used in the SHACL Validator with the SHACL file generated from the TAP; and yes, mostly they work.

I have got to admit that I find the implications of needing 16 tests for such a simple profile somewhat daunting when thinking about real-world profiles that are an order of magnitude or more larger, but I hope that confidence and experience built with simple profiles will reduce the need to so many test cases. So my next steps will be to slowly build up the range of constraints and complexity of examples. Watch this space for more details, or contact me if you have suggestions.

The post Application Profile to Validation with TAP to SHACL appeared first on Sharing and learning.

Dublin Core Tabular Application Profile⤴

from @ Sharing and learning

Over the last year or so I have been contributing to a Dublin Core Metadata Initiative Interest Group, lead by Karen Coyle, that has been drafting recommendations on how to create and document application profiles in simple a tabular format. At the end of last year we had a webinar presenting the work so far, which now available on YouTube. For me the really useful thing about this approach, which we are calling DC TAP, is that it is a human-friendly approach that also lends itself to machine processing­—at the end of the webinar recording Tom Baker demos a python script that will take a tabular application profile exported in CSV format and turn it into ShEx that can be used to validate data.

Application Profiles

“data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application” –Heery and Patel

Application profiles are a powerful concept, central to how RDF can be used to create new schemas without creating entirely new standards. The idea was presented in “Application Profiles: Mixing and Matching Metadata Schemas” by Rachel Heery and Manjula Patel, where it was defined as: “schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application”. Twenty years on and the only part of that definition that I would quibble with is that “local” underplays how widely useful an application profile can be when shared. A couple of examples might illustrate this.

The Data Catalog Vocabulary (DCAT) is a “vocabulary designed to facilitate interoperability between data catalogs published on the Web”. It draws on terms from external vocabularies like Dublin Core and FOAF;  where these aren’t sufficient it mints new terms, and it mixes these terms according to a domain model relevant to data sets. Thus DCAT can be seen as an application profile of several pre-existing vocabularies supplemented with few new terms and a model of how to use those terms. Recently, when I was asked about describing learning resources about data management, I suggested adding LRMI into this mix and so create a schema using terms that are mostly already familiar in that domain.—No need for the implementors to move to a new specification. (Hence the use of DCAT at the end of my previous post on harmonizing LOM metadata with RDF.)

Bioschemas “aim to improve the Findability on the Web of life sciences resouces”. They take a similar approach, but with the starting point of schema.org. Unlike Dublin Core and FOAF, schema.org is a huge and ever-growing vocabulary, and the main issue in using it is one of selection, i.e. cutting it down to size, and explanation, i.e. explaining how you want to use what has been selected. On their website you can see their draft recommendation for how they would describe Courses; note the tabular format, how they tweak the term descriptions to be understandable for their community, how they add requirements such as which properties must be used and whether a property can be repeated, also they place constraints on the values allowable for some properties, e.g. that the value should be drawn from a specific concept scheme. This general approach will also be familar to anyone who has looked at Google’s guidlines on use of schema.org for various search products it offers, for example recipes.

Tabular Application Profiles

Select, Explain, Constrain, Share

One of my colleagues in the DC TAP interest group, Nishad talks about “profiling” “contraining” and “explaining” as the key aspects of an Application Profile. Application Profiles allow you to select which terms you want to use, explain how to use them, place constraints on their use (i.e. narrow down what is allowed in the definition of the vocabulary) and share them with others. Existing standards, notably ShEx and SHACL overlap with this approach, but the aim of the DC TAP group has been to create a simple format congruent with the approach that is often taken by the people who build application profiles. Hence the tabular approach rather than an RDF specification, which I feel will provide a format that fosters collaboration around these profiles. The simplest allowable TAP is a single column list of the properties that have been selected. The most complex allows you to specify which properties are used to describe which types of entity, how they are related, what formats should be used for values, which gets more technical but the tabular approach to preseting this helps keep it manageable. Importantly, the output is actionable, e.g. can be transformed to ShEx and SHACL to allow data selection and validation services, or can be parsed to automatically create data entry forms, etc.

There’s plenty of further expanation in the video (embedded above) and in the draft specification and draft primer, but I’ll end with screen shots of a simple example: a schema for describing a course. The vocabulary used is schema.org, so the central entities are CourseInstances (offerings of a course) with specific start and end dates, at a virtual or physical location, about some concept, and with a person as the instructor. First the circles-and-arrows diagram, then the corresponding TAP.

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

JSON Schema for JSON-LD⤴

from @ Sharing and learning

I’ve been working recently on definining RDF application profiles, defining specifications in JSON-Schema, and converting specifications from a JSON Schema to an RDF representation. This has lead to me thinking about, and having conversations with people  about whether JSON Schema can be used to define and validate JSON-LD. I think the answer is a qualified “yes”. Here’s a proof of concept; do me a favour and let me know if you think it is wrong.

Terminology might get confusing: I’m discussing JSON, RDF as JSON-LD, JSON Schema, RDF Schema and schema.org; which are all different things (go an look them up if you’re not sure of the differences).

Why JSON LD + JSON Schema + schema.org?

To my mind one of the factors in the big increase in visibility of linked data over that last few years has been the acceptability of JSON-LD to programmers familiar with JSON. Along with schema.org, this means that many people are now producing RDF based linked data often without knowing or caring that that is what they are doing. One of the things that seems to make their life easier is JSON Schema (once they figure it out). Take a look at the replies to this question from @apiEvangelist for some hints at why and how:

Also, one specification organization I am working with publishes its specs as JSON Schema. We’re working with them on curating a specification that was created as RDF and is defined in RDF Schema, and often serialized in JSON-LD. Hence the thinking about what happens when you convert a specification from RDF Schema to JSON Schema —  can you still have instances that are linked data? can you mandate instances that are linked data? if so, what’s the cost in terms of flexibility against the original schema and against what RDF allows you to do?

Another piece of work that I’m involved in is the DCMI Application Profile Interest Group, which is looking at a simple way of defining application profiles — i.e. selecting which terms from RDF vocabularies are to be used, and defining any additional constraints, to meet the requirements of some application. There already exist some not-so-simple ways of doing this, geared to validating instance data, and native to the W3C Semantic Web family of specifications: ShEx and ShACL. Through this work I also got wondering about JSON Schema. Sure, wanting to use JSON Schema to define an RDF application profile in JSON Schema may seem odd to anyone well versed in RDF and W3C Semantic Web recommendations, but I think it might be useful to developers who are familiar with JSON but not Linked Data.

Can JSON Schema define valid JSON-LD?

I’ve heard some organizations have struggled with this, but it seems to me (until someone points out what I’ve missed) that the answer is a qualified “yes”. Qualifications first:

  • JSON Schema doesn’t defined the semantics of RDF terms. RDF Schema defines RDF terms, and the JSON-LD context can map keys in JSON instances to these RDF terms, and hence to their definitions.
  • Given definitions of RDF terms, it is possible to create a JSON Schema such that any JSON instance that validates against it is a valid JSON-LD instance conforming to the RDF specification.
  • Not all valid JSON-LD representations of the RDF will validate against the JSON Schema. In other words the JSON Schema will describe one possible serialization of the RDF in JSON-LD, not all possible serializations. In particular, links between entities in an @graph array are difficult to validate.
  • If you don’t have an RDF model for your data to start with, it’s going to be more difficult to get to RDF.
  • If the spec you want to model is very flexible, you’ll have difficulty making sure instances don’t flex it beyond breaking point.

But, given the limited ambition of the exercise, that is “can I create a JSON Schema so that any data it passes as valid is valid RDF in JSON-LD?”, those qualifications don’t put me off.

Proof concept of examples

My first hint that this seems possible came when I was looking for a tool to use when working with JSON Schema and found this online JSON Schema Validator.  If you look at the “select schema” drop down and scroll a long way, you’ll find a group of JSON Schema for schema.org. After trying a few examples of my own, I have a JSON Schema that will (I think) only validate JSON instances that are valid JSON-LD based on notional requirements for describing a book (switch branches in github for other examples).

Here are the rules I made up and how they are instantiated in JSON Schema.

First, the “@context” sets the default vocabulary to schema.org and allows nothing else:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "context.json",
  "name": "JSON Schema for @context using schema.org as base",
  "description": "schema.org is @base namespace, but others are allowed",
  "type": "object",
  "additionalProperties": false,
  "required": [ "@vocab" ],
  "properties": {
    "@vocab": {
      "type": "string",
      "format": "regex",
      "pattern": "http://schema.org/",
      "description": "required: schema.org is base ns"
    }
  }
}

This is super-strict, it allows no variations on @context": {"@vocab" : "http://schema.org"} which obviously precludes doing a lot of things that RDF is good at, notably using more than one namespace. It’s not difficult to create looser rules, for example madate schema.org as the default vocabulary but allow some or any others. Eventually you create enough slack to allow invalid linked data (e.g. using namespaces that don’t exist; using terms from the wrong namespace) and I promised you only valid linked data would be allowed. In real life, there would be a balance between permissiveness and reliability.

Rule 2: the book ids must come from wikidata:

{
 "$schema": "http://json-schema.org/draft-07/schema#",
 "$id": "wd_uri_schema.json",
 "name": "Wikidata URIs",
 "description": "regexp for Wikidata URIs, useful for @id of entities",
 "type": "string",
 "format": "regex",
 "pattern": "^https://www.wikidata.org/entity/Q[0-9]+" 
}

Again, this could be less strict, e.g. to allow ids to be any http or https URI.

Rule 3: the resource described is a schema.org/Book, for which the following fragment serves:

    "@type": {
      "name": "The resource type",
      "description": "required and must be Book",
      "type": "string",
      "format": "regex",
      "pattern": "^Book$"
    }

You could allow other options, and you could allow multiple types, maybe with one type manadatory (I have an example schema for Learning Resources which requires an array of type that must include LearningResource)

Rules 4 & 5: the book’s name and description are strings:

    "name": {
      "name": "title of the book",
      "type": "string"
    },
    "description": {
      "name": "description of the book",
      "type": "string"
    },

Rule 6, the URL for the book (i.e. a link to a webpage for the book) must be an http[s] URI:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http_uri_schema.json",
  "name": "URI @ids",
  "description": "required: @id or url is a http or https URI",
  "type": "string",
  "format": "regex",
  "pattern": "^http[s]?://.+"
}

Rule 7, for the author we describe a schema.org/Person, with a wikidata id, a familyName and a givenName (which are strings), and optionally with a name and description, and with no other properties allowed:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "person_schema.json",
  "name": "Person Schema",
  "description": "required and allowed properties for a Person",
  "type": "object",
  "additionalProperties": false,
  "required": ["@id", "@type", "familyName", "givenName"],
  "properties": {
    "@id": {
      "description": "required: @id is a wikidata entity URI",
      "$ref": "wd_uri_schema.json"
    },
    "@type": {
      "description": "required: @type is Person",
      "type": "string",
      "format": "regex",
      "pattern": "Person"
    },
    "familyName": {
      "type": "string"
    },
    "givenName": {
      "type": "string"
    },
    "name": {
      "type": "string"
    },
    "description": {
      "type": "string"
    }
  }
}

The restriction on other properties is, again, simply to make sure no one puts in any properties that don’t exist or aren’t appopriate for a Person.

The subject of the book (the about property) must be provided as wikidata URIs, with optional @type, name, description and url; there may be more than one subject for the book, so this is an array:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "about_thing_schema.json",
  "name": "About Thing Schema",
  "description": "Required and allowed properties for a Thing being used to say what something is about.",
  "type": "array",
  "minItems": 1,
  "items": {
    "type": "object",
    "additionalProperties": false,
    "required": ["@id"],
    "properties": {
      "@id": {
        "description": "required: @id is a wikidata entity URI",
        "$ref": "wd_uri_schema.json"
      },
      "@type": {
        "description": "required: @type is from top two tiers in schema.org type hierarchy",
        "type": "array",
        "minItems": 1,
        "items": {
          "type": "string",
          "uniqueItems": true,
          "enum": [
            "Thing",
            "Person",
            "Event",
            "Intangible",
            "CreativeWork",
            "Organization",
            "Product",
            "Place"
          ]
        }
      },
      "name": {
        "type": "string"
      },
      "description": {
        "type": "string"
      },
      "url": {
        "$ref": "http_uri_schema.json"
      }
    }
  }
}

Finally, bring all the rules together, making the @context, @id, @type, name and author properties mandatory; about, description and url are optional; no others are allowed.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "book_schema.json",
  "name": "JSON Schema for schema.org Book",
  "description": "Attempt at a JSON Schema to create valid JSON-LD descriptions. Limited to using a few schema.org properties.",
  "type": "object",
  "required": [
    "@context",
    "@id",
    "@type",
    "name",
    "author"
  ],
  "additionalProperties": false,
  "properties": {
    "@context": {
      "name": "JSON Schema for @context using schema.org as base",
      "$ref": "./context.json"
    },
    "@id": {
      "name": "wikidata URIs",
      "description": "required: @id is from wikidata",
      "$ref": "./wd_uri_schema.json"
    },
    "@type": {
      "name": "The resource type",
      "description": "required and must be Book",
      "type": "string",
      "format": "regex",
      "pattern": "^Book$"
    },
    "name": {
      "name": "title of the book",
      "type": "string"
    },
    "description": {
      "name": "description of the book",
      "type": "string"
    },
    "url": {
      "name":"The URL for information about the book",
      "$ref": "./http_uri_schema.json"
    },
    "about": {
      "name":"The subject or topic of the book",
      "oneOf": [
        {"$ref": "./about_thing_schema.json"},
        {"$ref": "./wd_uri_schema.json"}
      ]
    },
    "author": {
      "name":"The author of the book",
      "$ref": "./person_schema.json"
    }
  }
}

I’ve allowed the subject (about) to be given as an array of wikidata entity link/descriptions (as described above) or a single link to a wikidata entity; which hints at how similar flexibility could be built in for other properties.

Testing the schema

I wrote a python script (running in a Jupyter Notebook) to test that this works:

from jsonschema import validate, ValidationError, SchemaError, RefResolver
import json
from os.path import abspath
schema_fn = "book_schema.json"
valid_json_fn = "book_valid.json"
invalid_json_fn = "book_invalid.json"
base_uri = 'file://' + abspath('') + '/'
with open(schema_fn, 'r') as schema_f:
    schema = json.loads(schema_f.read())
with open(valid_json_fn, 'r') as valid_json_f:
    valid_json = json.loads(valid_json_f.read())
resolver = RefResolver(referrer=schema, base_uri=base_uri)
try :
    validate(valid_json,  schema, resolver=resolver)
except SchemaError as e :
    print("there was a schema error")
    print(e.message)
except ValidationError as e :
    print("there was a validation error")
    print(e.message)

Or more conveniently for the web (and sometimes with better messages about what failed), there’s the JSON Schema Validator I mentioned above. Put this in the schema box on the left to pull in the JSON Schema for Books from my github:

{
  "$ref": "https://raw.githubusercontent.com/philbarker/lr_schema/book/book_schema.json"
}

And here’s a valid instance:

{
  "@context": {
    "@vocab": "http://schema.org/"
  },
  "@id": "https://www.wikidata.org/entity/Q3107329",
  "@type": "Book",
  "name": "Hitchhikers Guide to the Galaxy",
  "url": "http://example.org/hhgttg",
  "author": {
    "@type": "Person",
    "@id": "https://www.wikidata.org/entity/Q42",
    "familyName": "Adams",
    "givenName": "Douglas"
  },
  "description": "...",
  "about": [
    {"@id": "https://www.wikidata.org/entity/Q3"},
    {"@id": "https://www.wikidata.org/entity/Q1"},
    {"@id": "https://www.wikidata.org/entity/Q2165236"}
  ]
}

Have a play, see what you can break; let me know if you can get anything that isn’t valid JSON LD to validate.

The post JSON Schema for JSON-LD appeared first on Sharing and learning.

Publications on WordPress⤴

from @ Sharing and learning

I have posted details of my publications on this site. More interestingly, I did so with a plugin and theme extension which builds on previous work on presenting publications in WordPress and using WordPress as a semantic platform. These are useful steps towards WordPress as a lightweight repository.

Publications as custom post types and metadata

The approach rests heavily on custom post types, one for each publication type. And for each post type there are custom metadata boxes that correspond to the schema.org properties that are important for that type of publication. As an added factor, some of the schema.org properties expect values which are entities rather than literals (i.e. Things not Strings). So there are custom post types for these entity types, namely People (the authors) and Organizations (publishers).

Editing details of a chapter, the dropdown options for author some from the People custom posts.

Output and theme extension

For each custom post type and associated metadata there are helper functions which can be called in the theme to output the data wrapped in suitable HTML. This output includes the schema.org properties embedded as RDFa. So, if you look at one of the publication pages through an RDFa enabled tool (such as Google’s Structured Data Testing Tool) you will extract all the metadata for that chapter. (Note: in this case you’ll also get information about this blog put there by SEO plugins I use).

I also created a single archive for all the publication custom post types. This I did pretty much as outlined before. As noted, that code would give all the custom post types with an archive the same archive. That’s not what I want,  so I registered the publication custom post types with a tag of my own

'pubwp_type' => 'publication'

and added this to the query to build the loop for the publications archive:

 
$cpargs = array('_builtin' => False,   
               'exclude_from_search' => False,   
               'pubwp_type' => 'publication'); 
$publication_post_types = get_post_types( $cpargs, 'names', 'and' );
$args = array(
	'post_type' => $publication_post_types,
	'posts_per_page' => -1
);
$publications = new WP_Query( $args );

Next steps

I would like to make the display of the archive more flexible, so it can be filtered and ordered by any parameter that makes sense (date, author, type, topic). Also I should integrate it better with the rest of the blog, so that publication types show up in general archives and searches.

Beyond my own publication list, I can see this approach being useful for disseminating information different types of resource, e.g. OERs, so I would like to make it easier to create new post types, with associated properties and helper functions.

The post Publications on WordPress appeared first on Sharing and learning.

Book chapter: Technology Strategies for Open Educational Resource Dissemination⤴

from @ Sharing and learning

A book with a chapter by Lorna M Campbell and I has just been published. The book is Open Education: International Perspectives in Higher Education edited by Patrick Blessinger and TJ Bliss, published by Open Book Publishers.

There are contributions by people I know and look up to in the OER world, and some equally good chapters by folk I had not come across before. It seems to live up to its billing of offering an international perspective by not being US-centric (though it would be nice to see more from S America, Asia and Africa), and it provides a wide view of Open Education, not limited to Open Education Resources. There is a foreword by David Wiley, a chapter on a human rights theory for open education by the editors, one on whether emancipation through open education is theory or rhetoric by Andy Lane. Other people from the Open University’s Open Education team (Martin Weller, Beatriz de los Arcos, Rob Farrow, Rebecca Pitt and Patrick McAndrew) have written about identifying categories of OER users.  There are chapters on aspects such as open science, open text books, open assessment and credentials for open learning; and several case studies and reflections on open education in practice.

Open Education: International Perspectives in Higher Education is available under a CC:BY licence as a free PDF, as very cheap mobi or ePub, or reasonably priced soft and hard back editions. You should get a copy from the publishers.

Technology Strategies for OER

The chapter that Lorna and I wrote is an overview drawing on our experiences through the UKOER programme and our work on LRMI looking at managing the dissemination and discovery of open education resources. Here’s the abstract in full, and a link to the final submitted version of our chapter.

This chapter addresses issues around the discovery and use of Open Educational Resources (OER) by presenting a state of the art overview of technology strategies for the description and dissemination of content as OER. These technology strategies include institutional repositories and websites, subject specific repositories, sites for sharing specific types of content (such as video, images, ebooks) and general global repositories. There are also services that aggregate content from a range of collections, these may specialize by subject, region or resource type. A number of examples of these services are analyzed in terms of their scope, how they present resources, the technologies they use and how they promote and support a community of users. The variety of strategies for resource description taken by these platforms is also discussed. These range from formal machine-readable metadata to human readable text. It is argued that resource description should not be seen as a purely technical activity. Library and information professionals have much to contribute, however academics could also make a valuable contribution to open educational resource (OER) description if the established good practice of identifying the provenance and aims of scholarly works is applied to learning resources. The current rate of change among repositories is quite startling with several repositories and applications having either shut down or having changed radically in the year or so that the work on which this contribution is based took. With this in mind, the chapter concludes with a few words on sustainability.

Preprint of full chapter (MS Word)

The post Book chapter: Technology Strategies for Open Educational Resource Dissemination appeared first on Sharing and learning.

HECoS, a new subject coding system for Higher Education⤴

from @ Sharing and learning

You may have missed that just before Christmas HECoS (the Higher Education Classification of Subjects) was announced. I worked a little on the project that lead up to this, along with colleagues in Cetis (who lead the project), Alan Paull Serices and Gill Ferrell, so I am especially pleased to see it come to fruition. I believe that as a flexible classification scheme built on semantic web / linked data principles it is a significant contribution to how we share data in HE.

HECoS was commissioned as part of the Higher Education Data & Information Improvement Programme (HEDIIP) in order to find a replacement to JACS, the subject coding scheme currently used in UK HE when information from different institutions needs to be classified by subject. When I was first approached by Gill Ferrell while she was working on a preliminary study of to determine if it needed changing, my initial response was that something which was much more in tune with semantic web principles would be very welcome (see the second part of this post that I wrote back in 2013). HECoS has been designed from the outset to be semantic web friendly. Also, one of the issues identified by the initial study was that aggregation of subjects was politically sensitive. For starters, the level of funding can depend on whether a subject is, for example, a STEM subject or not; but there are also factors of how universities as institutions are organised into departments/faculties/schools and how academics identify with disciplines. These lead to unnecessary difficulties in subject classification of courses: it is easy enough to decide whether a course is about ‘actuarial science’ but deciding whether ‘actuarial science’ should be grouped under ‘business studies’ or ‘mathematics’ is strongly context dependent. One of the decisions taken in designing HECoS was to separate the politics of how to aggregate subjects from the descriptions of those subjects and their more general relationships to each other. This is in marked contrast to JACS where the aggregation was baked into the very identifiers used. That is not to say that aggregation hierarchies aren’t important or won’t exist: they are, and they will, indeed there is already one for the purpose of displaying subjects for navigation, but they will be created through a governance process that can consider the politics involved separately from describing the subjects. This should make the subject classification terms more widely usable, allowing institutions and agencies who use it to build hierarchies for presentation and analysis that meet their own needs if these are different from those represented by the process responsible for the standard hierarchy. A more widely used classification scheme will have benefits for the information improvement envisaged by HEDIIP.

The next phase of HECoS will be about implementation and adoption, for example the creation of the governance processes detailed in the reports, moving HECoS up to proper 5-star linked data, help with migration from JACS to HECoS and so on. There’s a useful summary report on the HEDIIP site, and a spreadsheet of the coding system itself. There’s also still the development version Cetis used for consultation, which better represents its semantic webbiness but is non-definitive and temporary.