W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2000

Re: RDF and XLink

From: David Megginson <david@megginson.com>
Date: Fri, 26 May 2000 15:48:20 +0000
Message-ID: <392E9CC4.672ABA7A@megginson.com>
To: "Eve L. Maler" <Eve.Maler@east.sun.com>
CC: w3c-xml-linking-ig@w3.org, www-rdf-interest@w3.org, sergey Melnik <melnik@db.stanford.edu>, stefan Decker <stefan@db.stanford.edu>
"Eve L. Maler" wrote:

> "I'd recommend to be very careful with such things. RDF spec has a
> similar construct "aboutEach" which has been the subject of controversy
> and misunderstanding. The spec demands that the "batch" process of
> assigning the given relationship with every member of the bag (or in
> your case, every element with the same label) takes place during
> parsing, i.e. is transparent to the applications. However, a similar
> syntactic element "aboutEachPrefix" can only be expressed at the model
> level, i.e. using special relationships with predefined meaning."

The particularly nasty thing about aboutEach is that it doesn't play
very nicely with streaming processors: you either end up having to keep
a lot of information in memory (which destroys the benefit of a
streaming processor), or you have to expose aboutEach to the application
and complicate the interface.

For example, if I had

<rdf:Bag ID="foo">
<rdf:li resource="..."/>
<rdf:li resource="..."/>
<rdf:li resource="..."/>

my processor would have to store that entire structure in memory (and
every similar one) for the whole length of the parse in case the very
last description processed happened to use aboutEach to reference one of
them.  This approach doesn't hurt much with little toy RDF files, but
for the multi-gigabyte files that you see in B2B data exchange, it's
entirely inappropriate -- the only solution is to expose aboutEach to
the app and hope that it can somehow map it to the internal data
structures or database tables that it's been building.

All the best,


David Megginson                 david@megginson.com
Received on Friday, 26 May 2000 11:50:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:30 UTC