RE: Taking an axe RDF in XML? (no thank you)


I am not sure that the XML syntax is a major stumbling block on the road to
the adoption of RDF.

The counterexample is XSLT that has an even more horrible syntax but it has
been widely picked up.

My explanation of XSLT success vs RDF failure to gain widespread acceptance
is that the use case that XSLT is made to provide, tranforming XML, is both
widely needed and easily understood.

XSLT provide 'instant satisfaction': you write a transform and some
funny-looking XML gets transformed in human-readable HTML. Now that's

On the contrary: you describe some resource in RDF and ... not much happens.

The set of use cases provided by RDF is much richer but also clearly harder
to grasp than the XSLT ones.

But I would certainly agree that an aesthetically pleasing syntax that
people could write/read easily would help enormously in kick-starting the
semantic web. 

Problem: I don't think that you should be looking at XML for a solution of
this problem.

Are you aware of any XML syntax that people actually like to use?

XML fulfils a very important function in the semantic web as a flexible,
easy-to parse, transport syntax but it is far from being easy on the eye. 

A much better starting point would be N3 or other non-XML syntaxes. 

What about an official non-XML syntax for RDF optimised for human


Pasqualino "Titto" Assini - Nesstar Ltd
John Tabor Building - University of Essex
Colchester, Essex  - CO4 3SQ  - United Kingdom
email: <>  personal email: <> 

-----Original Message-----
From: Bill de hÓra []
Sent: 23 May 2002 13:51
To: 'Graham Klyne'
Subject: RE: Taking an axe RDF in XML? (no thank you)

Hash: SHA1

> -----Original Message-----
> From: Graham Klyne []
> Bill,
> I think there's an implicit assumption in your message that
> the existing 
> XML serialization of RDF is not suitable for its purpose.  


I don't altogether agree, but I suspect have a different notion of
fitness for purpose.

Let me clarify what I think the purpose of the XML serialization
is. The XML serialization is there to get RDF adopted and used,
nothing more. Behind that /is/ an assumption and it is this: in
software tools, syntax and ease of use  count for more than
semantics or correctness. 

The XML serialization is means-ended: it's a carrier, there so that
RDF graphs and the underlying consequences of the MT can be held
within it. Kendall Grant Clark suggests:

my theory about why RDF is not widely used is that to date it has
not been well evangelized. 

He's suggested that this is the role of the primer. I'm suggesting
that this is the role of the XML serialization.

> I'm not saying it's perfect, just a lot better than it's
> sometimes given 
> credit for.  It's biggest problem (IMO) was it's original 
> documentation 
> (which is easy for me to say in hindsight...)

I think it's clear enough I agree the state of current syntax draft
is a vast improvement over the M&S.  On the other hand, the wg did
invent ntriples to get some work done and as far as I know is still
using it. Not eating your own dogfood is cause for concern. When I
see the wg and the director move to the XML, no doubt I'll recant. 

> If there's a problem, I think it's that we're failing to 
> capitalize on this 
> migration path to RDF.

I don't agree this is the problem. People are not working and
thinking in RDF and that's almost wholly down to the syntax. RDF
compatible is good, but is a poor substitute for RDF inside. It's
also dissonant; while I'm thinking in domain X in my modelling
language, I have to saccade to be sure about RDF upward
compatibility. Make it easy for me to think about domain X /in/ RDF
not /for/ RDF.

> >4) Wrt to deployment, RDF's costs are frontloaded. We think
> it's going
> >useful, some day, because we have a notion that information
> in RDF form
> >is highly repurposable and easy to merge (serializations
> >notwithstanding). I haven't seen much by way of acknowledgement
> >that  RDF is a pension plan for your information, and surely it 
> wouldn't hurt
> >any to get this message across some more.
> #g:
> I agree strongly with almost everything you say here.  Except
> that   intelligent use of the XML serialization means that the
> front-loaded  costs can be practically zero as an increment on
> using XML.  Design your XML 
> application format to be RDF compatible.  Later, when the 
> tools are widely 
> available to handle this as pure RDF data, a return on almost 
> no investment 
> can be realized.

I think the costs are nowhere near zero, though they have dropped
considerably in the last year. 

Nonetheless, other wgs, specifically WS ones, don't seem all that
interested in RDF as base material, unless things have changed in
the last few months. It's astonishing to me that WSDL may get out
the door and not be written in an RDFXML. 

I've been hearing about the toolsets for a while. Danbri has
suggested in the past the RDF dev community aren't closers of a
sort. I challenged it then and still find it an anomaly difficult
to credit; it's looking for answers in the wrong place. This is a
classic bootstrapping problem; to break the cycle simplify the XML.

Syntactically, things still are not user friendly enough and I put
that down almost solely to the scope of the charter, not the
members of the wg, nor how RDF core goes about its business.

I humbly suggest that if a XML syntax is developed, a simple not a
clever one, you'll see the tools and people modelling RDF because
they have the tools, within six months of that syntax being
uploaded. Clear this barrier to adoption and the only thing that
can hold back RDF then are the innate complexity of RDF graphs or
the innate inability of RDF developers to ship One-Oh code, neither
of which I suggest are the barriers purported. Otherwise short of a
killer app, RDF will remain a fringe or sleeper technology while
the world carries on with the likes of WSDL, XMLSchema, XMI or the
Model Driven Architecture.

Bill de hÓra

Version: PGP 7.0.4


Received on Thursday, 23 May 2002 10:44:53 UTC