W3C home > Mailing lists > Public > semantic-web@w3.org > August 2006

Re: rdf crystalization

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 31 Aug 2006 11:56:37 +0200
Message-Id: <E66B3BBE-A80A-4F26-8852-FC2FDF424FBA@bblfish.net>
Cc: Semantic Web <semantic-web@w3.org>
To: Eric van der Vlist <vdv@dyomedea.com>

I have also added a wiki page for this so that other can add  
examples, tips and tricks, tools, etc

http://esw.w3.org/topic/RdfCrystalization


On 31 Aug 2006, at 09:05, Eric van der Vlist wrote:
> Hi Henry,
>
> Le lundi 28 août 2006 à 16:00 +0200, Henry Story a écrit :
>> As it is often useful to have terms to speak about things, I invented
>> "rdf crystalization" to describe what RSS1.1 does
>> when it combines a relax-ng with an ontology to create structured  
>> rdf/
>> xml .
>>
>> http://blogs.sun.com/bblfish/date/20060828
>>
>> RDF is fluid data, but it helps to crystalize it for angle bracket
>> lovers.
>>
>> After writing this I thought perhaps I should check if there is
>> already a term for that :-)
>
> This is something that we had already tried to achieve with RSS 1.0  
> and
> we'd discussed at length the opportunity to publish schemas for RSS  
> 1.0.

That is why I mentioned RSS1.1 which does produce those schemas. :-)
http://inamidst.com/rss1.1/

> 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? I know it's not widely used, but it is useful  
as an example.

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

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.

> 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 :-)
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.

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.

> Thanks for giving a name to this principle!

I keep thinking that perhaps I should really be in marketing :-)

Henry

> Eric
>> Henry
>>
>> Home page: http://bblfish.net/
>> Sun Blog: http://blogs.sun.com/bblfish/
>> Foaf name: http://bblfish.net/people/henry/card#me
>>
>>
>>
>>
>>
> -- 
> 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 09:56:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:17 UTC