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

Re: Decentralized RDF Distribution

From: Seth Russell <seth@robustai.net>
Date: Mon, 19 Feb 2001 08:58:14 -0800
Message-ID: <3A9150A6.556B58A4@robustai.net>
To: David Allsopp <dallsopp@signal.dera.gov.uk>
CC: RDF Interest <www-rdf-interest@w3.org>
David Allsopp wrote:

> 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?

I'm not so sure that's the best way to deal with a resource that represents a
time varying quantity.  Why not just assign a URL to the varying quantify ...
say http:/population.server.com#TownX  .. if you dereference that URL you would
expect to obtain the current quantity ... so now lapsing into N3 you can see
that the triple { :TownX population <http:/population.server.com#TownX> .} is
always valid.  One needs to retract it only if the server changes.

> 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.

Great!  What kind of time stamp uri's are you considering?

> 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 don't think we need talk of reified statements at all .. just talk of
statements and their contexts.  When you talk about a statement, you refer to
its URI directly.  Collecting a statement in a context, is talking about it.

> 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.

Lapsing into Semenglish, If I *assert* to the Semantic Cloud:

( Le Stori'e de Fran'cis ) a story; containsTheContext { (the present King of
France) is Bald; (lives in) Paris }.

But you insist that  one of my assertions { (the present King of France) is
Bald.} is Incoherent; because right now there is no (the present King of
France).  I would rejoin that you had forgotten about the context of my
assertion.  The point being that the case where (a statement which is reified
but not asserted) simply need not arise, if we implement contexts.

> 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.

I think such a query engine would be greatly simplified if the parser converted
the rdf reification quad to the form [statementId, subject, property, object]
collecting the statement in a context of course.  Then all retrievals would be
on the same format of data.  At the moment I can't think of where it would hurt
.. but certainly somebody will figure that out.

Received on Monday, 19 February 2001 11:48:58 UTC

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