Re: rdf semantics and timelessly true

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]
> 
> 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.

You make a great point here Henry, via HTTP we may not be able to 
accurately determine timeslices, however we can leverage ETags and 
modified times to associated triples/graphs with points in time, and as 
Pat pointed out we can think of time as being linear and discrete for 
most common application needs. When fuller knowledge is needed then we 
can turn to auditing request-response transactions (HTTP or SPARQL) and 
state changes on managed (/LDP) resources, and via changesets, or diffs. 
Many cases will also require cardinality restraints on properties I'd 
guess, or those changesets to determine that a triple has been replaced, 
rather than just added.

So perhaps it isn't always required to be modelled in the RDF, and 
common patterns can be codified and added to our systems in order to 
consider differing rdf snapshots from rdf sources on the web over time.

Thanks for talking this though to everybody who added input,

Nathan

> 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.
> 
>    https://blogs.oracle.com/bblfish/entry/temporal_relations
> 
> That means that one needs in the end notions of timeslices and mereological reasoning.
> 
> 
> [1] https://blogs.oracle.com/bblfish/entry/beatnik_change_your_mind
> 
> Social Web Architect
> http://bblfish.net/
>

Received on Thursday, 15 November 2012 00:25:00 UTC