- 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
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 UTC