Re: rdf semantics and timelessly true

On Nov 14, 2012, at 9:42 AM, Henry Story wrote:

> 
> On 14 Nov 2012, at 17:42, Nathan <nathan@webr3.org> wrote:
> 
>> Pat Hayes wrote:
>>> On Nov 14, 2012, at 8:03 AM, Nathan wrote:
>>>> Hi Pat,
>>>> 
>>>> Pat Hayes wrote:
>>>>> Its not impossible, and in a strong sense this is required by the current RDF semantics, which treats all RDF assertions as timelessly true.
>>>> Can you refine / expand on this please? I'd presumed RDF to have no consideration of time - e.g time-less; as opposed to being true for all time (timeless).
>>>> 
>>>> TIA,
>>>> 
>>>> Nathan
>>> Yes, time-less is a better way to put it. But it is so because URIreferences are assumed (and I know this is an idealization, but...) to be timeless in how they refer. Section 1.2 says:  "... the semantics simply assumes that ... a single URI reference can be taken to have the same meaning wherever it occurs. Similarly, the semantics has no special provision for tracking temporal changes. It assumes, implicitly, that URI references have the same meaning whenever they occur."
>>> In other words, no counters allowed. 
>> 
>> What about any data that changes? if <http://webr3.org/nathan#me> refers to "me", and I change my name from Nathan to Bob, then I cannot update my RDF to reflect this? or perhaps more realistically, my email address?
> 
> You need to distinguish between the context free truth of RDF semantics - which is what makes it possible to have very simple graph merging algorithms, and the separate decision about whether you trust some source of information and for how long [1]

I agree, these are two different issues. True, data does get updated and needs to be changed. But the difference is between treating this is a genuine *change*, requiring what one might call data surgery, and treating it as a normal part of the data processing, something to be integrated into the normal course of processing and modelling. RDF is built on the assumption that *normal* data operations are timeless, so if you want to talk about states, you have to actually talk about them and their times, not just assume that RDF is going to move along with you as your state changes. Put another way, RDF data is presumed to be stateless: it has no dynamics. 

> 
> HTTP headers give you information about how long a representation is valid for so that is one thing to take into account. You may also change your mind about whome to trust.

Quite.

> 
> But there is also an issue of good modelling. Relations and ontologies should I think create atemporal 
> relations. I don't think many people are aware of this issue. One can always map from one to another if one has the right context - but then we have a temporal context which won't allow rdf reasoning to function correctly I think.

Actually, RDF reasoning works fine within a single temporal context, but RDF has (currenlty) no provision for relating information between or across contexts. And there is the background idea that RDF is intended for publishing data on the Web, where the reader of the data might well have no way to know what the (implict) context of the data was when it was published. So contextual information should be made explicit, in an ideal RDF world. 

> 
>   https://blogs.oracle.com/bblfish/entry/temporal_relations
> 
> That means that one needs in the end notions of timeslices and mereological reasoning.

Timeslices is one way to deal with time (my personal favorite :-) but I don't see that it requires mereology. One can just asume that times are linearly ordered and discrete, for example. That works for virtually all real applications. 

Pat

> 
> 
> [1] https://blogs.oracle.com/bblfish/entry/beatnik_change_your_mind
> 
> Social Web Architect
> http://bblfish.net/
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 14 November 2012 18:12:34 UTC