Re: Incrementing a literal

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