RE: Alternatives to XML for RDF?

On Tue, 12 Aug 2003 Patrick.Stickler@nokia.com wrote:

>> -----Original Message-----
>> From: ext Charles McCathieNevile [mailto:charles@w3.org]
>>
>> XML is nice because it can be used with XML tools - XQuery,
>> Xforms, XSLT,
>
>For RDF, the use of XML does not actually invite the use
>of XML tools such as above, as they cannot be used
>effectively for arbitrary RDF/XML schemas.

This is true for generic processing of RDF. But I suspect I am not atypical
in being able to develop simple XML-based tools to work on specific
applications of RDF relevant to me. Although this doesn't give me the full
power of RDF, it allows me to do the job at hand with a simple tool, but
remain compatible with the full power of RDF.

>Operating directly on RDF/XML is a bad idea. One should
>always deal with an RDF graph -- and once you've gotten
>to the graph, the XML is gone, and is no longer an issue.

'The Graph' is an abstraction - interacting with it involves some
representation or other. For my purposes, XML happens to be an easy one to
use. In particular I am working on generating RDF, and using very simple
collections of RDF data.

>The one tool that might be used effectively with RDF/XML is
>an XML editor that simply does well-formedness checking. You
>can't do actual XML validation, because you can't write a
>DTD or XML Schema for RDF (it's element and attribute
>name sets are infinite).

In general this is true, but again for a specific purpose it is possible to
create an XML schema that specifies something which is valid XML and valid
RDF (by limiting yourself to the subset which meets those two conditions).
Coming from a background of people who are roughly familiar with XML, being
able to work with something that feels familiar (despite the fundamental
differences in outlook one normally finds among practitioners depending on
which side they came from) is extremely helpful.

>RDF/XML is actually more like a set of architectural forms than an XML
>content model.

Yes. Which is why I want to use RDF in the first place.

>I don't think there are many, if any, fans of RDF/XML.
>It is a means to an end (the graph) and a pretty ugly
>and problemmatic means at that.

I agree that it is a means to an end. Having a defined syntax that allows for
the reliable transfer of a graph to someone else is a pretty important end,
if we are to use this on the scale of the Web. In my individual project I can
use any internal format I want - whether that is one of incredible beauty and
elegance for my satisfaction, or horribly ugly but compatible with tools I
have already invested in.

Given that XML tools can be used for a number of simple, not unusual, real
world tasks processing RDF data serialised as RDF/XML, and the generally
widespread nature of XML, it seems to have some pragmatic advantages as an
agreed serialisation for interchange.

>That's a pity, because alot of folks get turned off by
>the XML serialization and miss the real beauty and
>power of RDF (there's probably a classic fairy tale
>in there somewhere ;-)

Right. Folks I work with don't understand any of the encodings normally used
for RDF, but they really like the ability to think about stuff by putting
down nodes and arcs, connecting them. It mirrors how they actually try to
record knowledge already. Constructing a graph in the mind from a written
serialisation is pretty hard for many people. Seeing the graph as a
two-dimensional layout makes a lot more sense.

Other people are used to the striping of XML, so the fact that RDF/XML takes
a similar approach puts them on comfortable ground as they try to work with
te new things that RDF brings an XML system. It has the added benefit that
they can use the tools tehy are used to for simple stuff.

Other people prefer a more narrative representation, or a cross-referenced
tabular representation, or whatever.

Clearly for many people chinese characters are a natural set of symbols. But
for the average english speaker, using only chinese characters would be a
strong encouragement to gmove to a graphic representation. Whereas adding
greek characters is something many people (especially with some mathematical
background) find natural. For people who grow up with chinese writing, the
difference between "vee", "u" "upsilon" and "nu" is probably not that
obvious...

It seems I misunderstood the assumptions behind the original request,
interpreting it through the filter I normally apply to viewing code.
Reminding myself of the broad range of users, and the perspectives they bring
to the question of "what is an ugly or elegant representation?" has been
valuable.

Electronic engineers tend not to popularise their work in a serialisation,
but with a graph (which implicitly tends to be directed).

Chess games, on the other hand, are nearly always represented with a
serialisation, of which I learned two as a kid.

What you will find elegant, sensible and useful depends not only on the task
at hand, but also on what you are used to.

cheers

Chaals

Received on Wednesday, 13 August 2003 01:42:17 UTC