Re: Alternatives to XML for RDF?

On Thu, 14 Aug 2003 09:00:58 +0300
"Patrick.Stickler" <Patrick.Stickler@nokia.com> wrote:

Sigh.

> 
> > -----Original Message-----
> > From: ext Aredridel [mailto:aredridel@nbtsc.org]
> > Sent: 13 August, 2003 21:22
> > To: www-rdf-interest@w3.org
> > Subject: 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.

These are your opinons, so here are mine. The first one is patently
false and the second is moaning on XML style with no substance.

Nobody is the arbiter of XML style, not that I'm telling you that a 5
year old XML format cannot be improved (or even, XML itself).

> > 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]
> 
> My point was not that using XML to serialize RDF graphs
> was a bad thing, but that the *particular* RDF/XML serialization
> has numerous issues that (for me at least) make dealing
> with RDF as RDF/XML more trouble than it's worth.
> 
> Specifically:
> 
> 1. You can't write a DTD to validate arbitrary RDF/XML.

True but you can't write a DTD to validate arbitrary XML either.

Your point is really that using DTDs to validate *any* RDF/XML isn't
possible.  Of course (well you can, but it isn't much use, lots of ANY).

Both XML and RDF are generic technology.  To "validate" instances of
them requires schemas/DTDs/... that are specific to the application in
hand.

RDF's "validation" is different from XML's since RDF was designed to mix
terms and hence, mix descriptions of those terms - XML gave you 1 DTD.

Whatever way you wrote your RDF in XML or any other file format,
"validating" RDF in the XML style would never work.

However, you can write a DTD or XML schema to XML-validate specific
RDF/XML instance for some application just like you can to validate a
specific XML instance for a particular application.


> 2. There are numerous ways in which the same thing can
>    be expressed in RDF/XML so XPaths and XSLT scripts
>    become extremely baroque if one wants to work with
>    arbitrary RDF/XML.

Yes. There are also likely numerous ways to write the same thing in XML.
But you cannot say they are the same thing. Although anything using XSLT
looks a little baroque to me :)

Pick one way to write it, make a DTD or some XML schema, then you can
DTD/schema-validate.

> 3. One cannot express constraints in terms of RDF/XML
>    which will be meaningful to generic XML tools.

The terms of RDF/XML are those of any XML syntax - elements and
attributes etc. So you can thus use any generic XML tool, whatever that
means.  Something that supports the XML 1.0 spec? with namespaces?

Big lumbering XML tools might do some XML schema validation for some XML
schema language (please install megabytes of software).

> 4. One cannot express vocabulary equivalences in terms
>    of RDF/XML which will be meaningful to generic XML
>    tools.

Yes, XML does not understand RDF.  So what?  XML does not understand
vocabulary equivalence at all for any terms for any application of that
file format.  There is no xml:sameAsOtherThing in the XML 1.0 specification.

Of course, that doesn't prevent add-on XML schema languages making
those claims.


So much of the points above are just general fallout from using XML
and DTDs as they were designed.  RDF/XML's striped design and
use of namespaces does have advantages, but these have consequences
that you are somewhat concerned with here.

> In short, RDF/XML is the least important part of RDF,
> and is nothing more than a means to an end, and operating
> directly on RDF/XML misses out on the very point of RDF,
> to work with meaning rather than syntax.

<censored/>

> As for folks using XML tools to do verious things to
> RDF/XML instances not relating to interacting with 
> the knowledge itself, but simply syntax fiddling,
> for various reasons, such as for presentation, fine.
> 
> But whenever I hear someone recommending that folks
> consider tools such as XPath, XQuery, etc. for use
> with RDF, I have to speak up.
>
> That's not the right way to work with RDF, and will
> be both fragile, limited, and fail to exploit the
> power of RDF and the Semantic Web.

Rather sweeping statements.

> > 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.
> 
> Sure. But you can't do that with the infinite namespace
> striping model used by RDF/XML.

Indeed, and when it was designed in 1998/1999, who knew what future XML
schema languages and tools would do several years later?

<snip/>

> > Making both NTriples and RDF/XML
> > standard serializations would be very useful. 
> 
> Or rather, making a form of N3 a standard serialization.
> 
> NTriples is, in a sense, "kind of" a standard, insofar as the
> tests are concerned, and being a subset of N3, would gain
> status should N3 be "blessed".

Back to the subject of this thread.

I edit N-Triples and helped create it (after Art Barstow). N3's
relationship to N-Triples is up to the N3 developers.  As far as I
recall, at this point, N3 doesn't do all of N-Triples.

N-Triples is far away from being appropriate for end users, for which it
was not designed. N3 also has similar problems, in I18N in particular.

This isn't to say that N-Triples++ wouldn't work but a small
set of additions are required.  Now is not the appropriate time
for me to change N-Triples which has been very successful
as the test case format that it is.

Given the concerns with XML and RDF/XML, any future non-XML syntaxes
better be well thought through.  For example, shipping XML literals
inside non-XML in a way that people find easy, that'll be fun.

Cheers

Dave

Received on Friday, 15 August 2003 06:27:37 UTC