Y'know, this essay illuminates a lot of why I will only use RDF when dragged kicking and screaming in front of a directed graph.

I learned to make tolerable ERDs in a few weeks. The design principles were pretty clear, and where they weren't clear, the tradeoffs were easily explainable.

I learned to write tolerable SGML DTDs (basic ones, anyway -- not so much the modular, INCLUDEd ones) in a few months. The design principles were pretty clear, and where they weren't clear, the tradeoffs were evident to an eye used to coping with instances.

The design principles for an RDF vocabulary -- are there any? I've once or twice, to my sorrow, been in a room where an RDF vocabulary was being designed. All discussions devolved into class-property-label disputes, weird attempts to turn "what the model is REALLY saying" into English sentences whose syntax invariably ended up horribly tortured and which did not clarify the issue at hand in the slightest, and confusion about bags or lists or links or whatever.

(And RDF people get all squinchy if you don't do these things correctly, even when they can't coherently explain the design principles or the tradeoffs. That's the worst part.)

I've never written a topic map, but if I had to, I expect I could figure out how in a few weeks (what with all my wizard librarian-fu). I doubt I'll ever figure out how to put together an RDF ontology. Possibly that should bother me, but somehow... I'm not bothered.

The thing about working out rdf models, if you already know ER modeling, is just to do ER modeling at the conceptual modeling level. RDF can be thought of as an ultra-normalized relational database, modulo a few quirks, of course. It's usually pretty straightforward to go from a high level ER diagram to an rdf design. An advantage is that, with rdf, you don't have to create new tables or rows for rare cases. The rdf data set can be like a set of sparse tables.

You can also do some informal object modeling as your starting point.

Just like ER designs, there are usually several ways to model something in rdf, and usually, none of them is the "one right way".

You also don't have to use every feature of rdf to do most of your work, anymore than you have to use every feature of a relational database. Use a nice subset and forget the rest for some other time.

Norm, I've had to do exactly this kind of modelling of types on phone numbers and email addresses, both personally and in my corporate work.

The solution I used is to exploit the fact that tel: URIs and mailto: URIs are the only acceptable ranges of foaf:phone and foaf:mbox, so we can actually type the objects.

My blog post on this topic is here.

So, rather than making subproperties of foaf:phone, we can just use foaf:phone and assert that, say,

<tel:+1-234-567-8900> rdf:type EXT:cellPhone .

It's a modelling choice, but I quite like it.

I think you're missing what's really different here, Dorothea. What makes the modelling issues in this example interesting has relatively little to do with the technology. My first design, the one that was just for me and didn't use any terms in any other vocabulary, took about 10 minutes to write and followed design principles that I've learned from years of work on XML vocabularies. Instantiating that model in RDF was easy and straightforward.

But unlike database design and XML schema design, which are designs that live in relative isolation, designing an RDF ontology (or at least this ontology) is about cooperating in a web-scale information space. Just as my pages on the web benfit from the network effect, the terms in my RDF vocabulary can benefit from that effect as well.

I want people to reuse them, I want them to spread, and I want to add value to the network by reusing terms from other vocabularies. My struggles with the design are as much about my attempts to understand what it means to design an ontology that will be used on that scale as they are about the details of this particular model.

As for discussions that devolve into class-property-label disuptes, if you haven't seen the same thing in designing XML vocabularies (elements or attributes?, element and attribute names!, mixed content or element content?, wrapper element or no wrapper element?, etc.), tag along with your favorite XML consultant sometime :-)

(Sound of palm striking forehead)

Thanks, Rich. That's an interesting idea.

While my initial response was that I liked the xml version of contacts, I did empathize with Dorotheas comments. Your response made (at least part of) your reasoning clear. designing an RDF ontology (or at least this ontology) is about cooperating in a web-scale information space could be seen as taking xml another step forward. I'd be interested in hearing more from you on this please Norm.

Also of interest to me was another piece of rationale for wanting the rdf, that you don't expand on.

I want to be able to combine the contacts in my address book with other data sources in ways that RDF makes easy and I want to be able to do inference over contacts again.

Which rdf tools make it easier than merging and querying the XML please?

regards DaveP

You have left it as an open question but why did you not consider vCard from the beginning?

I think it might not be very RDF-friendly, because it was conceived with XML in mind, but it facilitates mapping existing contacts information to the RDF space. For instance my RDF profile, which is rendered as HTML with ReDeFer at my homepage

.

Re Roberto: I'm assuming you're referring to the vCard-in-RDF spec that's lying around on the W3C's servers somewhere.

The reason not to use it… it's awful. Avoiding it like the plague is the best idea.