- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Tue, 7 Sep 2010 07:54:29 +0100
- To: Harry Halpin <hhalpin@w3.org>
- Cc: "RDB2RDF WG" <public-rdb2rdf-wg@w3.org>
On 29 Aug 2010, at 23:12, Harry Halpin wrote: > 1) What is the advantage of storing the mapping as RDF? > > One answer could be that you could SPARQL the RDB2RDF mapping and > store > them at SPARQL endpoints, but I can't think of any reason for doing > that > really. Any other reasons? Extensibility for free. Documenting mappings. We get URIs for the components of the mapping file for free, so annotating mappings out-of- band becomes easy. Community expectations. > 2) What is the advantage of storing the mapping as XML? > > Developers off the street understand XML much more so than RDF, and > the > tooling is much more mature. But there aren't *many* database > developers > out there. Also, XML Schema allows us to easily validate and find > broken > mappings. You overstate the value of XML validation. There are three levels of validation in XML. First, well-formedness; no difference to Turtle here. Second, XML Schema validation; this is where XML has an advantage over Turtle. Third, all the other syntactic and semantic constraints that cannot be expressed in an XML Schema; again, no difference to Turtle. So XML Schema really just helps with a certain class of mapping errors. The main reason pro XML for me is that your text editor already comes with syntax highlighting and similar bells and whistles for XML. If you live in Eclipse or other developer-centric environments, then you get a decent structured XML editor out of the box. > The real key I think would be the audience: the audience will likely > be > database maintainers who know a *little* about RDF, think Linked > Data/RDF > is interesting or have theiir boss tell them to export it, and want > to do > so quickly as possible. > > Do we expect this audience to author these config files *by hand*? Sort of. No one will write these files from scratch. They will use a tool that auto-generates a skeleton file, and then go in to customize that file. This is what we have today and this process works well. The auto-generation of the skeleton has the handy side-effect of providing a catalog of all the tables and columns in the database schema. Writing a mapping file without that pre-generated catalog is a *major* pain, no one will do that for a medium-sized schema, even in the nicest possible syntax. But yeah, as you and Eric said, we of course hope for GUI tools, but they could take a while to emerge, so the syntax must afford eyeball- reading and hand-customizing of the mapping files. Best, Richard
Received on Tuesday, 7 September 2010 06:55:05 UTC