Re: “SHACL Minus SPARQL”

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think that your method only works for certain shapes.

Consider, for example,
  a value of p is b
  AND
  a value of p is c OR a value of q is d

The closure filter here is a function of the entire shape.  If the shape
includes raw SPARQL code constructing the filter would require a semantic
analysis of the SPARQL code.


peter


On 03/04/2015 12:39 PM, Dimitris Kontokostas wrote:
> 
> 
> On Wed, Mar 4, 2015 at 5:38 PM, Richard Cyganiak <richard@cyganiak.de 
> <mailto:richard@cyganiak.de>> wrote:
> 
> 
>> On 4 Mar 2015, at 15:21, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>> 
>> Yes, I mean closed shapes, i.e., all triples in a graph (or around a
>> node) have to be somehow consumed by the shape.
>> 
>> I don't think that your idea of constructing the matched triples will
>> work in the presence of disjunction, at least without considerable code
>> embedded into the SPARQL engine.
> 
> You are probably right. I may investigate further if it is established 
> that someone can’t live without this feature.
> 
> 
> I think this is not so hard to check (unless I miss something) and
> depends on the semantics we give to disjunction (exclusive or not). I am
> using exclusive for the examples
> 
> Since the validation engine will check for the validity of the defined 
> properties we would only need an extra query for the closed shape
> checking, meaning no other properties exist other than the ones defined
> in the shape.
> 
> case 1: conjuctiveShape { ex:p1 [...] AND ex:p2 [...] AND ex:p3 [...] } 
> SELECT ?root WHERE ?root rdf:type/rdfs:subClassOf* <C1 > # or use the
> focus node here ?root ?p ?o FILTER ( ! (?p  IN (ex:p1, ex:p2, ex:p3)))
> 
> case 2: disjunctiveShapeSimple { (ex:p1 [...] OR  ex:p2 [...] OR ex:p3
> [...] )}
> 
> SELECT ?root WHERE ?root rdf:type/rdfs:subClassOf* <C1 > # or use the
> focus node here ?root ?p ?o FILTER ( ! ((?p  IN (ex:p1) && ?p NOT IN
> (ex:p2, ex:p3))  || (?p  IN (ex:p2) && ?p NOT IN (ex:p1 , ex:p3)) || (?p
> IN (ex:p3) && ?p NOT IN (ex:p1 , ex:p2)))
> 
> 
> case 3: disjunctiveShapeComplex { (ex:p1 [...] AND  ex:p2 [...]) OR
> (ex:p1 AND ex:p3 [...] )}
> 
> SELECT ?root WHERE ?root rdf:type/rdfs:subClassOf* <C1 > # or use the
> focus node here ?root ?p ?o FILTER ( ! ( (?p  IN (ex:p1, ex:p2) && ?p NOT
> IN (ex:p3))  || (?p  IN (ex:p1, ex:p3) && ?p NOT IN (ex:p2)))
> 
> Best, Dimitris
> 
> 
> Richard
> 
> 
>> 
>> peter
>> 
>> 
>> On 03/04/2015 06:37 AM, Richard Cyganiak wrote:
>>> 
>>>> On 3 Mar 2015, at 21:49, Peter F. Patel-Schneider 
>>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>> 
>>>> I would like to see the core of a proposal for something that
>>>> would support "SHACL minus SPARQL" as well as the core of a
>>>> proposal for "SHACL plus SPARQL".
>>>> 
>>>> I think that I could fairly easily put together a proposal for most
>>>> of the former, but I am puzzled as to how to handle recursion and
>>>> closure, so I would like to see how a proponent of this approach
>>>> would handle recursion or closure.
>>> 
>>> By closure, do you mean “closed shapes” as described here?
>>> 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
>
> 
>> 
>>> I’m not sure that this can be easily supported.
>>> 
>>> One way to do it might be to attach a second bit of SPARQL to each
>>> “macro definition”/“shape node”. That bit of SPARQL would CONSTRUCT
>>> the triples that are considered to be “covered” by a successful
>>> “macro”/“shape” evaluation. A SHACL processor would collect all those
>>> triples, and if any triples in the input RDF graph under
>>> consideration are not among those “covered”, then the closedness
>>> constraint is violated.
>>> 
>>> Personally I’m not fully convinced that this requirement is a good
>>> idea and necessary for SHACL 1.0, and there are many cases where I
>>> don’t know what the desired behaviour would be. I’d be quite
>>> comfortable with postponing this to a future version of SHACL.
>>> 
>>> My thoughts on recursion are too muddled to be of much help.
>>> 
>>> Best, Richard
>>> 
>>> 
>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
>> 
>> iQEcBAEBAgAGBQJU9yL2AAoJECjN6+QThfjzpCoH/0IqTnt8+4VL9f8Rbf/cyUhx 
>> dNWWS8Wn5snRN6cCJaZeLI4dQt/fa15jlG3/V2y+bZZQTWPnhBGBzr4Ti0g7rZP5 
>> KVDsnMflcCEU07yMjfvkXTPngvHwSUqdcwDu3pQ9hyYvSgE4SbY8Gp4aaFb8e7Sc 
>> FNUqd8u5SSE9XHf7zXGWW+9CBdiYBNSlt9Af3IyS6iuR2Iu8KNjlH4+4H4AApGlp 
>> m2O3HogHmEWqwysUpV9GXGYA6miwvXJ3+/ESvf0X2xhrzPXZ2v7LxbYuwtiDW2hl 
>> yKQIYPoVsYdFrrjZDsz5Fk2AL87LIxanaxBnw5dkmuRZ6sB47HkvKdNXsmPUpik= =bB9a 
>> -----END PGP SIGNATURE-----
> 
> 
> 
> 
> 
> 
> -- Dimitris Kontokostas Department of Computer Science, University of
> Leipzig Research Group: http://aksw.org 
> Homepage:http://aksw.org/DimitrisKontokostas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU957BAAoJECjN6+QThfjzE48H/RV6aC/JWyFipTHGuqt+zHK0
cRfAt6epcXoVN8n0r29uN5UU3Zq9P0vMfFDiJSKZA9gzYvpditMFWCHt255pIdB8
OLRLXgHTALI1f65Bed+KAvxk5QiL1zpjYpRlgT8xSGCd3LwqgxnClYrYpmm39grH
upFcYEoD7vraIPfEAvcbjn0HtO91t6Ifay78wOwS5FYxLtSLD33jjZ8XoSnp4K1s
nVHfe+JhGpr1g9yoWfYl8zHHLo9JBz696kpaYqznUN3Wo2lJTNRPxVo9i/2p9kid
I9Q7NJi6uirjXHmrzcT020zGpFvvG43/tPjgwUn9cwl89+b0Yj0xLkLGDtSGhrU=
=5SWT
-----END PGP SIGNATURE-----

Received on Thursday, 5 March 2015 00:10:11 UTC