Parsing the vocabulary for fun and frustration

Posted on Thu 01 August 2013 in misc

For various reasons I've spent a few hours today trying to parse the vocabulary into a nice, searchable database structure. Unfortunately, for a linked data effort that's two years old now and arguably one of the most important efforts out there, it's been an exercise in frustration.

OWL - oww, oww, oww

My first attempt was to work through the "`official OWL version of the terms <>`__" (per That quickly led me to filing a bug asking for the OWL to be served up as MIME type application/xml rather than text.html so that my browser would do a better job of rendering it. But that was a minor issue. As I worked through the OWL, I discovered that it was not at all in sync with the vocabulary as documented via the web site.

For example, looking at the OWL for datePublished, things look okay at first glance:

<!-- --><owl:DatatypeProperty rdf:about="">    <rdfs:label xml:lang="en">datePublished</rdfs:label>    <rdfs:comment xml:lang="en">Date of first broadcast/publication.</rdfs:comment>    <rdfs:range rdf:resource=""/>    <rdfs:domain>        <owl:Class>            <owl:unionOf rdf:parseType="Collection">                <rdf:Description rdf:about=""/>            </owl:unionOf>        </owl:Class>    </rdfs:domain></owl:DatatypeProperty>

But the first problem is that the range property is a lie. Per, the value is supposed to be restricted to (backed up by an RDF(S) assertion in the page itself.

In fact, this problem affects all of the range declarations in the OWL document. Everything has a range of "literal". Not good.


Next, I tried the RDF/XML format. Looking at again, we see:

<rdf:Description rdf:about=""> <rdf:type rdf:resource=""/>    <rdfs:label xml:lang="en">Date Published</rdfs:label>  <rdfs:comment xml:lang="en">Date of first broadcast/publication.</rdfs:comment>    <rdfs:domain rdf:resource=""/>  <rdfs:range rdf:resource=""/>    <rdfs:isDefinedBy rdf:resource=""/></rdf:Description>

Better, in that the range property is not literal, but instead of pointing to, it's pointing to That seems weird and concerning. In addition, working with this format quickly becomes difficult because you have to dereference assertions like the following to make sense of things:

<rdf:Description rdf:nodeID="node180s0ohklx169">    <rdf:type rdf:resource=""/></rdf:Description><rdf:Description rdf:nodeID="node180s0ohklx170">   <rdf:first rdf:resource=""/>    <rdf:rest rdf:nodeID="node180s0ohklx171"/></rdf:Description><rdf:Description rdf:nodeID="node180s0ohklx171">   <rdf:first rdf:resource=""/>   <rdf:rest rdf:resource=""/></rdf:Description><rdf:Description rdf:nodeID="node180s0ohklx169">    <owl:unionOf rdf:nodeID="node180s0ohklx170"/></rdf:Description><rdf:Description rdf:about="">   <rdfs:range rdf:nodeID="node180s0ohklx169"/>  <rdfs:isDefinedBy rdf:resource=""/></rdf:Description>

Insert Ain't nobody got time for that! meme image here, if you will...


Somewhat ironically, given the XML orientation of the semantic web world, the best option I've found so far ends up being the JSON representation of the schema. Here's our friend, again:

"datePublished": {      "comment": "Date of first broadcast/publication.",       "comment_plain": "Date of first broadcast/publication.",       "domains": [        "CreativeWork"      ],       "id": "datePublished",       "label": "Date Published",       "ranges": [        "Date"      ]    },

Very easy to work with, and the data seems to be accurate! So far I've noticed only a few quirks:

  1. datatypes and properties have valid comment properties, but types only have an empty string. Of course I could harvest those myself for each type by hitting the corresponding page, but I shouldn't have to do that.
  2. datatypes and types have url properties, but properties do not. It's straightforward to create them yourself by appending the id property to "", but consistency would be nice.


I would recommend anyone looking to do something meaningful with the vocabulary currently to start with the JSON format; you will likely be much more efficient than if you wade into one of the other formats and start dealing with multiple namespaces, etc before ultimately realizing that the format you're working with is deeply flawed or out of sync... And I've given myself the task of offering up a merge request or two to Git repository where the scrapers that generate these formats live, so hopefully these problems will be resolved sooner rather than later :-)