We've put an OWL version of the Dublin Core out on our web site, feel free to use it as is or copy and modify it.
http://ontologies.semanticarts.com/dublincore/dublincore.owl
In the act of doing this we recognized that there are so many different ways of doing this, there may never be a standard. A few quick notes on the design tradeoffs we made here:
First, it is initially tempting to have many of the tags in the Dublin Core be classes (Creator, Publisher, etc etc). But as you reflect on the way they are used and intended to be used, they are really properties. Properties of "document" or some generic class that covers the types of things intended to be covered by the Dublin Core (books, on line articles, music and the like).
So even if "creator" is a property, you'd probably like to have a class at the other end of the property. Maybe you'd like to have the property be "hasCreator" and the target object be a member of class "Creator." But that's not really going to work. Already the tag name is different, but there is a deeper problem. The recommended use is for Creators (and other people and organizations) to represent their names in the "LastName, FirstName" style. Of course this means that the names are strings, and that the property is a datatype property.
If our primary goal was Dublin Core compatibility, we would just make all the tags datatype properties, with a domain of document, and be pretty much done. And if that's what you want, just take the attached and strip out the rest.
For our purposes we were hoping on some future integration between the structured and unstructured world, and the all datatype property solution was limiting in this regard (there is very little node folding to be done in this style design for instance).
In many cases we would know the uri/urn of the entity in question (we would know an author's identity not just their name). We'd like to make it an object property, but in the end settled on this tradeoff: we'd make two subproperties of each of the dublin core properties where we would have identities (creator, contributor and publisher) one for their name and one a string representation of their id. As subproperties each would then infer and show up as "creator" or "contributor." We wanted to make the id version a subtype of an object property, but that just wasn't going to happen. We intend to have a simple rule convert the string id to a uri when we need to integrate.
For several of the other properties, if there was a document to document relationship (basedOn, versionOf, partOf etc) we created an object property with Document as domain and range.
We used the Dublin Core guideline for sub tags with periods, but I have a feeling we're going to regret that. I'll let you know.
Comments
Old but not that old!
I appreciate that this is an old blog post but it isn't that old and DCMI's "guideline for sub tags with periods" hasn't been around for a long, long while - like at least 5 years, probably much longer. So I have a significant concern that this work is based on a very old understanding of what DCMI is and its relationship to RDF. I suggest that you refer to
http://dublincore.org/documents/dcmi-terms/
for the appropriate properties and classes, and
http://dublincore.org/documents/dc-rdf/
for an overview of the relationship between DC metadata and RDF.
Best,
Andy.