RE: Alternatives to XML for RDF?

> -----Original Message-----
> From: ext Dave Beckett [mailto:dave.beckett@bristol.ac.uk]
> Sent: 15 August, 2003 13:23
> To: Stickler Patrick (NMP/Tampere)
> Cc: aredridel; www-rdf-interest
> Subject: 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.

Then, my first point actually *isn't* false, as you claim above.

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

Nothing that I've said in this thread conflicts with what
you have said about creating vocabulary or application specific
DTDs or schemas.

So I fail to understand your apparent objection.

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

True, but variability of expression is a symptom of
RDF/XML not being intended to serve as the form
of consumption.

Consistency is important in the form of consumption, to
minimize complexity and effort -- and the graph is very
consistent.

RDF/XML can include all kinds of syntactic sugar because
the variability is removed when mapped to the graph.

Folks who use tools such as XQuery are used to dealing
with XML models which are designed to be the primary
form of consumption, and as such, exhibit far less variation
than RDF/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.

You seem to be presuming a fairly closed and constrained
environment, where one controls both content creation and
content consumption.

But for someone wanting to work with arbitrary RDF, one
does not have the luxury of picking one way to write RDF/XML,
since they are not the content creator, nor can they
constrain the RDF to a particular vocabulary (even if
the RDF uses the vocabulary of interest, it may include
statements using other vocabularies, etc.).

In short, if you want to deal with arbitrary RDF in any
scalable, reliable manner, you should work with graphs,
and not with RDF/XML.

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

I mean, you can't both specify things such as minimum cardinalities
yet allow for arbitrary syndication of knowledge fragments into 
a valid kb satisfying all constraints.

With XML, you have to say everything that is required in
the same instance, or it is invalid.

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

I'm sorry, Dave, but I don't follow the point you are trying
to make here, or what you are actually objecting to in what
I said.

I'm simply trying to say that processing RDF/XML as XML
is not going to be nearly as optimal to processing it as a graph 
because the heart of RDF is not XML. 

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

Perhaps, but I beleve they are fully valid.

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

My comments on the shortcomings of the striping model
are fully valid for DTDs. XML Schema really adds nothing
to the issue.

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

Right. As I suggested, "a form of" N3.

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

I don't see where anyone proposed anything of the sort. Either
that N-Triples itself would be changed, or that anything specific
would be done in any particular timeframe.

> Given the concerns with XML and RDF/XML, any future non-XML syntaxes
> better be well thought through. 

I fully agree.

> For example, shipping XML literals
> inside non-XML in a way that people find easy, that'll be fun.

Quite.

Patrick

Received on Friday, 15 August 2003 08:07:27 UTC