Leeh wrote:
I understand that the "real" RDF model is the conceptual network of
nodes (Subjects and Objects) connected by predicate arcs;
Congratulations ! You're probably the first person to ever post an RDF
question here, yet to understand that already. And you thought you were
"naive" ?
the official way to serialize the graph is to use the RDF/XML specification.
Hmmm.....
It's certainly not "the official way", just one of the oficially
described ways.
So far so good; but N3 and/or N-Triple notations are also used, and it
sure seems to me that N3 is "iso-morphic" to the graph;
You're not really getting this "naive" thing are you? 8-) That's a
pretty insightful comment and it took the RDF WG about 3 years before
it really sank in. The _history_ of RDF is as a fix to some issues with
XML. The "typical" understanding of RDF is as a sub-dialect of
XML(sic). The clueful understanding of it around the WG is increasingly
that triples are where it's at and what do we need this XML stuff for
anyway? Pragmatic reality obviously has to be somewhere in the middle.
If RDF were started again today, I don't think there'd be any XML
anywhere near it.
You have to remember though that RDF is pretty old, and it began at a
time when XML was suffering from being looked down on by the SGML and
HyTime people as too limited and so needed extensions built on top of
it. There was also a pervasive attitude that XML could solve everything
(I mean _everything_ - it was the era of universal semantic translation
by XSLT) and it would be truly universal in the future.
If we need to express the graph model in an XML -ish form, why wouldnt
it be easier, simpler, less fattening, whatever, to start with the the
triples
Good.
thus: [some XML stuff]
Bad.
The problem is one of legacy. RDF/XML's strength (its only strength) is
in its close resemblance to a pure-XML solution devoid of most RDF
structure and certainly devoid of "triples". Look at the post-2004
descriptions of RDF/XML; compare them to the pre-2004 "striped" use of
XML to represent RDF in XML and constrast them to pre-2000 notions of
representing RDF in XML.
RDF/XML's main weakness is as you've identified: it's a weird way to
represent triples and triples are the clear representation of RDF.
RDF/XML is RDF's own worst enemy when it comes to clear understanding
of what's really going on.
However if RDF/XML is ever to fly, it _must_ be XML-like, including a
strong resemblance to the sort of XML documents that a non-RDF
architect would design. User acceptance from the existing XML community
demands this. For another thing it (currently) relies on the
data-typing of XML Schema, and that itself depends on binding through
mapping properties and element names in the RDF/XML approach rather
than your triples-in-XML approach.
But as far as I can tell, no one has done or proposed such a thing. Has
it got some sort of fatal flaw, conceptual or practical, that I'm
looking right past?
What you suggest is an excellent way to directly represent triples in
XML. However triples can be represented in many ways, and XML doesn't
really offer anything here (compared to N3)
What makes RDF/XML , which to my inexperienced eye seems a bit clunky in
comparison, the preferred notation over N3 or an xml-ized version of N3 ?
"Clunky" is certainly true. It's not even sure if RDF/XML _is_ the
preferred notation any more. I don't think it is for most of Bristol
(from my last conversations with HP people). The RDF theoretical people
seem to focus on N3 entirely.
I'm in a different non-HP world these days. I have to work with XML and
I introduce RDF into things as far as I can get away with. So for me,
RDF/XML is the only way I can possibly work. It's still a little weird,
but then I remember how bad it was before 2004!
I don't think your RDF-in-triples-in-XML will ever be adopted. It's a
great idea, but it solves the wrong problem. No-one wants both triples
_and_ XML, the triples people don't need XML, the XML people can't work
with something that's so different to non-RDF XML.
