Re: “SHACL Minus SPARQL”

On Wed, Mar 4, 2015 at 5:38 PM, Richard Cyganiak <richard@cyganiak.de>
wrote:

>
> > On 4 Mar 2015, at 15:21, Peter F. Patel-Schneider <
> 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> 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