Re: Incrementing a literal

Yes, you can use SPARQL Update to safely update a counter. Here's the code 
I used in an app. 

Suppose you have a resource, <http://example.com/query>, stored in a named 
graph of the same name, and it has a counter defined by a predicate 
:nextIdentifier, e.g. if the counter is 42 you have the following triple.

<http://example.com/query> :nextIdentifier 42 .

Run the following update to safely increment the counter to 43.

base <http://example.com/>

prefix :  <http://example.com/ns#>

delete {
        graph <query> {
                <query> :nextIdentifier ?nextIdentifier .
        }
}
insert {
        graph <query> {
                <query> :nextIdentifier ?nextIdentifier1 .
        }
}
where {

        graph <query> {
                <query> :nextIdentifier ?nextIdentifier .
        }
 
        bind (?nextIdentifier + 1 as ?nextIdentifier1) .
}

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational 

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:   "Stephen D. Williams" <sdw@lig.net>
To:     semantic-web@w3.org, 
Date:   11/14/2012 02:49 AM
Subject:        Re: Incrementing a literal



What happens when agent A and B try to update the same counter at the same 
or nearly the same time?
Single threaded, locking for transaction systems aren't scalable and have 
some other negatives, although they 

On the other hand, in many circumstances, rather than updating values, 
adding new knowledge is the way to solve the problem.  Things like totals 
or counts can be considered the results of a query.

On the other other hand, computing / caching / knowing facts resulting 
from applying a rule isn't necessarily that far from a semantic web 
database.  

sdw

On 11/13/12 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? 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?

Received on Wednesday, 14 November 2012 15:18:55 UTC