For the work we’ve been doing on semantic description of courses we needed a platform for creating and editing instance data flexibly and easily. We looked at callimachus and Semantic MediaWiki; in the end we went with the latter because of JAVA version incompatibility problems with the other, but it has been a bit of a struggle. I’ve used WordPress for publishing information about resources on a couple of projects, for Cetis publications and for learning resources, and have been very happy with it. WordPress handles the general task of publishing stuff on the web really well, it is easily extensible through plugins and themes, I have nearly always found plugins that allow me to do what I want and themes that with a little customization allow me to present the information how I want. As a piece of open source software it is used on a massive scale (about a quarter of all web domains use it) and has the development effort and user support to match. For the previous projects my approach was to have a post for each resource I wanted to describe and to set the title, publication date and author to be those for the resource, I used the main body of the post for a description and used tags and categories for classification, e.g. by topic or resource type; other metadata could be added using WordPress’s Custom Fields, more or less as free text name-value pairs. While I had modified themes so that the semantics of some of this information was marked up with microdata or RDFa embedded in the HTML, I was aware that WordPress allowed for more than I was doing.
The possibility of using WordPress for creating and publishing semantic data hinges on two capabilities that I hadn’t used before: firstly the ability to create custom post types so that for each resource type there can be a corresponding post type; secondly the ability to create custom metadata fields that go beyond free text. I used these in conjunction with a theme which is a child theme of the current default, TwentyFifteen, which sets up the required custom types and displays them. Because I am familiar with it and it is quite general purpose, I chose the schema.org ontology to implement, but I think the ideas in this post would be applicable to any RDF vocabulary. When creating examples I had in mind a dataset describing the books that I own and the authors I am interested in.
I started by using a plugin, Custom Post Type UI, to create the post types I wanted but eventually was doing enough in php as a theme extensions (see below) that it made sense just to add a function to create the the post types. This drops the dependency on the plugin (though it’s a good one) and means the theme works from the outset without requiring custom types to be set up manually.
add_action( 'init', 'create_creativework_type' );
function create_creativework_type() {
register_post_type( 'creativework',
array(
'labels' => array(
'name' => __( 'Creative Works' ),
'singular_name' => __( 'Creative Work' )
),
'public' => true,
'has_archive' => true,
'rewrite' => array('slug' => 'creativework'),
'supports' => array('title', 'thumbnail', 'revisions' )
)
);
}
The key call here is to the WP function register_post_type() which is used to create a post type with the same name as the schema.org resource type / class; so I have one of these for each of the schema.org types I use (so far Thing, CreativeWork, Book and Person). This is hooked into the WordPress init process so it is done by the time you need those post types.
I do use a plugin to help create the custom metadata fields for every property except the name property (for which I use the title of the post). Meta Box extends the WordPress API with some functions that make creating metadata fields in php much easier. These metadata fields can be tailored for particular data types, e.g. text, dates, numbers, urls and, crucially, links to other posts. That last one gives you what you need for to create relationships between the resources you describe in WordPress, which can expressed as triples. Several of these custom fields can be grouped together into a “meta box” and attached as a group to specific post types so that they are displayed when editing posts of those types. Here’s what declaring a custom metadata field for the author relationship between a CreativeWork and a Person looks like with MetaBox (for simplicity I’ve omitted the code I have for declaring the other properties of a Creative Work and some of the optional parameters). I’m using the author property as an example because a repeatable link to another resource is about as complicated a property as you get.
function semwp_register_creativework_meta_boxes( $meta_boxes )
{
$prefix = 'semwp_creativework_';
// 1st meta box
$meta_boxes[] = array(
'id' => 'main_creativework_info',
'title' => __( 'Main properties of a schema.org Creative Work', 'semwp_creativework_' ),
// attach this box to the following post types
'post_types' => array('creativework', 'book' ),
// List of meta fields
'fields' => array(
// Author
// Link to posts of type Person.
array(
'name' => __( 'Author (person)', 'semwp_creativework_' ),
'id' => "{$prefix}authors",
'type' => 'post',
'post_type' => 'person',
'placeholder' => __( 'Select an Item', 'semwp_creativework_' ),
// set clone to true for repeatable fields
'clone' => true
),
),
);
return $meta_boxes;
}
What this gives when editing a post of type book is this:
WordPress uses a series of nested templates to display content, which are defined in the theme and can either be specific to a post type or generic, the generic ones being used as a fall back if a more specific one does not exist. As I mentioned I use a child theme of TwentyFifteen which means that I only have to include those files that I change from the parent. To display the main content of posts of type book I need a file called content-book.php (the rest of the page is common to all types of post), which looks like this
<article resource="?<?php the_ID() ; ?>#id" id="?<?php the_ID(); ?>" <?php post_class(); ?> vocab="http://schema.org/" typeof="Book">
<header class="entry-header">
<?php
if ( is_single() ) :
the_title( '
<h1 class="entry-title" property="name">', '<;/h1>' );
else :
the_title( sprintf( '
<h2 class="entry-title"><;a href="%s" rel="bookmark">', esc_url( get_permalink() ) ), '</a></h2>
;' );
endif;
?>
</header>
<div class="entry-content">
<?php semwp_print_creativework_author(); ?>
<?php semwp_print_book_bookEdition(); ?>
<?php semwp_print_book_numberOfPages(); ?>
<?php semwp_print_book_isbn(); ?>
<?php semwp_print_book_illustrator(); ?>
<?php semwp_print_creativework_datePublished(); ?>
<?php semwp_print_book_bookFormat(); ?>
<?php semwp_print_creativework_sameAs(); ?></div>
<footer class="entry-footer">
<?php twentyfifteen_entry_meta(); ?>
<?php edit_post_link( __( 'Edit', 'twentyfifteen' ), '<span class="edit-link">', '</span>' ); ?>
<?php semwp_print_extract_rdf_links(); ?>
</footer>
</article>
Note the RDFa in some of the html tags, for example the <article> tag includes
resource= [url]#id vocab="http://schema.org/" typeof="Book"
and the title is output in an <h1> tag with the
property="name"
attribute. Exposing semantic data as RDFa is one (good) thing, but what about other formats? A useful web service called RDF Translator helps here. It has an API which allowed me to put a link at the foot of each resource page to the semantic data from that page in formats such as RDF/XML, N3 and JSON-LD; it’s quite not what you would want for fully fledged semantic data publishing but it does show the different views of the data that can be extracted from what is published.
Also note that most of the content is printed through calls to php functions that I defined for each property, semwp_print_creativework_author() looks like this (again a repeatable link to another resource is about as complex as it gets:
function semwp_print_alink($id) {
if (get_the_title($id)) //it's a object with a title
{
echo sprintf('<a property="url" href="%s"><span property="name">%s</span></a>', esc_url(get_permalink($id)), get_the_title($id) );
}
else //treat it as a url
{
echo sprintf('<a href="%s">%s</a>', esc_url($id), $id );
}
}
function semwp_print_creativework_author()
{
if ( rwmb_meta( 'semwp_creativework_authors' ) )
{
echo '
By: ';
$authors = rwmb_meta( 'semwp_creativework_authors' );
foreach ( $authors as $author )
{
echo '<span property="author" typeof="Person">';
semwp_print_alink($author);
echo '</span>';
}
echo '
';
}
}
So in summary, for each resource type I have two files of php/html code: one which sets up a custom post type, custom metadata fields for the properties of that type (and any other types which inherit them) and includes some functions that facilitate the output of instance data as HTML with RDFa; and another file which is the WordPress template for presenting that data. Apart from a few generally useful functions related to output as HTML and modifications to other theme files (mostly to remove embedded data which I found distracting) that’s all that is required.
The result looks like this:
And here’s the N3 rendering of the data in that page as converted by RDF Translator:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfa: <http://www.w3.org/ns/rdfa#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix schema: <http://schema.org/> . @prefix xml: <http://www.w3.org/XML/1998/namespace> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <http://www.pjjk.net/semanticwp/book/the-day-of-the-triffids> rdfa:usesVocabulary schema: . <http://www.pjjk.net/semanticwp/book/the-day-of-the-triffids?36#id> a schema:Book ; schema:author [ a schema:Person ; schema:name "John Wyndham"@en-gb ; schema:url <http://www.pjjk.net/semanticwp/person/john-wyndham> ] ; schema:bookEdition "Popular penguins (2011)"@en-gb ; schema:bookFormat ""@en-gb ; schema:datePublished "2011-09-01"^^xsd:date ; schema:illustrator [ a schema:Person ; schema:name "John Griffiths"@en-gb ; schema:url <http://www.pjjk.net/semanticwp/person/john-griffiths> ] ; schema:isbn "0143566539"@en-gb ; schema:name "The day of the triffids"@en-gb ; schema:numberOfPages 256 ; schema:sameAs "http://www.amazon.co.uk/Day-Triffids-Popular-Penguins/dp/0143566539/"@en-gb, "https://books.google.co.uk/books?id=zlqAZwEACAAJ"@en-gb .
Further work: Ideas and a Problem
There’s a ton of other stuff that I can think of that could be done with this, from the simple, e.g. extend the range of types supported, to the challenging, e.g. exploring ways of importing data or facilitating / automating the creation of new post types from known ontologies, output in other formats, providing a SPARQL end point &c &c… Also, I suspect that much of what I have implemented in a theme would be better done as a plugin.
There is one big problem that I only vaguely see a way around, and that is illustrated above in the screenshot of the editing interface for the ‘about’ property. The schema.org/about property has an expected type of schema.org/Thing; schema.org types are hierarchical, which means the value for about can be a Thing or any subtype of Thing (which is to say of any type). This sort of thing isn’t unique to schema.org. However, the MetaBox plugin I use will only allow links to be made to posts of one specific type, and I suspect that reflects something about how WordPress organises posts of different custom types. I don’t think there is any way of asking it to show posts from a range of different types and I don’t think there is any way of saying that posts of type person are also of type thing and so on. In practice this means that at the moment I can only enter data that shows books as being about unspecific Things; I cannot, for example, say that a biography is a book about a Person. I can only see clunky ways around this.
[Aside: the big consumers of schema data (Google, Bing, Yahoo, Yandex) will also permit text values for most properties and try to make what sense of it they can, so you could say that for any property either a string literal or a link to another resource should be permitted. This, I think, is a peculiarity of schema.org. The screenshot above of the data input form shows that the about field is repeated to provide the option of a text-only value, an approach hinting at one of the clunky unscalable solutions to the general problem described above.]
What next? I might set a student project around addressing some of these extensions. If you know a way around the selecting different type problem please do drop me a line. Other than that I can see myself extending this work slowly if it proves useful for other stuff, like creating examples of pages with schema.org or LRMI data in them. If anyone is really interested in the source code I could put it on github.