Re: [xml-dev] RDF for unstructured databases, RDF for axiomatic

(As an aside, I think RDF reification with formal semantics is doable,
it just needs to be done a bit differently, and it doesn't need to be
in RDF Core.  My basic argument is that the relevant parts of RDF are
a subset of FOL, and FOL can be reified in FOL (as in Perlis85 or
KIF92), and also in RDF.  For details see my LX paper submitted for
www2003 [1].  Please send follow-ups on that to rdf-logic, though.)

> Let's say I have a triple database for my address book. My auntie sends me
> her contact details in an RDF document. Shortly after sending, she realises
> that she made a mistake on the address and so corrects this and send the new
> document. Unfortunately, I receive the second document before the first. The
> documents each contain a datestamp, expressed as an RDF statement about that
> document. I have received all the information necessary, but how do I know
> from the triples I've received which is the current address?

I'm eager to see some discussion on this (but maybe we should keep it
on rdf-interest, follow-ups directed there).  My best sense is that to be
taken seriously (as more than the toy data most of us are playing with
now), RDF assertions need to come with metadata about who is asserting
them and for what time range they are being asserted.  RDF served via
HTTP gets some of this in HTTP headers.  This metadata could also come
in some kind of XML envelope, perhaps along with a signature (or
even inside an RDF graph if the message content is carried reified).

(Some people think that absent this metadata, RDF should be considered
asserted for all time, ... or perhaps for the moment you read it.  I
think this ambiguity will grow more grating, and we'll start to demand
the metadata.  If it's resolved by fiat to be eternal, then it'll just
have to reify the mutable content: unqualified RDF will be like
transaction logs of the variable RDF knowledge bases.)

I expect some data, such as definitions of terms, to be asserted as
true-forever.  Other data will be asserted true for a very short
(perhaps instantaneous) sample time.  In between, like current
web-page expiration times, will be data which people are willing to
sign for a few hours into the future to allow caching, etc.  

Often clients will have to make the "no news means no change"
assumption: you work with the latest information you have, because
it's all you have.

When you get conflicting assertions, and one has expired, it's clear
which should take precedence.  If both have expired, I'd still stick
with the one with the later expiration time.  If neither has expired,
I think you have a contradiction (which is another matter all
together).   What exactly it means for one to take precedence over
another is another question -- does one doc replace another, or do you
treat the older one simply as default values?

I should update my earlier thoughts on the matter [2] to say this more
clearly.

       -- sandro

[1] http://www.w3.org/2002/08/LX/v3/paper.html
[2] http://www.w3.org/2002/03/semweb/change

Received on Wednesday, 20 November 2002 17:42:16 UTC