- From: Eric van der Vlist <vdv@dyomedea.com>
- Date: Thu, 31 Aug 2006 18:04:31 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: Semantic Web <semantic-web@w3.org>
- Message-Id: <1157040271.25854.37.camel@localhost.localdomain>
Le jeudi 31 août 2006 à 11:56 +0200, Henry Story a écrit : .../... > > > W3C XML Schema has been rejected quite early because its xs:any > > particule couldn't exclude multiple namespaces and would have greatly > > reduced the extendability of RSS 1.0. As far as I remember, TREX, > > Schematron and Examplotron schemas have been contributed. RELAX NG was > > still in its infancy an we've preferred to keep these schemas out > > of the > > spec. > > Does RSS1.1 fix that? Kind of... RSS 1.1 uses RELAX NG which can exclude multiple namespaces when defining foreign elements, however, it focuses on the core RSS namespace and doesn't use this feature. In other words, the schema would need some polishing to be usable to validate RSS 1.1 core together with modules. Right now, it accepts elements from any foreign namespace but doesn't check any constraint on these elements. > I know it's not widely used, but it is useful > as an example. Yes, it's a nice exercise. > > > > The "crystalization" of RSS 1.0 is thus only described in its > > specification but it is very real. > > > > I have found the concept of crystalizing RDF is difficult to push in > > both XML and RDF worlds: XML eyes have found the RDF tax unbearable > > and > > RDF eyes tend to consider the crystalization of RSS 1.0 as a kind of > > non normative guideline for RDF newbies. > > yes, I have found so too. > > Psychologically it is difficult, especially because we are still in > the early days of both worlds. Perhaps the rdf/xml serialisation does > not make crystallization as easy as it could be. My guess is that as > more people get to understand both worlds, it will end up becoming > clear how to do a better form of rdf/xml, or we will end up having > recipes for making it easy to build. I hope so. > In any case it is a lot to learn to start off with. > > And for people producing rdf/xml it is a pain because standards such > as RDFT are only beginning to emerge, and there are no tools to help > us produce the right crystallization. > > But those tools will have to be produced, since one does need to > produce normal xml crystalizations of graphs. It should be possible to write schema aided serializers that produce nice crystals... My TreeBind binding framework (http://www.nongnu.org/treebind/) could probably be used for this kind of tools. > > I understand both points and reckon that although I am a proponent of > > crystalized RDF vocabularies, I would fight any effort to crystalize > > XML... > > I would say crystalize *to* xml :-) Yes. What I meant is that the same arguments that we can elaborate to explain why XML shouldn't be constrained to use a specific Unicode serialization can be used to argue that RDF shouldn't be constrained to use a specific XML serialization :) ... > I agree that crystalization to rdf/xml is a much better solution. > Perhaps we should only call something a crystalization when one ends > up with rdf/xml, but then I was thinking that perhaps in the end we > may end up with an improoved rdf/xml and so by constraining the > definition, we would end up having to re-invent the term if a new > form comes up. > > > Crystalizing RDF is about facilitating the access at both a RDF > > and a XML level and that could be transposed to XML to facilitate the > > access at both a XML and a text (Unicode) level. This transposition > > could be done by providing both a XML schema and a EBNF that would > > impose a specific serialization for XML (such as imposing double > > quotes > > to delimit attributes, specific namespace prefixes, ...). This would > > have the benefit to lead to XML applications that could be parsed > > through regular expressions! > > > > I find it hard to explain why I think that crystalizing XML is a bad > > idea while crystalizing RDF is a good one but I try to pursue this > > principle when I work with RDf and: > > Well given that you can the put your ontology for all your terms > online at the url of the relation or class it makes it much easier to > understand. Also you get SPARQL queries for free. You get a good > semantics. You get clear extensibility, ... > > > > > * My XML/RDF QBE syntax > > (http://www.idealliance.org/papers/extreme/Proceedings/html/ > > 2005/Vlist01/EML2005Vlist01.html) is crystalized. > > * My main contribution to the INSEE geographical ontology > > (http://rdf.insee.fr/geo/) has been to make sure that it > > crystalizes nicely. If you look at one of the instance > > documents > > such as http://rdf.insee.fr/geo/cantons-01-2003.rdf you'll see > > that we've done a very good job to keep the "RDF tax" as > > low as > > possible and I plan to write a RELAX NG schema to describe > > this > > serialization. > > I have added those two as examples to my blog. But I notice that you > don't make your terms available via http GET > for example I can't get http://rdf.insee.fr/geo/canton. That's something that has been discussed at large and that I am still trying to fix :) ... > Also I don't think coming up with a new query language is so > important. The xml people have xquery and the rdf people have SPARQL. > That's good enough. Yes, but my intention while proposing this language was to crystalize the queries themselves so that the same queries can be understood by both XML and RDF people! There was also a more concrete motivation which is that the data currently lives in a LDAP repository and that I didn't want to develop neither a XQuery to LDAP nor a SPARQL to LDAP gateway... > > Thanks for giving a name to this principle! > > I keep thinking that perhaps I should really be in marketing :-) :) Eric -- GPG-PGP: 2A528005 Freelance consulting and training. http://dyomedea.com/english/ ------------------------------------------------------------------------ Eric van der Vlist http://xmlfr.org http://dyomedea.com (ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema ------------------------------------------------------------------------
Received on Thursday, 31 August 2006 16:04:46 UTC