OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: A certain difficulty

[ Lists Home | Date Index | Thread Index ]
  • From: "Perry A. Caro" <caro@Adobe.COM>
  • To: Dan Brickley <danbri@w3.org>
  • Date: Mon, 28 Feb 2000 13:06:14 -0800

Dan Brickley wrote:
> The concerns centre around how closely RDF is
> associated with one particular RDF interchange syntax, namely the
> XML-based format described alongside the RDF model in the Model and Syntax
> Recommendation. RDFists have generally anticipated multiple syntaxes, or
> (equivalently?) software architectures that extract RDF data structures
> from a wide variety of concrete representations. Nobody is considering a
> rewrite of the model, but there is widespread concern that the current
> syntax is sub-optimal, and holding back progress with RDF
> generally. That's all.

I grumble over the syntax as much as any implementor, but there is danger in
being cavalier about changing the syntax, as I will detail below.

Here, I want to agree that the syntax is holding people back, but I claim
that there are more significant impediments, and in fact, the problems with
the syntax are minor in comparison and no worse than other arcane standards,
such as XSLT.  I think the more important problems, which others have
detailed, are:

* Lack of good public/open software (compared to SAX, DOM, XSLT).
* Lack of good usage examples.
* Lack of usage guidance for the most common applications.

I would claim that the simplest applications of RDF will be the most common:
Unqualified Dublin Core, externalizing simple SQL database tables with
single keys, and traditional key/value metadata.  Frankly, if your task is
to port a legacy metadata format, like IPTC, RDF is over-specified for
things that are ultimately irrelevant (aboutEachPrefix), and under-specified
for critical requirements (like semantic constraints on values, ala XML

> RDF apps written today can be coded to distinguish
> between model and syntax and therefore be futureproofed w.r.t. such
> developments, but since there's currently only one widely understood
> syntax for RDF people feel there's a gap that could be filled relatively
> easily.

Easy for you, difficult for me.  With our customers, we get about a
once-a-decade opportunity to shift to a new interchange format, and even
then, it is a multi-year struggle/transition. The kinds of systems our
customers build around metadata are mission-critical and long-lived. 
Interchange format stability is a big deal.

The primary reason we are using RDF in the first place, and putting up with
its difficulties, is the belief that it is the best candidate for general
inter-application interchange of metadata.  That means the syntax as well as
the model.  If a second syntax comes into general usage (de jure or de
facto), RDF as a standard of interchange is tremendously weakened.

Steps can be taken to mitigate this problem, such as guaranteeing that the
new syntax is backwards compatible with version 1.0 parsers/processors, but
ultimately, when you open the door to the possibility of a new syntax, you
invite early-adopters to jump ship altogether.  If we are forced to consider
a new syntax, do you think we will limit ourselves to RDF?  XML technology
has advanced significantly since RDF was ratified, and I would be hard
pressed to defend the expenditure of resources needed to keep up with new
RDF syntaxes, when a home-brewed and/or XML Schema controlled syntax would
suit our usage more efficiently.  Not to mention that we would have more
control and stability.  Once you weaken the interchange story for RDF,
what's left as an advantage in the general metadata world?

Perry Caro
Advanced Technology Group
Adobe Systems Incorporated

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS