W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

Re: RDF graph model limited by RDF/xml 1.0 syntax?

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Thu, 27 Sep 2001 20:21:47 +0100
Message-Id: <5.1.0.14.2.20010927201221.03be47a0@joy.songbird.com>
To: Dan Connolly <connolly@w3.org>
Cc: w3c-rdfcore-wg@w3.org
At 11:42 AM 9/27/01 -0500, Dan Connolly wrote:
>Now that I've written down my thoughts, I lean
>toward saying: the future is longer than the past;
>let's formalize a nice clean graph model, accept that
>the 1.0 xml serialization has some limitations, and
>work toward fixing those limitations in the future.

Well, I sort-of assumed this was where we were trying to go.  The charter 
restriction on not extending RDF in this round emphatically does not mean 
(IMO) that the underlying abstraction must be hobbled by the limitations of 
the current syntax.

I see two ways to instantiate this vision:  (a) make the abstract 
graph/model theory agnostic w.r.t. possible future extensions, or (b) pick 
a general, consistent framework that ignores the arbitrary 
restrictions.  If the latter is easier, and if it doesn't force us to make 
some premature decisions, I'm all for it.

>After all, an awful lot of RDF software is gonna
>have nothing to do with the XML serialization, and
>forcing all that software to support these
>awkward limitations doesn't serve RDF's goals,
>in the long run.

I very much agree.  (Though I'm mildly surprised to hear you say this.)

>I wonder whether this resolution to literalsubjects
>and to the question of whether bNodes are allowed
>as predicates fits in our charter;

Ah... that's why you had LE : E -> URI designated as "partial", n'est pas?

>  i.e. I wonder
>if it's acceptable to the community as a clarification
>of the RDF 1.0 spec. Perhaps it's best to put
>those off until we design an XML syntax that supports
>them. I dunno.

If (a) it's simpler to express than being merely agnostic about certain 
points, and
(b) doesn't force us into making premature decisions that out successors 
may later regret, then I'd support such an approach.  An issue may be 
whether or not we can be sufficiently confident about (b).

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------
Received on Thursday, 27 September 2001 15:43:26 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:39:51 EDT