Jeni's Musings

“You can call this description a RDF schema or conceptual model or ontology, depending on how impressive you want to sound”

And if you want to sound really, like, old school(!) you can refer to it as plain old entity-relationship modelling as really thats all it is. My current view is that designing RDF vocabularies is like E-R modelling, only without that need to eventually make the model fit into a physical database schema. Decide on the things, properties and their relationships and you’re done.

I’ve been using the “Define a subset of RDF/XML for your application” approach quite successfully for the past 6 months or so on a client project. I’ve been creating an RDF vocabulary that the client is shipping to us as XML documents. The RDF profile is validated with XML Schema as a first pass. This provides the up-front validation that you get with XML, but the content is entirely valid RDF/XML too, so we can just throw it into a triple store if it passes validation. Its works really well.

With this approach there’s also suprisingly little RDF/XML syntax that creeps through into your XML vocabulary. For us this has amounted to:

rdf:about, rdf:resource — which are easy to grok from a “primary key” & “foreign key” standpoint

rdf:parseType=”Collection” — for lists of stuff (we’ve avoided Seq, Bag, etc)

rdf:parseType=”Literal” — for XML literals. A bit funky, but preferable to CDATA.

Other than that we use namespaces everywhere, xml:base to shorten URIs whereever possible, and avoid using rdf:RDF as the root element of the document.

I’ll try and find the time to write this up better, but thought I’d leave a comment here to begin with!