Originally published on the Consensus Enterprises blog.

As a content management framework, Drupal provides strong support for its taxonomical subsystem for classifying data. It would be great if such data could be exposed via the Simple Knowledge Organization System (SKOS) standard for publishing vocabularies as linked data. As Drupal becomes used more and more as a back-end data store (due to features such as built-in support for JSON:API), presenting this data in standard ways becomes especially important.

So is this actually possible now? If not, what remains to be done?

Drupal’s history

First, let’s explore some of Drupal core’s history as it relates to the Semantic Web and Web services formats, also useful for future reference. This is basically the backstory that makes all of this possible.

REST support was added to Views

This was implemented in the (now closed) issues:

• Add a REST export display plugin and serializer integration
• Convert the taxonomy listing and feed at /taxonomy/term/%term to Views

Non-Schema.org namespace mappings were removed (including contrib’s UI support) in Drupal 8

Here’s the change notice:

• Use schema.org types and properties in RDF mappings

And a follow-up issue requesting support for additional namespaces:

• Allow usage of any namespace in RDF mapping UI

The community chose to replace JSON-LD with HAL in Drupal 8

Here’s an article with the details:

• Decoupling Drupal 8 Core: Web Services in Core and the Serialization Module

Multiple Components

As this is really a two-part issue, adding machine-readable metadata and then making machine-readable data available, I’ll split the discussion into two sections.

Adding machine-readable metadata

While there’s an RDF UI module that enables one to specify mappings between Drupal entities and their fields with RDF types and properties, it only supports Schema.org via RDFa (not JSON-LD).

As explained very well in Create SEO Juice From JSON LD Structured Data in Drupal, a better solution is to use the framework provided by the Metatag module (used by modules such as AGLS Metadata). The article introduces the Schema.org Metatag module, which uses the Metatag UI to allow users to map Drupal data to Schema.org, and exposes it via JSON-LD.

So one solution would be to:

1. Clone Schema.org Metatag, calling the new module SKOS Metatag.
2. Replace all of the Schema.org specifics with SKOS.
3. Rejoice.

But after taking some time to process all of the above information, I believe we should be able to use the knowledge of the vocabulary hierarchy to add the SKOS metadata. We probably don’t need any admin UI at all for configuring mappings.

Assuming that’s true, we can instead create a SKOS module that doesn’t depend on Metatag, but Metatag may still be useful given that it already supports Views.

Making the machine-readable data available

Exposing the site’s data can be done best though Views. I wouldn’t recommend doing this any other way, e.g. accessing nodes (Drupal-speak for records) directly, or through any default taxonomy links for listing all of a vocabulary’s terms. (These actually are Views, but their default set-ups are missing configuration.) A good recipe for getting this up & running, for both the list and individual items, is available at Your First RESTful View in Drupal 8.

To actually access the data from elsewhere, you need to be aware of the recent API change To access REST export views, one now MUST specify a ?_format=… query string, which explains why some consumers broke.

The JSON-LD format is, however, not supported in Core by default. There is some code in a couple of sandboxes, which may or may not work, that will need to be ported to the official module, brought up-to-date, and have a release (ideally stable) cut. See the issue JSON-LD REST Services: Port to Drupal 8 for details.

Now, the Metatag solution I proposed in the previous section may work with Views natively, already exposing data as JSON-LD. If that’s the case, this JSON-LD port may not be necessary, but this remains to be seen. Also, accessing the records directly (without Views) may work as well, but this also remains to be seen after that solution is developed.

Conclusion

Clearly, there’s more work to be done. While the ultimate goal hasn’t been achieved yet, at least we have a couple of paths forward.

That’s as far as I got with pure research. Due to priorities shifting on the client project, I didn’t get a chance to learn more by reviewing the code and testing it to see what does and doesn’t work, which would be the next logical step.

If you’ve got a project that could make use of any of this, please reach out. We’d love to help move this technology further along and get it implemented.

References

General information

• What is the relationship between RDF, RDFa, Microformats and Microdata
• What is the difference between Microdata, RDFa & JSON-LD?

Contributed modules that probably aren’t helpful (but could be)

• Structured Data (JSON+LD Rich Snippets)
• JSON LD Schema API
• WissKI
• Ontology (OWL)
• DCAT
• RDF entity
• Drupal2RDF (This is brand new, but at the time of this writing, there’s not enough info/code yet to figure out what it’s trying to do.)
• There’s a module called Smart Glossary which allows you to have multilingual SKOS Thesauri on your Drupal site, but I don’t think it’s useful at all as it’s part of a suite of modules maintained by PoolParty, where they expect you to use their data store:
  • Smart Glossary
  • PoolParty Taxonomy Manager for Drupal
  • Semantic Connector
  • PowerTagging

Questions about importing SKOS data (not exporting it)

• Options for SKOS integration in Drupal 8
• How can I work with SKOS data?