Re: on determinism in SPARQL constraints

Hi again Peter,

This is an informal reply and not necessarily representing the views of the
WG.

I looked a bit further at the SPARQL spec and I found these official
functions: rand(), now(), UUID(), STRUUID().
Of course, there may be other similar user defined functions.

Since you raised this comment, do you have any specific suggestions on how
SHACL should work is such cases or a warning would be sufficient (for you)?

Dimitris

On Sun, Oct 2, 2016 at 11:39 AM, Dimitris Kontokostas <
kontokostas@informatik.uni-leipzig.de> wrote:

> Not necessarily, I could adjust my example similar to yours and run it
> near the midnight of Oct 9th.
>
> In general all functions that return values independent of the data graph,
> like rand or now may, in some cases, result in non deterministic validation
> scenarios.
>
> Dimitris
>
> Typed by thumb. Please forgive brevity, errors.
>
> On Oct 1, 2016 23:48, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
> wrote:
>
>> That's probably a separate issue as the different results would
>> (probably) be
>> produced by two different validations of a data graph.  In the case I
>> mention
>> below, the question is how often RAND is called during a single
>> validation of
>> a data graph.
>>
>> peter
>>
>>
>> On 10/01/2016 01:36 PM, Dimitris Kontokostas wrote:
>> > Thanks Peter,
>> >
>> > This is a good point but a possible constraint would be "an issue
>> should not
>> > be issued with a future date"
>> >
>> > given the following data graph:
>> >  ex:issue1 ex:issued "10-10-2016"^^xsd:date
>> >
>> > if we run the validation now we would get different results compared to
>> > running a validation with the exact same input after 10 days.
>> >
>> > How could we define a validation scenario to be deterministic but at
>> the same
>> > time allowing such cases?
>> > Requiring identical shapes and data graph would obviously not be enough
>> and we
>> > need to somehow introduce time, but not sure how.
>> >
>> > Best,
>> > Dimitris
>> >
>> > On Sat, Oct 1, 2016 at 3:25 AM, Peter F. Patel-Schneider
>> > <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>> >
>> >     What happens if a SPARQL query in SHACL is non-deterministic?  Is
>> there any
>> >     guarantee about when and how often SPARQL queries are processed to
>> produce a
>> >     query result?
>> >
>> >     For example are there any guarantees that
>> >
>> >     **prefixes, etc., as needed**
>> >
>> >     s:s1 rdf:type sh:Shape ;
>> >      sh:targetClass ex:c1 ;
>> >      sh:property [ sh:predicate ex:p1 ;
>> >                    sh:qualifiedMinCount 1 ; sh:qualifiedMaxCount 1 ;
>> >                    sh:qualifiedValueShape [
>> >                      sh:property [ sh:predicate ex:p2 ;
>> >                                    sh:shape s:s2 ] ] ] .
>> >
>> >     s:s2 rdf:type sh:Shape ;
>> >      sh:sparql [ sh:prefixes ex: ;
>> >       sh:select """SELECT $this WHERE {
>> >                  BIND ( ( RAND() * 25 )  AS ?r )
>> >                  FILTER ( STRLEN($this) < ?r ) }""" ] .
>> >
>> >     will never produce a violation on the data graph
>> >
>> >     PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#
>> >     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>>
>> >     PREFIX ex: <http://ex.org/>
>> >
>> >     ex:i1 rdf:type ex:c1 ;
>> >      ex:p1 [ ex:p2 ex:i3 ], [ ex:p2 ex:i3 ] .
>> >
>> >
>> >     Peter F. Patel-Schneider
>> >     Nuance Communications
>> >
>> >
>> >
>> >
>> > --
>> > Dimitris Kontokostas
>> > Department of Computer Science, University of Leipzig & DBpedia
>> Association
>> > Projects: http://dbpedia.org, http://rdfunit.aksw.org,
>> http://aligned-project.eu
>> > Homepage: http://aksw.org/DimitrisKontokostas
>> > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>> >
>>
>>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT

Received on Sunday, 2 October 2016 13:49:34 UTC