W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2004

RE: XHTML and RDF; thinking about Trix, etc

From: <Patrick.Stickler@nokia.com>
Date: Fri, 27 Feb 2004 09:30:53 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B02A2E98B@trebe006.europe.nokia.com>
To: <GK@ninebynine.org>, <www-rdf-interest@w3.org>
Cc: <jos.deroo@agfa.com>

I share your concerns about confusing things by introducing yet
another serialization for RDF. I myself don't consider TriX as a 
replacement for RDF/XML (at least not anytime soon) but rather
as a tool for specific purposes, specifically use in an XML environment.

There are two key shortcomings to RDF/XML that I see insofar as
its usability with generic XML tools is concerned: (a) consistency
of structure, and (b) open tagset vocabulary.

The former could be addressed by defining a subset of RDF/XML which
provides a highly consistent, canonical serialization which is still fully
valid RDF/XML. 

The latter issue, the open tagset vocabulary, requires something other 
than RDF/XML, and it's IMO this latter issue that causes the greatest 
barrier to the use of generic XML tools and methods.

For my own part, if RDF/XML can be successfully embedded in XHTML
without too many challenges, then that is surely preferable (I haven't
had time yet to read Mark's paper, but surely will). 

The greatest value of TriX, IMO (and Jeremy may think differently) is 
as a specialized serialization which can be used by the XML community as
an XML friendly expression of RDF, not as a replacement for RDF/XML
for the broader RDF community.


-----Original Message-----
From:	www-rdf-interest-request@w3.org on behalf of ext Graham Klyne
Sent:	Thu 2004-02-26 13:52
To:	www-rdf-interest
Cc:	Jos De_Roo
Subject:	Re: XHTML and RDF; thinking about Trix, etc

At 02:41 26/02/04 +0100, Jos De_Roo wrote:

>it gives a very good feeling to read things like

Hey, yes!  That's some nice work.  Thanks for the reference.

I'd like to see a nice user interface for this kind of thing built into an 
HTML editor :-).  (It puts me in mind of a kind of "literate RDF"?)


Anyway, to broader topics.

I've been mulling over the recent discussion of Trix [1] from Jeremy and 

I have been thinking that it is a worthy piece of work, but have been 
struggling to find a coherent view about why, after several years, we want 
to start talking about /another/ XML syntax for RDF.  If the purpose of the 
existing RDF standard is to provide a single recommended way to exchange 
RDF between applications, then is yet another XML syntax for RDF not the 
last thing we want muddying the waters at this time?

I've also been having some thoughts about how, now that RDF is a full 
Recommendation, I might be able to promote its adoption in real-world 
applications, which means articulating some benefits of using RDF.  My 
thoughts have been lead in part by a comment by Brian McBride at a meeting 
last year, roughly:  "the question we ask should not be 'how do we get (all 
this data) converted to RDF', but rather 'how do we bring the benefits of 
RDF processing to (all this data)'".  I surely misquote, but I hope the 
intent is not damaged.  Part if the value I see in Mark Birbeck's paper 
[2], cited by Jos, is the way it addresses this question (for XHTML).

Reading Mark's paper [2] together with these other thoughts, lead me to a 
possible conclusion.  Maybe we don't really need another stand-alone 
RDF/XML format, but something we can use is a way to incrementally embed 
RDF in existing XML documents in a way that is amenable to processing with 
existing XML tools, and in particular easy isolation of the RDF into some 
representation of its abstract syntax.

I haven't looked or thought deeply enough about the technical issues, but 
I'm wondering if some combination of ideas from Trix [1] and "XHTML and 
RDF" [2] might not provide a framework for such?


[1] http://www.hpl.hp.com/techreports/2003/HPL-2003-268.html

[2] http://www.w3.org/MarkUp/2004/02/xhtml-rdf.html

Graham Klyne
For email:
Received on Friday, 27 February 2004 02:31:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:48 UTC