Re: RDF triple assertions live forever?

[dropping foaf-dev since (a) I'm not on it so I can't post to it, and
(b) I think it's against the list policies to cross post
non-announcements.  Shame on all of us for doing it so far.]

> Sandro Hawke wrote:
> 
> > In short, triples live forever in the same sense these words I'm writing
> > (which will be archived in various places) live forever.
> 
> I think the validUntil functionality that Phil is describing provides 
> additional functionality over-and-above the usual web expiry mechanisms.
> 
> If I publish a graph, on the web, making some assertions, then I might 
> reasonably expect that version of the document to be accesible 'for 
> ever' - e.g. in a web archive service. At some point in the future, it 
> becomes unreasonable to hold me to RDF assertions I have made in the 
> past; this will often be later than an HTTP header expiry date. It may 
> also be that the most obvious interpretation of my RDF document will 
> have changed merely by the passage of time. e.g. I may say today that 
> the BBC is a reliable and unbiased news source, and, heaven forbid, 
> politically changes in the future may mean that I no longer hold this 
> opinion. So having the option to state an explicit time out on the 
> semantic content, as opposed to merely the representation, of an RDF 
> document may be useful.
> 
> i.e. RDF triples are in the present tense - and hence there meaning 
> depends on what we think of as the present.

[This is really just a brainstorming post.  I don't think I'm
disagreeing with anyone.]

So the issue here is really about promises and (more generally) setting
useful expectations.   

We are familiar with a simple present tense web page:

        I am currently in Belmont, MA, USA. 
            -- posted Fri Mar 28 11:46:38 EDT 2008

Now, if I post:

        I am currently in Belmont, MA, USA. 
            -- posted Fri Mar 28 11:46:38 EDT 2008
            -- valid until Fri Mar 28 12:00:00 EDT 2008

it's basically the same as:

        I am currently in Belmont, MA, USA, and I hereby swear I shall
        not leave Belmont, MA, USA before Fri Mar 28 12:00:00 EDT 2008
            -- posted Fri Mar 28 11:46:38 EDT 2008

If I do, somehow, make it to the office (in Cambridge) by Noon (to have
lunch with Ivan), I have broken a promise and you all have to decide
what the consequences will be.  Okay, I'm fine with that design, as far
as it goes.

It's something of a niche solution though.  I don't expect it to be used
for the vast majority of semantic web content.

For most of the rest of us, I don't think we'll be comfortable making
promises like that.  Maybe they can be downgraded to simple "forward
looking statements", from which one might deviate without loss of
reputation (honor?) for many reasons?  strongValidUntil and
weakValidUntil?

Even that is a stronger statement than I want to make.  I really don't
want to tell you all when I plan to leave the house, even though I don't
mind telling you were I am.  (hypothetically speaking.)

Here's another possible approach:

        I am currently in Belmont, MA, USA. 
            -- posted Fri Mar 28 11:46:38 EDT 2008
            -- next location update expected by
               Fri Mar 28 12:00:00 EDT 2008

What this means is that (1) I was in Belmont at 11:46, (2) I made no
promise about when I might leave Belmont, (3) until noon you could
reasonably guess I was still in Belmont due to inertia, but it would
just be you making a guess, (4) after noon, if there was no new post,
you could still guess I was in Belmont, but you would probably put less
faith in the guess, since an expected update has not happened.

That's how I understand HTTP Cache semantics.

I guess there's fertile ground here for making practical forward-looking
statements, for providing the current state and whatever you are willing
to convey about plans and expectations of future state.  ....  I guess
calendar events are a good use case here.  Organizers make statements
about the future at increasing levels of commitment as the date "firms
up", but still the event could be cancelled, with no loss of
reputation/honor given the right circumstances (eg a natural disaster).

Oh look, it's Fri Mar 28 12:18:13 EDT 2008 and I'm still in Belmont.

     - s

Received on Friday, 28 March 2008 16:19:34 UTC