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

Re: Decentralized RDF Distribution

From: David Allsopp <dallsopp@signal.dera.gov.uk>
Date: Mon, 19 Feb 2001 10:46:35 +0000
Message-ID: <3A90F98B.F7837DEE@signal.dera.gov.uk>
To: RDF Interest <www-rdf-interest@w3.org>
CC: Seth Russell <seth@robustai.net>


Seth Russell wrote:
> Aaron Swartz wrote:

> > Updates (modifying triples) and deletes (removing triples) are more
> > difficult, and require entering an area that RDF has been afraid to
> > touch: time.
> 
> I don't think it makes much sense to modify a triple.  Rather you need to
> remove it; then perhaps add a different one.  

Does it not make sense where the object is a literal? Why wouldn't we
change
Town--population-->10297  to  Town--population-->10298  after the latest
birth?  8-)
Isn't this equivalent to remove/add in all cases, provided that updating
the object is an atomic operation?

> So we have here only two
> basic transactions insert and remove ... which may be better named assert
> and retract.
> 
> > The simplistic way to manage this would be to assign each triple a URI
> > and then publish updated information on each of the statements.
> > However, by doing this, we run into the tricky problem of both
> > asserting and reifying a statement at the same time. _@@ reification
> > experts should let me know how to do this_
> 
> I think this is a good idea, have the original author assign a uri to each
> triple.  The reified statement then is a quadruple [ statementUri,
> subject, predicate, object].  When we assert triples, that's what goes
> into the semantic cloud.  When people talk about those statements to the
> cloud, they refer to them by putting the statementUri in the subject.  I
> love it, it's simple.

I'm very interested in this sort of usage.  I'm working on software
agents which exchange information in situations where data change over
time, and are subject to varying levels of trust over time, so I will
need to be able to 'tag' the triples with their source, timestamp,
expiry...  This would allow filtering, or roll-back to earlier data,
etc.

I think this sort of usage needs to be considered in the design of APIs
and query languages - we'll need easy manipulation and querying of
reified statements, e.g:

I would want to be able to easily query for a statement which is reified
but not asserted, without having to construct a query explicitly
matching the whole quad.

Some APIs allow 'direct' reification without using quads (allowing
Statements to be Resources), whilst also allowing the explicit quad
form.  We shouldn't need to know which implementation is used when
writing our query, which reinforces the point that we shouldn't have to
explicitly search for quads - that's the job of the query engine.

Regards,

David.

-- 
David N Allsopp
DERA Malvern
Received on Monday, 19 February 2001 05:49:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:48 GMT