W3C home > Mailing lists > Public > semantic-web@w3.org > November 2012

Re: Incrementing a literal

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 13 Nov 2012 23:27:33 -0800
Cc: Semantic Web <semantic-web@w3.org>
Message-Id: <9DE83E5E-C4EB-4F72-AABB-285CCC324AA7@ihmc.us>
To: Sergey Larionov <s.larionov@rks.karelia.ru>

On Nov 13, 2012, at 9:43 PM, Sergey Larionov wrote:

> Henry, ok, time may be seen as continous (or is
> that a current consensus view from some leaders of
> thought). Still, when building the 'counter' ontology
> (or describing something that changes at all),
> can it make sense to somehow avoid the traditional 
> programming/overwriting thinking style like:
> update counter with value 1
> update counter with value 2
> update counter with value 3
> and instead just expand the knowledge by adding (no
> updating or deleting at all) new facts into knowledge
> system as they come:
> counter was 1 at timeA
> counter was 2 at timeB
> counter was 3 at timeC
> What is impossible here I fail to see?

Its not impossible, and in a strong sense this is required by the current RDF semantics, which treats all RDF assertions as timelessly true. However, there is a practical difficulty, which is that these 1/A 2/B .. sentences require a three-way relation between a counter, a value, and a time. And describing three-way relationships in RDF is awkward and artificial. One needs to do something like this:

Counterstate1 stateOf counter
Counterstate1 hasValue 1
Counterstate1 atTime A

Counterstate2 stateOf counter
Counterstate2 hasValue 2
Counterstate2 atTime B

Whereas the simpler representation, which records simply the value of a counter, is a binary relationship which is trivially easy to represent as a single RDF triple:

Counter hasValue <current value of the counter>

and so people, not surprisingly, tend to use that simpler, more natural, form of representation; even when it is, strictly, in violation of the RDF specs. 

Pat Hayes

> Is it difficult
> to query the 'current' value of a counter from such a
> (corresponding) set of triples using the currently
> available semantic web tools?
>>> Melvin, may I propose an opinion that 'needing to
>>> update a value' seems like a design flaw. Why? Taking
>>> your particular example of incrementing a 'counter'
>>> variable which goes from 1 to 2 to 3 and further on,
>>> on each step there actually *was* a time/state when
>>> 'counter' contained each of it's values. And at that
>>> time/state conclusions could be made which were based
>>> on *that* particular value. Updating seems like
>>> effectively erasing the history.
>>> Now what is 'current value' as it obviously should
>>> have some means to be changed? Well 'current value' 
>>> seems like a result of a function taking a specific
>>> 'current' time as an input. Current time is an observer's 
>>> context property. So may an answer to your question 
>>> contain a suggestion to store all the values for a 
>>> counter with their relevant time frame attributes 
>>> and obtain 'current' value using a query? SL
>> that is impossible since time is continuous and between any 
>> two times there are infinite number of more time slots. You
>> would need temporal reasoning and mereological reasoning to do
>> this. Those tools are not available yet.
>>>> Is there a pattern for incrementing a literal counter?
>>>> Alice stores turtle in http://example.org/counter
>>>> The initial operation should generate something like
>>>> <#> <#counter> 1.
>>>> Then the subsequent operation
>>>> <#> <#counter> 2.
>>>> And after that.
>>>> <#> <#counter> 3.
>>>> And so on ...
>>>> Is there a neat way to do this in  distributed way?  SPARQL update?   Maybe using Etags?   

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 07:28:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:50:14 UTC