Re: RDF triple assertions live forever?

Interesting - and I quite see what you're saying (however long Ivan may 
have to drum his fingers waiting for you to turn up for lunch...)

The relevant niche for POWDER is "ACME testing claims that all resources 
on example.org are mobileOK/child safe/accessible/about Cambridge 
restaurants - and if they're not, you can call us and complain as long 
as today's date is before 31st December 2008" [1]

Which, is a very different app to data describing an individual's 
whereabouts, or the validity of a statement like "the phone number at 
Symphony Hall is..."

So, yes, it's a niche. In that regard, it sounds as if we're on the 
right track to be creating a predicate of validUntil that is within the 
POWDER namespace  - but it would be wrong to claim that the relevant 
semantic extension has broad applicability to other uses of RDF/OWL.

Phil.

(who, given the time difference, is confident in saying that he'll be 
away from his computer and becoming intimate with a pint of something 
within the hour).

[1] http://www.w3.org/TR/2008/WD-powder-dr-20080317/#certification

Sandro Hawke wrote:
> [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:50:20 UTC