W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2004

RE: do we need INSERT?

From: Rob Shearer <Rob.Shearer@networkinference.com>
Date: Sat, 28 Aug 2004 16:18:57 -0700
Message-ID: <CFE388CECDDB1E43AB1F60136BEB4973028135@rome.ad.networkinference.com>
Cc: "RDF Data Access Working Group " <public-rdf-dawg@w3.org>

I'm going to go out on a limb and say no. INSERT and UPDATE
functionalities do NOT need to be part of a query language.

In SQL, there are strong arguments for including such functionality.
Data is partitioned into discrete segments with very specific forms.
Adding data requires the ability to target exactly where that data is
going, and SQL already provides such a facility. Further, INSERT
functionality is only provided for "true" RDBMS tables, not views or any
transformation which simply displays data in a specified format. It was
a given during the design of SQL that the vast vast majority of data
would would managed internally by the RDBMS.

RDF differs in all these ways. Most obviously, adding data to RDF
doesn't require any clever logic at all--you don't even have to do any
"schema validation" to make sure the new data matches up with the
existing data. You just say "here are a bunch more triples", and that's
that. You don't get any advantage to using a query language.

And of course the premise that data will be managed unambiguously by the
query processor will almost certainly be much much less true of RDF data
than it has been of SQL data. For the foreseeable future, RDF data is as
likely (or more likely) to come from flat files, transformation and
aggregation services, and remote network resources as it is to be
locally managed. Just as updating a RDBMS view doesn't make much sense,
updating RDF data from any of these sources doesn't make much sense:
it's ambiguous just where you should put the new data. Add to this the
possibility of data asserted by two or more sources and both UPDATE and
DELETE functionality start to look pretty ambiguous, too.

I look at the intent of an RDF query language as offering what DOM, SAX,
and XPath did for XML data: a way to get information out of that
particular data model for use in other applications. I think it's quite
significant that the write functionality of these technologies takes the
form of filters and transforms built on top of the query language.
Received on Saturday, 28 August 2004 23:21:50 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:44 UTC