- From: Benjamin Nowack <bnowack@appmosphere.com>
- Date: Thu, 11 Jan 2007 13:10:31 +0100
- To: W3C SWEO IG <public-sweo-ig@w3.org>
OK, this would probably fit better in SWD, but it's related to SWEO as well. Just some food for more thought: One of the (IMO) most destructive SemWeb misconceptions is the "RDF = RDF/XML" one. I guess we all agree that one of SWEO's objectives should be to provide (links to) easy-to-grok material for SemWeb newbies that make the distinction clear. However, if want to go beyond these simple education tasks, we have to reach out and get more people of the larger Web dev community involved. I personally don't have a problem with RDF/XML, and I always sigh when the "RDF/XML sucks" perma-thread reappears every other month, but fact is: * there *is* a perma-thread * it's sucessfully used by SemWeb opponents (and proponents as well, for that matter) to hinder community growth * even many RDFers don't like it * it *is* the recommended syntax * we are not in a position to make everyone switch to e.g. turtle; embedded RDF approaches don't work for all use cases, and generally, an XML-based syntax makes a lot of sense * even the most simple SemWeb "hello world" will include some serialization, any useful *2nd step* will include parsing/consuming * developers didn't forget the pain and frustration when they gave up on trying to write an RSS 1.0 parser So, assuming our wake-up efforts are a huge success and everyone gets interested in SemWeb development, how can we make sure that this 2nd step mentioned above doesn't become a showstopper? Of course, turtle is one way, but I think we'd be significantly more successful if we could offer an RDF/XML subset that's easy to write, and (more importantly) easy to parse with existing XML tools. And I believe the main benefit wouldn't be a technical, but a marketing/motivation one. When I wrote my RDF/XML parser in PHP using libxml, I managed to have a basic version running in less than an afternoon, but it took me months before it covered all the different optional features in the spec. I'm not sure what my concrete proposal for SWEO would be, I'd at least like to see * an as-short-as-possible "essential RDF syntax" document, that, after reading it once, allows developers to write valid RDF/XML (and turtle?) documents. What I'm dreaming of is: * a more spec-like "RDF/XML Lite", that is a valid subset of RDF/XML, XSLT and XML parser-friendly, and that allows average coders to easily create conforming parsers and/or converters * we manage to persuade toolkit developers to offer this serialization as an output option * we manage to persuade app/extension/plugin developers to update their RDF/XML export formats * alternatively we manage to deploy some simple rdfxml2rdfxmllite scripts I think this would be doable, it's a little bit like DOAP, or the foafnet effort from a few years back, just more general. I think it would be easy to get consensus on the features this RDF/XML subset should (not) have, Leo even started a wiki page[1] some time ago. What's missing is just someone to collect requirements, write it up properly and some authority to spread the word. Congrats, you reached the end of this post. Fell free to tell me this is entirely off-topic ;) Ben [1] http://esw.w3.org/topic/SimpleRdfXml
Received on Thursday, 11 January 2007 12:12:00 UTC