0 So, I've been working lately on building a plugin for Omeka to report data in it as Linked Open Data. One iffiness I encountered was how to create fields that could act as proper Linked Open Data fields that actually connect to other things. It seemed like using Omeka's Element Set structure would make sense, so that's where I went. And then things got nutty and I went to town.

0 The basic idea seemed straightforward enough. Create a new Element Set and its Elements to handle URIs of Linked Data. After a dead-end or two caused by my utter fail of experience building databases, I realized that I needed to create a new little table to go along with each Element, called ElementRdf. This table lets me shove in the relevant rdf info about an Element: it's URI, domain and range, etc.

0 During this little learning experience, I realized that, when in doubt, do what Jim Safley and the rest of the Omeka team did. I'm learning lots from following along their code as best I can. In this case, the big one is the Dublin Core Extended plugin, which adds in the Elements for refined DC. There was a neat thing there -- to install it all, there's an array of all the new Elements that need to come in, and the install script parses it and creates the Elements according to the data.

0 Hmmm. An array, you say? This got some happy thoughts rolling, because setting up an array like that made a lot of sense to simplify operations. Plus, I was concerned with adding in Elements that would serve the role of predicates in RDF assertions. PlusPlus, ARC has a data structure that represents RDF graphs as an array. Possibilities? Hell yeah.

0 So I built up a basic script that reads an ARC array representing an RDF graph, looks for things of rdf:type Property or the various OWL properties, and turns those into Elements for an Element Set. The upshot is that, with a few fine details to negotiate on a case-by-case basis, I'm pushing Semantic Web vocabularies into Omeka Element Sets via just a script and basically the same template for the plugin. The Element Set plugins will work with LinkedOpenOmeka if it's there (at least, when it's really released!), or just pop in independently.

0So, here's a quck run-down of the Element Sets that I've got right now. More, especially the University Ontology that I've been hammering away at for a long time, which tries to link up AIISO and SIOC, will be coming along soon. Any suggestions to add are very welcome.

AIISO

The Academic Institution Internal Structure Ontology from Talis. Any universities out there want to redo their web sites with a new app? Omeka with this Element Set might work.

BIBO

The Bibliography Ontology from Bruce D'Arcus and Fred Gaisson. This one seems like a powerful natural fit for Omeka -- it includes a really powerful list of terms for bibliographic info.

CDWA-Lite

Categories for the Description of Works of Art I confess that I'm not as familiar with this ontology as I'd like to be. Richard Urban produced an OWL expression of it, and I'm grateful for it, and for pointing me toward it.

DOAP

The Description Of A Project Ontology.

FOAF

The Friend Of A Friend Ontology. Okay, it's designed with modern people in mind, with email addresses and web pages and all, but ya can't do without it.

SIOC

The Semantically Interlinked Online Communities Ontology. Let's get meta. If you are putting together a web site that's a collection of info about web sites, this is the way to go.

Values and External Links

0I haven't done anything yet with templating the input forms, so everything gets one big text area regardless of whether the value should properly be a URI or a string of text or a date. But, if you're using the Linked Open Omeka plugin, it will check if the value is just a URI and treat it accordingly. So, you can add a link to any other URI just by entering it into the form.

Internal Links

0Again if using Linked Open Omeka, internal links can be a little confusing until you get the hang of them. That's because there are some distinctions between URIs that need to be there to keep the data consistent. They seem weird at first glance, but make sense with some examples. The game is to keep three things distinct: 1) An Item in Omeka, 2) the web page that displays that item, and 3) the thing that the Item is about. Linked Open Omeka makes different URIs for each.

0First off, an Item vs. its web page. Think of the Item as being an abstract concept, whereas the web page is the thing you are looking at. The web page is a bunch of HTML generated by one of many different themes in Omeka. Chanage the theme, and the web page completely changes. The Item, however, remains the same. Usually, you don't need to think about the distinction, but when aiming for linked data, they need to stay separate. So, the URI for a web page is what you generally see. It follow a pattern something like http://youromeka.org/items/show/1 for the first item -- or rather, the web page for the first item -- in Omeka. For the Item itself, Linked Open Omeka gives it a URI like http://youromeka.org/resource/items/show/1.

0Next, is the distinction between an Item and the thing that it is about. The distinction makes sense when you look at an example. Let's say that you are creating an Item about the Mona Lisa. You created that Item in Omeka. Leonardo DaVinci created the Mona Lisa. Linked Open Omeka gives a URI like http://youromeka.org/resource/items/show/1/object to the object itself. So, most of the time, an internal link using one of the Element Sets should go to the URI of the object itself.

0As always, lots of work still to do. But I'm really excited about this. The more ways we have to describe something the better, and I hope that this helps make Omeka more descriptively powerful. If this can also turn into Linked Open Data, well, I think we'll really be cooking with gas.

0Raw Data Now