- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Thu, 25 Nov 2004 10:38:42 +0100
- To: Charles McCathieNevile <charles@w3.org>
- Cc: Giovanni Tummarello <giovanni@wup.it>, www-rdf-interest@w3.org
Yes to everything ;-) Certainly for people coming to RDF from XML with preconceptions of how to solve problems from that space, RDF/XML is a big problem. The cost of the syntax looms large long before the developer sees the potential benefits of the model. But RDF/XML does work pretty nicely for machine-machine comms, is in the specs and isn't going to go away any time soon. re. XML tool compatibility with RDF/XML, yep it is a problem, but don't overestimate tool standardization within XML. Both SAX and DOM seem to be sidestepped by many developers these days, with pull parsers and tree-based APIs that exploit individual programming language idioms (Did I see a gay & lesbian version of DOM the other day? Maybe I dreamt it.) There's something of a mismatch between the goals of XML Schema and RDF serializations, but many XML folks seem to be tending towards alternatives like Relax NG anyhow. XSLT is a big sticking point, but even then I suspect there's a danger of overstating the problems. Given that James & Ian's have a C# RDF/XML parser [1] actually based around XSLT there may well be avenues forward that haven't yet been explored. I personally really like XSLT, but not everyone sees things the same way (e.g. [2]). Whatever, I don't think there's actually such a rigid tool set to conflict with RDF/XML, there are probably points where more interop can take place (like the graph/XPath stuff) given enough imagination and time... The tool that XML developers really, desperately seem to want to cling on to is the text editor, and on that front perhaps Turtle is the best solution. Under what circumstances are XML developers likely to benefit from RDF? Ok, moving from a tree to a graph has obvious benefits in the Web environment. Inference and the logic of ontologies is pretty handy too. Maybe the most immediate benefit is being able to mix together data from different domains (or unambiguously extend within a domain). How much of these can be done without committing to RDF/XML? Most, if not all. But if a developer already has data in an XML syntax, what are they to do? I suspect there's still plenty of work that can be done (or broadcast more, if it's already been done) in terms of using domain-specific XML languages in RDF systems. Assume people don't want to add rdf:parseType="Resource" every few elements (a fairly safe assumption, IMHO). Domain-specific XML is usually relatively easy to consume, but producing domain-specific material can be a pain. I think that pain could probably be eased. So can't we perhaps leave commitment to an RDF syntax until after the model has been introduced? (btw - has anyone done a serializer that takes an RDF model together with an XML Schema, filters down the statements to those which correspond to names in the schema, then pumps out data that conforms to the schema?) I guess what I'm suggesting is that converting XML data to RDF is a darn sight easier than converting XML developers to RDF. Once a decent number of RDF-based systems are online (and joined together) the utility should be obvious. Until we have widespread model envy, integration through interfacing is probably the easiest path. This kind of skirts around Chaals' excellent point, that they just want to know what THE syntax is. Ok, tell them it's their current syntax. So is promoting RDF+XML a lost cause? Definitely maybe. I certainly don't think *using* it is a lost cause (as long as you don't look at it too often). None of the alternate XML syntaxes seem to have gained significant traction. For promotional purposes, where generalized syntax must be addressed then Turtle almost certainly is the answer. But like everyone's already said, it's the model that counts. Cheers, Danny. [1] http://www.semanticplanet.com/2004/10/announcingSemanticPlanetsRDFLibAndCarp [2] http://www.martinfowler.com/bliki/MovingAwayFromXslt.html -- http://dannyayers.com
Received on Thursday, 25 November 2004 09:38:43 UTC