RE: Alternatives to XML for RDF?

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

Interesting.  I am one of those people, then!  I keep thinking that
RDF/XML is one of the things that makes it integrate with existing
infrastructure so well.  [Even just being able to store RDF in an XML
database is useful, as is rudimentary querying with XPath]

What I think is missing is tools for making the XML serialization itself
useful.  Having well-defined ways to shoehorn a graph into a specific
XML schema (or subset of schemas) would be very useful, I think --
Having a schema language that can state "this XML element is an instance
of rdf:Bag", and similar things, would make it possible to serialize
useful parts of an RDF graph into a well-formed and valid XML document.

An easy example of this would be RSS 1.0: I'm not sure if there's a spec
for how the XML should be formed, exactly, beyond RDF/XML rules, but
specifying it should be easy: <rdf:RDF> contains <rss:channel> and
<rss:item> and ____ extension elements; <channel> contains the normal
stuff, <item> and so on -- and that schema specifies what parts of the
RDF infoset are part of the application's knowledge model.  Such a spec
could also point out the default handling of unknown elements. Among the
ptions would be: ignore, parse inner content, deal with as abstract RDF,
pretend it's just well-formed XML and ignore the meaning.  This could be
a per-element attribute in the schema as well -- for example, require
<rss:channel> to conform exactly, but take just what's useful from
<rss:item>.

Such a schema spec would also allow for specifying a "correct"
normalization of the RSS/XML for any given circumstance. In the case of
RSS 1.0, one could say "One <channel> per file/feed", and "Serialize
with <channel> as the starting node in the graph; use only abbreviated
form there; second, serialize <item> nodes; third, allow no nodes to be
serialized if they would have to be top-level nodes in the
serialization."

The inverse scenario is also useful: such a schema would say,
canonically, what parts of an XML document are really graph semantics,
and what parts are just XML.  It would also allow a good mechanism to
extend XML's extremely useless ID/IDREF system.  If it had used some of
the ID-to-URI mapping that RDF does to begin with, much of XPath 2.0
would not have had to be invented.

> 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 ;-)

I agree in that the XML serialization is complex.  I'd like to see
people introduced using another syntax first, then the full model
unleashed later when they're ready.  Making both NTriples and RDF/XML
standard serializations would be very useful. [as an aside, I'd love to
see HTTP content negotiation on most RDF available on the web: if the
User-agent sends Accept: application/ntriples (or whatever ntriples ends
up being), send that. If it understands rdf+xml, send that.