Re: Decentralized RDF Distribution

Seth Russell wrote:
> 
> 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 guess that makes sense on the web - I'm coming at this from a slightly
different perspective; using software agents which aren't necessarily
out on the web; they may be in closed networks.  There may not be one
authoritative source for the data - different agents say different
things, and you just have to decide which one you trust most at that
point in time (or take an average or something). The agents may have
very restricted forms of (message passing) communication and can't
necessarily dereference an HTTP URL.

> > 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 haven't given that much thought yet as I have other priorities -
there's the stuff on date and time formats at
http://www.w3.org/TR/NOTE-datetime, which seems an obvious choice...
 
> > 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'm afraid I missed most of the discussion about contexts, so I'm in the
dark here - can you point me to something which will explain?  How would
I 'collect a statement in a context'? Is this something implemented now,
or does it require extensions to current APIs?

Regards,

David.

-- 
...Wandsworth the skool dog trots up with the missing fusion
percolater in his fatheful jaws. Meanwhile, Sigismund looks at us 
through his all-seeing videoscope.  We look at him.  Impasse.

Received on Tuesday, 20 February 2001 05:24:35 UTC