W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2001

Re: Summary of the QName to URI Mapping Problem

From: David Allsopp <dallsopp@signal.qinetiq.com>
Date: Wed, 22 Aug 2001 16:31:15 +0100
Message-ID: <3B83D043.52C1037C@signal.qinetiq.com>
CC: www-rdf-interest@w3.org

"Thomas B. Passin" wrote:

> OK, I'm going to close this out with this last remark.  You ***are*** going
> to lose information putting something into rdf interchange syntax - it's the
> well-known inability to round-trip.  Once you flatten a nested structure
> into sets of triples, with interpolated nodes to take the place of the
> nested structures, you lose the information needed to fully reconstruct the
> original, right?  You may claim that nothing important is lost ***for the
> purposes of RDF representation***, which may be true. 

That's the important point. It should be the case that RDF in any
serialisation format can be parsed and then re-serialised (& repeat any
number of times) with no loss of data *relevant to the RDF data model*. 
Yes, you lose the ordering of tags in an XML document, for example, but
if that order is significant then that document isn't conforming to RDF

> Or you may add some
> triples to describe the original structure, which would mean adding thngs
> that weren't in the original.  In any event, something has been lost or
> added.

I can't imagine why it would be desirable to capture such structural
information from the document, which should be irrelevant by
definition.  Especially since we would be assuming, at the data model
level, a specific serialisation format! Once we've parsed into triples
we should neither know nor care what serialisation was used, surely?


David Allsopp

/d{def}def/u{dup}d[0 -185 u 0 300 u]concat/q 5e-3 d/m{mul}d/z{A u m B u
m}d/r{rlineto}d/X -2 q 1{d/Y -2 q 2{d/A 0 d/B 0 d 64 -1 1{/f exch d/B
A/A z sub X add d B 2 m m Y add d z add 4 gt{exit}if/f 64 d}for f 64 div
setgray X Y moveto 0 q neg u 0 0 q u 0 r r r r fill/Y}for/X}for showpage
Received on Wednesday, 22 August 2001 11:31:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:31 UTC