Re: “SHACL Minus SPARQL”

On Thu, Mar 5, 2015 at 7:57 AM, Dimitris Kontokostas <
kontokostas@informatik.uni-leipzig.de> wrote:

>
> 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.
>
I see they should not be equal but one restricting to a subset of the other
e.g. b: minCount=1 and c: minCount=2

in that case the same algorithm can apply. if we convert the expression to
DNF it could be (p AND p) OR (p AND q).
(Haven't thought of CNF forms but there should be an equivalent expression
for that)

and the filter will be
FILTER ( ! ((?p  IN (ex:p) && ?p NOT IN (ex:q))  || (?p  IN (ex:p, ex:q) )

in this case, with some extra processing of the expression we could just
require
FILTER ( ! (?p  IN (ex:p, ex:q) )

Note the values of p and q are checked separately, here we check only if
properties besides the ones defined in the shape exist



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



-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas