Re: “SHACL Minus SPARQL”

On Mar 5, 2015 2:09 AM, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:
>
> -----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
>

I don't understand this shape, I think this should always fail unless b and
c are equal.

> 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.

You are right about SPARQL, it never occurred to me that we would allow it
in closed shapes.

>
>
> 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-----
>