W3C home > Mailing lists > Public > public-esw@w3.org > June 2003

Explaining why we use RDF instead of just XML

From: Dan Brickley <danbri@w3.org>
Date: Wed, 25 Jun 2003 05:48:32 -0400
To: www-rdf-interest@w3.org
Cc: public-esw@w3.org
Message-ID: <20030625094831.GF26372@tux.w3.org>

RDF IG, (copying SWAD-Europe list)

I've just written a few comments in a weblog, 
http://www.pmbrowser.info/hublog/archives/000258.html that I thought I'd 
archive here too, see if they make sense to folks. I was trying to explain
a bit about why RDF might make sense for someone considering the use of 
XML for a vocabulary. I think maye I just restated what Danny said there at 
greater length...

[[
One way to think about this: the Resource Description Framework (RDF) 
is a family of XML applications who agree to make a certain tradeoff 
for the sake of cross-compatibility. In exchange for accepting a number 
of constraints on the way they use XML to write down claims about the world, 
they gain the ability to have their data freely mixed with that of other 
RDF applications.

Since many descriptive problems are inter-related, this is an attractive offer, 
even if the XML syntax is a little daunting. MusicBrainz can focus on describing 
music, RSS 1.0 on describing news channels, FOAF on describing people, 
Dublin Core on describing documents, RdfGeo on places and maps, RdfCal on 
describing events and meetings, Wordnet on classifying things using nouns, 
ChefMoz on restaurants, and so on.

Yet because they all bought into the RDF framework, any RDF document can draw 
on any of these 'vocabularies'. So an RSS feed could contain markup describing 
the people and places and music associated with a concert; a calendar entry 
could contain information about it's location and expected attendees, a 
restaurant review could use FOAF to describe the reviewer, or a FOAF file 
could use Dublin Core to describe the documents written by its author, as 
well as homepages and other information about those authors.

So, for any particular application, you could do it in standalone XML. RDF 
is designed for areas where there is a likely pay-off from overlaps and 
data merging, ie. the messy world we live in where things aren't so easily 
parceled up into discrete jobs.

But it is a tradeoff. Adopting RDF means that you just can't make up your 
XML tagging structure at random, but you have to live by the 'encoding' rules 
expected of all RDF applications.
This is so that software written this year can have some hope of doing useful 
things with vocabularies invented next year: an unpredictable 'tag soup' 
of arbitrary mixed XML is hard to process. RDF imposes constraints so that 
all RDF-flavoured XML is in broadly the same style (for example, ordering 
of tags is usually insignificant to what those tags tell the world). 
Those constraints take time to learn and understand and explain, and so 
adopting RDF isn't without its costs.

And so the more of us who use RDF, the happier the cost/benefit tradeoff gets, 
since using RDF brings us into a larger and larger family of inter-mixable data.

Does this make any sense? 
]]
Received on Wednesday, 25 June 2003 05:48:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:12 GMT