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

In my KR model, time is part of the context.
The basic format of a KR proposition is

    at space=s, time=t, view=v { statement list }

In many cases, there is no space-time dependence, and only view (which is the name given to a list of propositions) is pertinent.  But whenever an action is involved, the where (space) and when (time) can be important, as in your example.

Note: the above ignores other types of sentences (questions, commands and assignments) and nested contexts.
============ 
Dick McCullough 
knowledge := man do identify od existent done
knowledge haspart list of proposition

  ----- Original Message ----- 
  From: Sandro Hawke 
  To: Danny Ayers 
  Cc: uche.ogbuji@fourthought.com ; Shelley Powers ; Jonathan Borden ; RDF-Interest ; xml-dev@lists.xml.org 
  Sent: Wednesday, November 20, 2002 2:41 PM
  Subject: 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