Re: SHACL

[Beaudet, David]

Paul, I started writing a validator for Linked Art a couple of years ago that 
has some SHACL examples you might find useful.

https://github.com/linked-art/shacl-validator

- Dave Beaudet


On Apr 6, 2024 12:52, Paul Tyson  wrote:
This is old, but might be useful. It has a chapter on SHACL.

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbook.validatingrdf.com%2F&data=05%7C02%7C%7Cf8969d026af84604b08108dc5659f16c%7C53f6461e95ad4b08a8da973e49ae9312%7C0%7C0%7C638480191519535786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=dLNK8hNKKXKteItrBE0AkGgc05iFqqvm1B1q27CqcT0%3D&reserved=0<https://book.validatingrdf.com/>

Regards,
--Paul

On 4/5/24 04:58, Hashim Khan wrote:
> Hi,
>   I am interested in working with SHACL shapes for validation. I would
> like to know if someone  points out a nice resource.
>
> Best,
>

Re: SHACL

[Paul Tyson]

This is old, but might be useful. It has a chapter on SHACL.

https://book.validatingrdf.com/

Regards,
--Paul

On 4/5/24 04:58, Hashim Khan wrote:

Hi,
  I am interested in working with SHACL shapes for validation. I would
like to know if someone  points out a nice resource.

Best,

Re: SHACL

[Hashim Khan]

Thanks a lot. It is really helpful.

Regards,

On Fri, Apr 5, 2024 at 2:49 PM Arne Bernhardt 
wrote:

> Hi Hashim,
>
> In addition to the official Apache Jena SHACL documentation at
> https://jena.apache.org/documentation/shacl/,
> I've found these slides to be quite insightful for an overview:
> https://www.slideshare.net/irenetq/shacl-overview.
>
> For hands-on practice, the SHACL Playground (https://shacl.org/playground/
> )
> might be helpful to experiment with SHACL shapes and see real-time results.
> (although it does not run with Apache Jena and has a number of "known
> issues" listed at the bottom of the site)
>
> Does this cover what you're looking for?
>
>   Arne
>
> Am Fr., 5. Apr. 2024 um 11:58 Uhr schrieb Hashim Khan <
> engr.hashimwa...@gmail.com>:
>
> > Hi,
> >  I am interested in working with SHACL shapes for validation. I would
> > like to know if someone  points out a nice resource.
> >
> > Best,
> >
> > --
> > *Hashim Khan*
> >
>


-- 
*Hashim Khan*

Re: SHACL

[Arne Bernhardt]

Hi Hashim,

In addition to the official Apache Jena SHACL documentation at
https://jena.apache.org/documentation/shacl/,
I've found these slides to be quite insightful for an overview:
https://www.slideshare.net/irenetq/shacl-overview.

For hands-on practice, the SHACL Playground (https://shacl.org/playground/)
might be helpful to experiment with SHACL shapes and see real-time results.
(although it does not run with Apache Jena and has a number of "known
issues" listed at the bottom of the site)

Does this cover what you're looking for?

  Arne

Am Fr., 5. Apr. 2024 um 11:58 Uhr schrieb Hashim Khan <
engr.hashimwa...@gmail.com>:

> Hi,
>  I am interested in working with SHACL shapes for validation. I would
> like to know if someone  points out a nice resource.
>
> Best,
>
> --
> *Hashim Khan*
>

SHACL

[Hashim Khan]

Hi,
 I am interested in working with SHACL shapes for validation. I would
like to know if someone  points out a nice resource.

Best,

-- 
*Hashim Khan*

Re: Checking that SPARQL Update will not validate SHACL constraints

[Martynas Jusevičius]

Arne’s email got lost somehow but I see it in Andy’s reply.

Thanks for the suggestions.

On Wed, 13 Dec 2023 at 19.52, Andy Seaborne  wrote:

>
>
> On 13/12/2023 15:49, Arne Bernhardt wrote:
> > Hello Martynas,
> >
> > I have no experience with implementing a validation layer for Fuseki.
> >
> > But I might have an idea for your suggested approach:
> > Instead of loading a copy of the graph and modifying it, you could create
> > an org.apache.jena.graph.compose.Delta based on the unmodified graph.
> > Then apply the update to the delta graph and validate the SHACL on the
> > delta graph. If the validation is successful, you can safely apply the
> > update to the original graph and discard the delta graph.
> >
> > You still have to deal with concurrency. For example, the original graph
> > could be changed by a second, faster update while you are still
> validating
> > the first update. It would not be safe to apply the validated changes to
> a
> > graph that has been changed in the meantime.
> >
> > Arne
>
> It'll depends in the SHACL. Many constraints don't need all the data
> available. Some need just the subject and all properties (e.g.
> sh:maxCount). Some need all the data (SPARQL ones - they are opaque to
> analysis so the general way is they need all the data).
>
> If the proxy layer is same JVM, BufferingDatasetGraph may help.
> It can be used to capture the adds and deletes. It can then be validated
> (all data or only the data changing). Flush the changes to the database
> just before the end of the request in the proxy level commit.
>
> If the proxy is in a different JVM, then only certain constraints can be
> supported but they do tend to be the most common checks.
>
>  Andy
>
> >
> >
> >
> >
> > Am Mi., 13. Dez. 2023 um 14:29 Uhr schrieb Martynas Jusevičius <
> > marty...@atomgraph.com>:
> >
> >> Hi,
> >>
> >> I have an objective to only persist constraint-validated data in Fuseki.
> >>
> >> I have a proxy layer that validates all incoming GSP PUT and POST
> >> request graphs in memory and rejects the invalid ones. So far so good.
> >>
> >> What about SPARQL Update requests though? For simplicity's sake, let's
> >> say they are restricted to a single graph as in GSP PATCH [1].
> >> What I can think of is first loading the graph into memory and
> >> executing the update, and then validating the resulting graph against
> >> SHACL. But maybe there's a smarter way?
> >>
> >> Also interested in the more general case without the graph restriction.
> >>
> >> Martynas
> >>
> >> [1] https://www.w3.org/TR/sparql11-http-rdf-update/#http-patch
> >>
> >
>

Re: Checking that SPARQL Update will not validate SHACL constraints

[Andy Seaborne]

On 13/12/2023 15:49, Arne Bernhardt wrote:

Hello Martynas,

I have no experience with implementing a validation layer for Fuseki.

But I might have an idea for your suggested approach:
Instead of loading a copy of the graph and modifying it, you could create
an org.apache.jena.graph.compose.Delta based on the unmodified graph.
Then apply the update to the delta graph and validate the SHACL on the
delta graph. If the validation is successful, you can safely apply the
update to the original graph and discard the delta graph.

You still have to deal with concurrency. For example, the original graph
could be changed by a second, faster update while you are still validating
the first update. It would not be safe to apply the validated changes to a
graph that has been changed in the meantime.

Arne


It'll depends in the SHACL. Many constraints don't need all the data 
available. Some need just the subject and all properties (e.g. 
sh:maxCount). Some need all the data (SPARQL ones - they are opaque to 
analysis so the general way is they need all the data).


If the proxy layer is same JVM, BufferingDatasetGraph may help.
It can be used to capture the adds and deletes. It can then be validated 
(all data or only the data changing). Flush the changes to the database 
just before the end of the request in the proxy level commit.


If the proxy is in a different JVM, then only certain constraints can be 
supported but they do tend to be the most common checks.


Andy






Am Mi., 13. Dez. 2023 um 14:29 Uhr schrieb Martynas Jusevičius <
marty...@atomgraph.com>:


Hi,

I have an objective to only persist constraint-validated data in Fuseki.

I have a proxy layer that validates all incoming GSP PUT and POST
request graphs in memory and rejects the invalid ones. So far so good.

What about SPARQL Update requests though? For simplicity's sake, let's
say they are restricted to a single graph as in GSP PATCH [1].
What I can think of is first loading the graph into memory and
executing the update, and then validating the resulting graph against
SHACL. But maybe there's a smarter way?

Also interested in the more general case without the graph restriction.

Martynas

[1] https://www.w3.org/TR/sparql11-http-rdf-update/#http-patch

Re: Checking that SPARQL Update will not validate SHACL constraints

[Arne Bernhardt]

Hello Martynas,

I have no experience with implementing a validation layer for Fuseki.

But I might have an idea for your suggested approach:
Instead of loading a copy of the graph and modifying it, you could create
an org.apache.jena.graph.compose.Delta based on the unmodified graph.
Then apply the update to the delta graph and validate the SHACL on the
delta graph. If the validation is successful, you can safely apply the
update to the original graph and discard the delta graph.

You still have to deal with concurrency. For example, the original graph
could be changed by a second, faster update while you are still validating
the first update. It would not be safe to apply the validated changes to a
graph that has been changed in the meantime.

Arne




Am Mi., 13. Dez. 2023 um 14:29 Uhr schrieb Martynas Jusevičius <
marty...@atomgraph.com>:

> Hi,
>
> I have an objective to only persist constraint-validated data in Fuseki.
>
> I have a proxy layer that validates all incoming GSP PUT and POST
> request graphs in memory and rejects the invalid ones. So far so good.
>
> What about SPARQL Update requests though? For simplicity's sake, let's
> say they are restricted to a single graph as in GSP PATCH [1].
> What I can think of is first loading the graph into memory and
> executing the update, and then validating the resulting graph against
> SHACL. But maybe there's a smarter way?
>
> Also interested in the more general case without the graph restriction.
>
> Martynas
>
> [1] https://www.w3.org/TR/sparql11-http-rdf-update/#http-patch
>

Checking that SPARQL Update will not validate SHACL constraints

[Martynas Jusevičius]

Hi,

I have an objective to only persist constraint-validated data in Fuseki.

I have a proxy layer that validates all incoming GSP PUT and POST
request graphs in memory and rejects the invalid ones. So far so good.

What about SPARQL Update requests though? For simplicity's sake, let's
say they are restricted to a single graph as in GSP PATCH [1].
What I can think of is first loading the graph into memory and
executing the update, and then validating the resulting graph against
SHACL. But maybe there's a smarter way?

Also interested in the more general case without the graph restriction.

Martynas

[1] https://www.w3.org/TR/sparql11-http-rdf-update/#http-patch

Re: Executing SHACL over Fuseki dataset

[Martynas Jusevičius]

Thanks Øyvind, that looks promising.

On Tue, Jun 6, 2023 at 11:58 AM Øyvind Gjesdal  wrote:
>
> I haven't tried it, but it looks like it is implemented, and you can
> configure a SHACL service on datasets, in the assembler for Fuseki.
> https://jena.apache.org/documentation/shacl/#integration-with-apache-jena-fuseki
>
>
> You can then use the api and post shapes as files for validating datasets:
>
> The example from the documentation :
>
> curl -XPOST --data-binary @fu-shapes.ttl  \
>  --header 'Content-type: text/turtle' \
>  'http://localhost:3030/ds/shacl?graph=default'
>
> Best regards,
> Øyvind
>
>
> On Tue, Jun 6, 2023 at 11:27 AM Martynas Jusevičius 
> wrote:
>
> > Hi,
> >
> > What is the approach to validating data stored in Fuseki with SHACL?
> > Without having to retrieve a data dump first.
> >
> > I have found some generic projects that claim to translate SHACL to SPARQL:
> > https://github.com/rdfshapes/shacl-sparql
> > https://github.com/Shape-Fragments/SHACL2SPARQL
> > Has anyone had any luck with them?
> >
> > I was wondering if a Jena-based solution would be feasible and what
> > would it take.
> >
> >
> > Martynas
> >

Re: Executing SHACL over Fuseki dataset

[Øyvind Gjesdal]

I haven't tried it, but it looks like it is implemented, and you can
configure a SHACL service on datasets, in the assembler for Fuseki.
https://jena.apache.org/documentation/shacl/#integration-with-apache-jena-fuseki


You can then use the api and post shapes as files for validating datasets:

The example from the documentation :

curl -XPOST --data-binary @fu-shapes.ttl  \
 --header 'Content-type: text/turtle' \
 'http://localhost:3030/ds/shacl?graph=default'

Best regards,
Øyvind


On Tue, Jun 6, 2023 at 11:27 AM Martynas Jusevičius 
wrote:

> Hi,
>
> What is the approach to validating data stored in Fuseki with SHACL?
> Without having to retrieve a data dump first.
>
> I have found some generic projects that claim to translate SHACL to SPARQL:
> https://github.com/rdfshapes/shacl-sparql
> https://github.com/Shape-Fragments/SHACL2SPARQL
> Has anyone had any luck with them?
>
> I was wondering if a Jena-based solution would be feasible and what
> would it take.
>
>
> Martynas
>

Executing SHACL over Fuseki dataset

[Martynas Jusevičius]

Hi,

What is the approach to validating data stored in Fuseki with SHACL?
Without having to retrieve a data dump first.

I have found some generic projects that claim to translate SHACL to SPARQL:
https://github.com/rdfshapes/shacl-sparql
https://github.com/Shape-Fragments/SHACL2SPARQL
Has anyone had any luck with them?

I was wondering if a Jena-based solution would be feasible and what
would it take.


Martynas

Re: [SHACL] sh:prefixes

[Andy Seaborne]

Could you add it to the formal errata list?  It does not appear to be 
listed at


https://github.com/w3c/data-shapes/issues?q=is%3Aissue+is%3Aopen+label%3AErrata

It helps make the case for work to be done.

> go into that document and fix it

The SHACL CG can publish a revised document as a CG report. While this 
does not replace the REC, it is a way forward - other specs proceed like 
this.


Part of RDF-star WG charter to update specs and also prepare for "living 
standards". SHACL is not on the list but _maybe_ ...


* if it is a small amount of work

* if there is a list of errata so any adding SHACL has known costs.
  Anything open-ended is unlikely to get any traction.
  A CG report is evidence of this.

* There needs to be one or more people to do the work.

In theory, changes to documents in-scope for RDF-star WG can be done by 
by PRs from anyone who is able to sign the necessary IP agreement. It is 
not necessarily only RDF-star WG members make contributions; someone on 
the WG could shepherd it.


Andy



On 28/02/2023 13:26, Holger Knublauch wrote:

I know, almost everybody stumbles there. It was bad editing by the editor :)

Unfortunately I cannot just go into that document and fix it. That's the bane 
of these formal specs, and why many people get work done quicker outside of 
such formal processes.

Holger

Re: [SHACL] sh:prefixes

[Holger Knublauch]

I know, almost everybody stumbles there. It was bad editing by the editor :)

Unfortunately I cannot just go into that document and fix it. That's the bane 
of these formal specs, and why many people get work done quicker outside of 
such formal processes.

Holger


> On 28 Feb 2023, at 1:24 pm, Martynas Jusevičius  
> wrote:
> 
> Thanks Holger, that is the case :) The "sh:prefixes ex:" in the SHACL spec 
> was somewhat confusing without context, because it looks like a Turtle prefix 
> declaration.
> 
> This works:
> 
> :prefixes sh:declare [
> sh:prefix "skos" ;
> sh:namespace "http://www.w3.org/2004/02/skos/core#"^^xsd:anyURI ;
> ] .
> 
> <#ConceptBroaderCycleShape> sh:prefixes :prefixes ;
> 
> 
> On Tue, Feb 28, 2023 at 2:16 PM Holger Knublauch  <mailto:hol...@topquadrant.com>> wrote:
>> I suspect this is another instance of the common misunderstanding: the 
>> @prefix declarations are not mapped to any triples and are only a concept of 
>> the serialization. To make them visible to SHACL, you need to declare 
>> triples such as in
>> 
>> Shapes Constraint Language (SHACL)
>> w3.org
>> 
>>  <https://www.w3.org/TR/shacl/#sparql-prefixes>Shapes Constraint Language 
>> (SHACL) <https://www.w3.org/TR/shacl/#sparql-prefixes>
>> w3.org <https://www.w3.org/TR/shacl/#sparql-prefixes> 
>> <https://www.w3.org/TR/shacl/#sparql-prefixes>
>> in your case it would be skos: as subject.
>> 
>> Holger
>> 
>> 
>>> On 28 Feb 2023, at 12:56 pm, Martynas Jusevičius >> <mailto:marty...@atomgraph.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Does Jena's SHACL engine support sh:prefixes? Or am I using them wrong?
>>> 
>>> The following test shape
>>> 
>>> @prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
>>> @prefix sh: <http://www.w3.org/ns/shacl#> .
>>> 
>>> <#ConceptBroaderCycleShape>
>>>a sh:NodeShape ;
>>>sh:targetClass skos:Concept ;
>>>sh:sparql [
>>>a sh:SPARQLConstraint ;
>>>sh:message "Concept is broader than itself (directly or indirectly)" 
>>> ;
>>>sh:prefixes skos: ;
>>>sh:select """
>>>SELECT *
>>>{
>>>$this skos:broader+ $this .
>>>}
>>>""" ;
>>>] .
>>> 
>>> returns an error:
>>> 
>>> org.apache.jena.shacl.parser.ShaclParseException: Bad query: Line 5,
>>> column 23: Unresolved prefixed name: skos:broader
>>> at org.apache.jena.shacl.lib.ShLib.parseQueryString(ShLib.java:262)
>>> at org.apache.jena.shacl.lib.ShLib.extractSPARQLQuery(ShLib.java:270)
>>> at 
>>> org.apache.jena.shacl.engine.SparqlConstraints.parseSparqlConstraint(SparqlConstraints.java:64)
>>> at 
>>> org.apache.jena.shacl.parser.Constraints.lambda$static$20(Constraints.java:116)
>>> at 
>>> org.apache.jena.shacl.parser.Constraints.parseConstraint(Constraints.java:176)
>>> at 
>>> org.apache.jena.shacl.parser.Constraints.parseConstraints(Constraints.java:160)
>>> at 
>>> org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:319)
>>> at 
>>> org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
>>> at 
>>> org.apache.jena.shacl.parser.ShapesParser.parseShape(ShapesParser.java:236)
>>> at 
>>> org.apache.jena.shacl.parser.ShapesParser.parseShapeAcc(ShapesParser.java:221)
>>> at 
>>> org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:163)
>>> at 
>>> org.apache.jena.shacl.parser.ShapesParser.parseProcess(ShapesParser.java:100)
>>> at org.apache.jena.shacl.Shapes.parseProcess(Shapes.java:111)
>>> at org.apache.jena.shacl.Shapes.parseAll(Shapes.java:106)
>>> at org.apache.jena.shacl.Shapes.parse(Shapes.java:83)
>>> at 
>>> org.apache.jena.shacl.validation.ShaclPlainValidator.parse(ShaclPlainValidator.java:38)
>>> at 
>>> org.apache.jena.shacl.validation.ShaclPlainValidator.validate(ShaclPlainValidator.java:90)
>>> at shacl.shacl_validate.exec(shacl_validate.java:124)
>>> at org.apache.jena.cmd.CmdMain.mainMethod(CmdMain.java:87)
>>> at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:56)
>>> at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:43)
>>> at shacl.shacl_validate.main(shacl_validate.java:60)
>>> at shacl.shacl.main(shacl.java:81)
>>> 
>>> 
>>> Martynas
>> 

Re: [SHACL] sh:prefixes

[Martynas Jusevičius]

Thanks Holger, that is the case :) The "sh:prefixes ex:" in the SHACL spec
was somewhat confusing without context, because it looks like a Turtle
prefix declaration.

This works:

:prefixes sh:declare [
sh:prefix "skos" ;
sh:namespace "http://www.w3.org/2004/02/skos/core#"^^xsd:anyURI ;
] .

<#ConceptBroaderCycleShape> sh:prefixes :prefixes ;


On Tue, Feb 28, 2023 at 2:16 PM Holger Knublauch 
wrote:

> I suspect this is another instance of the common misunderstanding: the
> @prefix declarations are not mapped to any triples and are only a concept
> of the serialization. To make them visible to SHACL, you need to declare
> triples such as in
>
> Shapes Constraint Language (SHACL)
> <https://www.w3.org/TR/shacl/#sparql-prefixes>
> w3.org <https://www.w3.org/TR/shacl/#sparql-prefixes>
> [image: favicon.ico] <https://www.w3.org/TR/shacl/#sparql-prefixes>
> <https://www.w3.org/TR/shacl/#sparql-prefixes>
>
> in your case it would be skos: as subject.
>
> Holger
>
>
> On 28 Feb 2023, at 12:56 pm, Martynas Jusevičius 
> wrote:
>
> Hi,
>
> Does Jena's SHACL engine support sh:prefixes? Or am I using them wrong?
>
> The following test shape
>
> @prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
> @prefix sh: <http://www.w3.org/ns/shacl#> .
>
> <#ConceptBroaderCycleShape>
>a sh:NodeShape ;
>sh:targetClass skos:Concept ;
>sh:sparql [
>a sh:SPARQLConstraint ;
>sh:message "Concept is broader than itself (directly or
> indirectly)" ;
>sh:prefixes skos: ;
>sh:select """
>SELECT *
>{
>$this skos:broader+ $this .
>}
>""" ;
>] .
>
> returns an error:
>
> org.apache.jena.shacl.parser.ShaclParseException: Bad query: Line 5,
> column 23: Unresolved prefixed name: skos:broader
> at org.apache.jena.shacl.lib.ShLib.parseQueryString(ShLib.java:262)
> at org.apache.jena.shacl.lib.ShLib.extractSPARQLQuery(ShLib.java:270)
> at
> org.apache.jena.shacl.engine.SparqlConstraints.parseSparqlConstraint(SparqlConstraints.java:64)
> at
> org.apache.jena.shacl.parser.Constraints.lambda$static$20(Constraints.java:116)
> at
> org.apache.jena.shacl.parser.Constraints.parseConstraint(Constraints.java:176)
> at
> org.apache.jena.shacl.parser.Constraints.parseConstraints(Constraints.java:160)
> at
> org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:319)
> at
> org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
> at
> org.apache.jena.shacl.parser.ShapesParser.parseShape(ShapesParser.java:236)
> at
> org.apache.jena.shacl.parser.ShapesParser.parseShapeAcc(ShapesParser.java:221)
> at
> org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:163)
> at
> org.apache.jena.shacl.parser.ShapesParser.parseProcess(ShapesParser.java:100)
> at org.apache.jena.shacl.Shapes.parseProcess(Shapes.java:111)
> at org.apache.jena.shacl.Shapes.parseAll(Shapes.java:106)
> at org.apache.jena.shacl.Shapes.parse(Shapes.java:83)
> at
> org.apache.jena.shacl.validation.ShaclPlainValidator.parse(ShaclPlainValidator.java:38)
> at
> org.apache.jena.shacl.validation.ShaclPlainValidator.validate(ShaclPlainValidator.java:90)
> at shacl.shacl_validate.exec(shacl_validate.java:124)
> at org.apache.jena.cmd.CmdMain.mainMethod(CmdMain.java:87)
> at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:56)
> at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:43)
> at shacl.shacl_validate.main(shacl_validate.java:60)
> at shacl.shacl.main(shacl.java:81)
>
>
> Martynas
>
>
>

Re: [SHACL] sh:prefixes

[Holger Knublauch]

I suspect this is another instance of the common misunderstanding: the @prefix 
declarations are not mapped to any triples and are only a concept of the 
serialization. To make them visible to SHACL, you need to declare triples such 
as in

https://www.w3.org/TR/shacl/#sparql-prefixes
in your case it would be skos: as subject.

Holger


> On 28 Feb 2023, at 12:56 pm, Martynas Jusevičius  
> wrote:
> 
> Hi,
> 
> Does Jena's SHACL engine support sh:prefixes? Or am I using them wrong?
> 
> The following test shape
> 
> @prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
> @prefix sh: <http://www.w3.org/ns/shacl#> .
> 
> <#ConceptBroaderCycleShape>
>a sh:NodeShape ;
>sh:targetClass skos:Concept ;
>sh:sparql [
>a sh:SPARQLConstraint ;
>sh:message "Concept is broader than itself (directly or indirectly)" ;
>sh:prefixes skos: ;
>sh:select """
>SELECT *
>{
>$this skos:broader+ $this .
>}
>""" ;
>] .
> 
> returns an error:
> 
> org.apache.jena.shacl.parser.ShaclParseException: Bad query: Line 5,
> column 23: Unresolved prefixed name: skos:broader
> at org.apache.jena.shacl.lib.ShLib.parseQueryString(ShLib.java:262)
> at org.apache.jena.shacl.lib.ShLib.extractSPARQLQuery(ShLib.java:270)
> at 
> org.apache.jena.shacl.engine.SparqlConstraints.parseSparqlConstraint(SparqlConstraints.java:64)
> at 
> org.apache.jena.shacl.parser.Constraints.lambda$static$20(Constraints.java:116)
> at 
> org.apache.jena.shacl.parser.Constraints.parseConstraint(Constraints.java:176)
> at 
> org.apache.jena.shacl.parser.Constraints.parseConstraints(Constraints.java:160)
> at 
> org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:319)
> at 
> org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
> at org.apache.jena.shacl.parser.ShapesParser.parseShape(ShapesParser.java:236)
> at 
> org.apache.jena.shacl.parser.ShapesParser.parseShapeAcc(ShapesParser.java:221)
> at 
> org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:163)
> at 
> org.apache.jena.shacl.parser.ShapesParser.parseProcess(ShapesParser.java:100)
> at org.apache.jena.shacl.Shapes.parseProcess(Shapes.java:111)
> at org.apache.jena.shacl.Shapes.parseAll(Shapes.java:106)
> at org.apache.jena.shacl.Shapes.parse(Shapes.java:83)
> at 
> org.apache.jena.shacl.validation.ShaclPlainValidator.parse(ShaclPlainValidator.java:38)
> at 
> org.apache.jena.shacl.validation.ShaclPlainValidator.validate(ShaclPlainValidator.java:90)
> at shacl.shacl_validate.exec(shacl_validate.java:124)
> at org.apache.jena.cmd.CmdMain.mainMethod(CmdMain.java:87)
> at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:56)
> at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:43)
> at shacl.shacl_validate.main(shacl_validate.java:60)
> at shacl.shacl.main(shacl.java:81)
> 
> 
> Martynas

Re: [SHACL] sh:prefixes

[Andy Seaborne]

Is there something in the WG test suite for this?

Andy

On 28/02/2023 12:56, Martynas Jusevičius wrote:

Hi,

Does Jena's SHACL engine support sh:prefixes? Or am I using them wrong?

The following test shape

@prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

<#ConceptBroaderCycleShape>
 a sh:NodeShape ;
 sh:targetClass skos:Concept ;
 sh:sparql [
 a sh:SPARQLConstraint ;
 sh:message "Concept is broader than itself (directly or indirectly)" ;
 sh:prefixes skos: ;
 sh:select """
 SELECT *
 {
 $this skos:broader+ $this .
 }
 """ ;
 ] .

returns an error:

org.apache.jena.shacl.parser.ShaclParseException: Bad query: Line 5,
column 23: Unresolved prefixed name: skos:broader
at org.apache.jena.shacl.lib.ShLib.parseQueryString(ShLib.java:262)
at org.apache.jena.shacl.lib.ShLib.extractSPARQLQuery(ShLib.java:270)
at 
org.apache.jena.shacl.engine.SparqlConstraints.parseSparqlConstraint(SparqlConstraints.java:64)
at 
org.apache.jena.shacl.parser.Constraints.lambda$static$20(Constraints.java:116)
at 
org.apache.jena.shacl.parser.Constraints.parseConstraint(Constraints.java:176)
at 
org.apache.jena.shacl.parser.Constraints.parseConstraints(Constraints.java:160)
at org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:319)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
at org.apache.jena.shacl.parser.ShapesParser.parseShape(ShapesParser.java:236)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeAcc(ShapesParser.java:221)
at org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:163)
at org.apache.jena.shacl.parser.ShapesParser.parseProcess(ShapesParser.java:100)
at org.apache.jena.shacl.Shapes.parseProcess(Shapes.java:111)
at org.apache.jena.shacl.Shapes.parseAll(Shapes.java:106)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:83)
at 
org.apache.jena.shacl.validation.ShaclPlainValidator.parse(ShaclPlainValidator.java:38)
at 
org.apache.jena.shacl.validation.ShaclPlainValidator.validate(ShaclPlainValidator.java:90)
at shacl.shacl_validate.exec(shacl_validate.java:124)
at org.apache.jena.cmd.CmdMain.mainMethod(CmdMain.java:87)
at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:56)
at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:43)
at shacl.shacl_validate.main(shacl_validate.java:60)
at shacl.shacl.main(shacl.java:81)


Martynas

[SHACL] sh:prefixes

[Martynas Jusevičius]

Hi,

Does Jena's SHACL engine support sh:prefixes? Or am I using them wrong?

The following test shape

@prefix skos:   <http://www.w3.org/2004/02/skos/core#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

<#ConceptBroaderCycleShape>
a sh:NodeShape ;
sh:targetClass skos:Concept ;
sh:sparql [
a sh:SPARQLConstraint ;
sh:message "Concept is broader than itself (directly or indirectly)" ;
sh:prefixes skos: ;
sh:select """
SELECT *
{
$this skos:broader+ $this .
}
""" ;
] .

returns an error:

org.apache.jena.shacl.parser.ShaclParseException: Bad query: Line 5,
column 23: Unresolved prefixed name: skos:broader
at org.apache.jena.shacl.lib.ShLib.parseQueryString(ShLib.java:262)
at org.apache.jena.shacl.lib.ShLib.extractSPARQLQuery(ShLib.java:270)
at 
org.apache.jena.shacl.engine.SparqlConstraints.parseSparqlConstraint(SparqlConstraints.java:64)
at 
org.apache.jena.shacl.parser.Constraints.lambda$static$20(Constraints.java:116)
at 
org.apache.jena.shacl.parser.Constraints.parseConstraint(Constraints.java:176)
at 
org.apache.jena.shacl.parser.Constraints.parseConstraints(Constraints.java:160)
at org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:319)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:305)
at org.apache.jena.shacl.parser.ShapesParser.parseShape(ShapesParser.java:236)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeAcc(ShapesParser.java:221)
at org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:163)
at org.apache.jena.shacl.parser.ShapesParser.parseProcess(ShapesParser.java:100)
at org.apache.jena.shacl.Shapes.parseProcess(Shapes.java:111)
at org.apache.jena.shacl.Shapes.parseAll(Shapes.java:106)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:83)
at 
org.apache.jena.shacl.validation.ShaclPlainValidator.parse(ShaclPlainValidator.java:38)
at 
org.apache.jena.shacl.validation.ShaclPlainValidator.validate(ShaclPlainValidator.java:90)
at shacl.shacl_validate.exec(shacl_validate.java:124)
at org.apache.jena.cmd.CmdMain.mainMethod(CmdMain.java:87)
at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:56)
at org.apache.jena.cmd.CmdMain.mainRun(CmdMain.java:43)
at shacl.shacl_validate.main(shacl_validate.java:60)
at shacl.shacl.main(shacl.java:81)


Martynas

Re: Increasing verbosity of shacl cli tool to show sh:message or sh:resultMessage

[Lorenz Buehmann]

How do you decide on which part of the OR failed to print your expected 
message? I mean, technically also the first part lead to FALSE, so we 
could easily also decide on printing an assigned message to that part - 
doesn't exist in your case, but is also a reason why the validation fails.


Or do you expect all messages being propagated up to the root node which 
failed?


On 11.01.23 23:02, Kyle Lawlor-Bagcal wrote:

Hello,

I'm interested to know if there is a way to configure the apache jena 
shacl cli tool to output the values of sh:message or sh:resultMessage. 
I have a property shape where I tried adding contextual info into 
sh:message/sh:resultMessage. I would like to see this info in the 
output from the shacl cli in the case of failed validation. Here is an 
minimal example to show the situation, in case I'm just doing 
something wrong.


schema.ttl:


@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix regen: <http://regen.network/> .

regen:ProjectPageShape a sh:NodeShape ;
  sh:targetClass regen:Project-Page ;

  sh:or (
    [ sh:not
  [ sh:path regen:landStewardStory ;
    sh:minCount 1 ;
    sh:maxCount 1
  ]
    ]
    [
  sh:and (
    [ sh:path regen:landStewardStory ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:maxLength 500 ;
  sh:datatype xsd:string
    ]
    [
  sh:path regen:landStewardStoryTitle ;
  sh:resultMessage "regen:landStewardStoryTitle missing" ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:maxLength 160 ;
  sh:datatype xsd:string
    ]
  )
    ]
  );
.

data.jsonld:

{
  "@context": {
    "regen": "http://regen.network/";,
  },
  "@type": "regen:Project-Page",
  "regen:landStewardStory": "In 1998, the local community supported 
our plan to establish the Rukinga Wildlife Sanctuary that covers 
80,000 acres of forest. We established a community works project so 
local residents had an alternative income stream in place of poaching 
and clear cutting​. We brought on locally hired rangers and trained 
them to be wilderness guardians. We convinced the owners of the 
cattle to remove the cattle from the land to reduce conflict over 
resources."

}
And here is the output from running "shacl validate --text 
--shapes=schema.ttl --data=data.jsonld":



[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage  "Or at focusNode 
_:Bccda076ea2a1aedde6ef53f415f1b148" ;

 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:OrConstraintComponent ;
 sh:sourceShape regen:ProjectPageShape ;
 sh:value  _:b0
]
] .

The result I am looking for would look like this:

[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage "regen:landStewardStoryTitle 
missing" ;

 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:OrConstraintComponent ;
 sh:sourceShape regen:ProjectPageShape ;
 sh:value  _:b0
]
] . 

Any suggestions on how this could be achieved?

Thanks,
Kyle

Re: Increasing verbosity of shacl cli tool to show sh:message or sh:resultMessage

[Andy Seaborne]

On 11/01/2023 22:02, Kyle Lawlor-Bagcal wrote:

Hello,

I'm interested to know if there is a way to configure the apache jena 
shacl cli tool to output the values of sh:message or sh:resultMessage. I 
have a property shape where I tried adding contextual info into 
sh:message/sh:resultMessage. I would like to see this info in the output 
from the shacl cli in the case of failed validation. Here is an minimal 
example to show the situation, in case I'm just doing something wrong.


schema.ttl:


@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix regen: <http://regen.network/> .

regen:ProjectPageShape a sh:NodeShape ;
  sh:targetClass regen:Project-Page ;

  sh:or (
    [ sh:not
  [ sh:path regen:landStewardStory ;
    sh:minCount 1 ;
    sh:maxCount 1
  ]
    ]
    [
  sh:and (
    [ sh:path regen:landStewardStory ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:maxLength 500 ;
  sh:datatype xsd:string
    ]
    [
  sh:path regen:landStewardStoryTitle ;
  sh:resultMessage "regen:landStewardStoryTitle missing" ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:maxLength 160 ;
  sh:datatype xsd:string
    ]
  )
    ]
  );
.

data.jsonld:

{
  "@context": {
    "regen": "http://regen.network/";,


Syntax error in the JSON.


  },
  "@type": "regen:Project-Page",
  "regen:landStewardStory": "In 1998, the local community supported 
our plan to establish the Rukinga Wildlife Sanctuary that covers 
80,000 acres of forest. We established a community works project so 
local residents had an alternative income stream in place of poaching 
and clear cutting​. We brought on locally hired rangers and trained 
them to be wilderness guardians. We convinced the owners of the cattle 
to remove the cattle from the land to reduce conflict over resources."

}
And here is the output from running "shacl validate --text 
--shapes=schema.ttl --data=data.jsonld":



[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage  "Or at focusNode 
_:Bccda076ea2a1aedde6ef53f415f1b148" ;

 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:OrConstraintComponent ;
 sh:sourceShape regen:ProjectPageShape ;
 sh:value  _:b0
]
] .

The result I am looking for would look like this:

[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage "regen:landStewardStoryTitle missing" ;
 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:OrConstraintComponent ;
 sh:sourceShape regen:ProjectPageShape ;
 sh:value  _:b0
]
] . 

Any suggestions on how this could be achieved?


The constraint failing is the sh:or which doesn't have a resultMessage. 
Rereading the SHACL spec, there isn't any text about rolling up messages 
- what do other engines do?


There is the Zazuko SAHCL playground

https://shacl-playground.zazuko.com/

it find s the violation but it does not print a message.

Some of the SHACL user community are to be found on Discord:
https://discord.gg/RTbGfJqdKB

where you might get suggestions.

via
https://lists.w3.org/Archives/Public/public-shacl/2021Nov/0007.html

Andy




Thanks,
Kyle

Increasing verbosity of shacl cli tool to show sh:message or sh:resultMessage

[Kyle Lawlor-Bagcal]

Hello,

I'm interested to know if there is a way to configure the apache jena 
shacl cli tool to output the values of sh:message or sh:resultMessage. I 
have a property shape where I tried adding contextual info into 
sh:message/sh:resultMessage. I would like to see this info in the output 
from the shacl cli in the case of failed validation. Here is an minimal 
example to show the situation, in case I'm just doing something wrong.


schema.ttl:


@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix regen: <http://regen.network/> .

regen:ProjectPageShape a sh:NodeShape ;
  sh:targetClass regen:Project-Page ;

  sh:or (
    [ sh:not
  [ sh:path regen:landStewardStory ;
    sh:minCount 1 ;
    sh:maxCount 1
  ]
    ]
    [
  sh:and (
    [ sh:path regen:landStewardStory ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:maxLength 500 ;
  sh:datatype xsd:string
    ]
    [
  sh:path regen:landStewardStoryTitle ;
  sh:resultMessage "regen:landStewardStoryTitle missing" ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:maxLength 160 ;
  sh:datatype xsd:string
    ]
  )
    ]
  );
.

data.jsonld:

{
  "@context": {
    "regen": "http://regen.network/";,
  },
  "@type": "regen:Project-Page",
  "regen:landStewardStory": "In 1998, the local community supported 
our plan to establish the Rukinga Wildlife Sanctuary that covers 
80,000 acres of forest. We established a community works project so 
local residents had an alternative income stream in place of poaching 
and clear cutting​. We brought on locally hired rangers and trained 
them to be wilderness guardians. We convinced the owners of the cattle 
to remove the cattle from the land to reduce conflict over resources."

}
And here is the output from running "shacl validate --text 
--shapes=schema.ttl --data=data.jsonld":



[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage  "Or at focusNode 
_:Bccda076ea2a1aedde6ef53f415f1b148" ;

 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:OrConstraintComponent ;
 sh:sourceShape regen:ProjectPageShape ;
 sh:value  _:b0
]
] .

The result I am looking for would look like this:

[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage "regen:landStewardStoryTitle missing" ;
 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:OrConstraintComponent ;
 sh:sourceShape regen:ProjectPageShape ;
 sh:value  _:b0
]
] . 

Any suggestions on how this could be achieved?

Thanks,
Kyle

Re: Persist SHACL shapes in dataset possible?

[Sebastian Faubel]

Hi Andy, Hi Lorenz,

Thank you both for your quick responses! Regarding your question, Andy:

The shapes graph contains a bit less than 3M triples, but will eventually
grow in size as we add validation of measurement units. Executing a
validation using the API currently takes around 18s which is quite
impressive. Also, that you support SHACL SPARQL is really cool.

It would be perfectly fine for us to have the shapes stored in a named
graph in the same Dataset.

Btw. Does TDB performance scale per dataset (my guess) or per graph?

~Sebastian

*Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg,
Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | www.semiodesk.com


This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Semiodesk GmbH is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.


On Wed, Sep 21, 2022 at 11:07 AM Andy Seaborne  wrote:

>
>
> On 21/09/2022 08:00, Lorenz Buehmann wrote:
> > Interesting question. I think currently the Fuseki SHACL service expects
> > a Turtle file for the shapes acording to [1]. I agree that this seems to
> > be rather inefficient.
>
> @Sebastian - how much data is there? (in triples ideally)
> What does 300mb translate into in terms of numbers of triples and shapes?
>
> How long (lcoally from a file) does it take to parse the shapes?
>
> >
> > @Andy:
> >
> > - the code expects only Turtle format, right? RDF/XML would fail to
> > parse the shapes then, correct?
>
> No. The Content-Type header is used - if that fails, the default lang
> provided is used.
>
> > - the shapes are parsed into a Graph, wouldn't it be possible to reuse a
> > named graph of the backend dataset containing the shapes?
>
> Possible to implement, yes.
>
> Do you mean the same dataset as the data? (that is, using the dataset as
> a collection of graphs). Or a different dataset for storing shapes
> separately from the data (maybe default union graph is being used on the
> data).
>
> Both are possible, the first is easier. The second gets into naming
> named graphs in other datasets.
> "http://example/dataset#encoded-named-graph-uri"; could be be used (does
> not work ATM - it needs implementing.)
>
>  > Or would it be
>  > too slow to use shaped from e.g. a TDB backend?
>
> Jena SHACL parses the shapes and then executes from an in-memory
> datastructure (a bit more than the AST but not much) so execution is not
> dipping in and out of the database. It should be fast enough.
>
> The parsing is cacheable.  Cache invalidation is hard if it's a
> different dataset.
>
>
> This would be a good example of adding more capabilities by using a
> Fuseki Module:
>
> https://jena.apache.org/documentation/fuseki2/fuseki-modules
>
> The idea is to make the fuseki-server jar
> (1) Fuseki main
> (2) A set of modules (for now, admin, UI; later - open ended set)
>
> and the user can choose the server functionality by the selection of
> modules.
>
>  Andy
>
> >
> >
> > Cheers,
> >
> > Lorenz
> >
> >
> > [1]
> >
> https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/SHACL_Validation.java#L66
> >
> >
> > On 20.09.22 17:22, Sebastian Faubel wrote:
> >> Hello everyone,
> >>
> >> I am using Jena Fuseki 4.6.1 with a dataset that I want to validate
> using
> >> SHACL. I've seen the documentation on the SHACL feature in Apache Jena
> >> Fuseki here:
> >>
> >> https://jena.apache.org/documentation/shacl/
> >>
> >> My issue is that my SHACL shapes graph has around 300mb. Uploading this
> >> every time I want to validate would be pretty slow and inefficient. I
> was
> >> wondering if it is possible to persist the shapes graph in the dataset
> >> somehow?
> >>
> >> Thank you! :)
> >>
> >> ~Sebastian
> >>
> >> *Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg,
> >&g

Re: Persist SHACL shapes in dataset possible?

[Andy Seaborne]

On 21/09/2022 08:00, Lorenz Buehmann wrote:
Interesting question. I think currently the Fuseki SHACL service expects 
a Turtle file for the shapes acording to [1]. I agree that this seems to 
be rather inefficient.


@Sebastian - how much data is there? (in triples ideally)
What does 300mb translate into in terms of numbers of triples and shapes?

How long (lcoally from a file) does it take to parse the shapes?



@Andy:

- the code expects only Turtle format, right? RDF/XML would fail to 
parse the shapes then, correct?


No. The Content-Type header is used - if that fails, the default lang 
provided is used.


- the shapes are parsed into a Graph, wouldn't it be possible to reuse a 
named graph of the backend dataset containing the shapes?


Possible to implement, yes.

Do you mean the same dataset as the data? (that is, using the dataset as 
a collection of graphs). Or a different dataset for storing shapes 
separately from the data (maybe default union graph is being used on the 
data).


Both are possible, the first is easier. The second gets into naming 
named graphs in other datasets. 
"http://example/dataset#encoded-named-graph-uri"; could be be used (does 
not work ATM - it needs implementing.)


> Or would it be
> too slow to use shaped from e.g. a TDB backend?

Jena SHACL parses the shapes and then executes from an in-memory 
datastructure (a bit more than the AST but not much) so execution is not 
dipping in and out of the database. It should be fast enough.


The parsing is cacheable.  Cache invalidation is hard if it's a 
different dataset.



This would be a good example of adding more capabilities by using a 
Fuseki Module:


https://jena.apache.org/documentation/fuseki2/fuseki-modules

The idea is to make the fuseki-server jar
(1) Fuseki main
(2) A set of modules (for now, admin, UI; later - open ended set)

and the user can choose the server functionality by the selection of 
modules.


Andy




Cheers,

Lorenz


[1] 
https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/SHACL_Validation.java#L66 



On 20.09.22 17:22, Sebastian Faubel wrote:

Hello everyone,

I am using Jena Fuseki 4.6.1 with a dataset that I want to validate using
SHACL. I've seen the documentation on the SHACL feature in Apache Jena
Fuseki here:

https://jena.apache.org/documentation/shacl/

My issue is that my SHACL shapes graph has around 300mb. Uploading this
every time I want to validate would be pretty slow and inefficient. I was
wondering if it is possible to persist the shapes graph in the dataset
somehow?

Thank you! :)

~Sebastian

*Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg,
Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | 
www.semiodesk.com



This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended 
recipient(s).

Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Semiodesk 
GmbH is

not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are 
solely
those of the author and do not necessarily represent those of the 
company.

Re: Persist SHACL shapes in dataset possible?

[Lorenz Buehmann]

Interesting question. I think currently the Fuseki SHACL service expects 
a Turtle file for the shapes acording to [1]. I agree that this seems to 
be rather inefficient.


@Andy:

- the code expects only Turtle format, right? RDF/XML would fail to 
parse the shapes then, correct?


- the shapes are parsed into a Graph, wouldn't it be possible to reuse a 
named graph of the backend dataset containing the shapes? Or would it be 
too slow to use shaped from e.g. a TDB backend?



Cheers,

Lorenz


[1] 
https://github.com/apache/jena/blob/main/jena-fuseki2/jena-fuseki-core/src/main/java/org/apache/jena/fuseki/servlets/SHACL_Validation.java#L66


On 20.09.22 17:22, Sebastian Faubel wrote:

Hello everyone,

I am using Jena Fuseki 4.6.1 with a dataset that I want to validate using
SHACL. I've seen the documentation on the SHACL feature in Apache Jena
Fuseki here:

https://jena.apache.org/documentation/shacl/

My issue is that my SHACL shapes graph has around 300mb. Uploading this
every time I want to validate would be pretty slow and inefficient. I was
wondering if it is possible to persist the shapes graph in the dataset
somehow?

Thank you! :)

~Sebastian

*Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg,
Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | www.semiodesk.com


This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Semiodesk GmbH is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.

Persist SHACL shapes in dataset possible?

[Sebastian Faubel]

Hello everyone,

I am using Jena Fuseki 4.6.1 with a dataset that I want to validate using
SHACL. I've seen the documentation on the SHACL feature in Apache Jena
Fuseki here:

https://jena.apache.org/documentation/shacl/

My issue is that my SHACL shapes graph has around 300mb. Uploading this
every time I want to validate would be pretty slow and inefficient. I was
wondering if it is possible to persist the shapes graph in the dataset
somehow?

Thank you! :)

~Sebastian

*Semiodesk GmbH | *Werner-von-Siemens-Str. 6 Geb. 15k, 86159 Augsburg,
Germany | Phone: +49 821 8854401 | Fax: +49 821 8854410 | www.semiodesk.com


This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Semiodesk GmbH is
not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.

Re: Is it possible to get more info out of the shacl validation messages?

[Kyle Lawlor-Bagcal]

Thanks to all for your replies, I very much appreciate it.

You could write and be able to reuse share if written as a property 
shape referred to directly:


"""
regen:C02-ProjectShapeX a sh:NodeShape ;
  sh:targetClass regen:C02-Project ;
  sh:property regen:ProjectTypePropertyShape
.

# Property shapes can have URIs!
regen:ProjectTypePropertyShape
    # rdf:type not necessary
    rdf:type a sh:PropertyShape ;
    sh:path regen:projectType ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:minLength 1 ;
    sh:datatype xsd:string ;
    sh:group regen:ProjectPageMetadataGroup ;
.
"""

will give

"MinLengthConstraint[1]: String too short: "

If written this way, all the violations of 
regen:ProjectTypePropertyShape will generate messages so you can get 
one for minLength and one for maxCount, say, if they both fail.


This set me down a path that is working quite well for me. I did have to 
make some adjustments, but I'm quite happy with where I ended up.


Indeed, having property shapes with URI's is also a nicety that I think 
is a benefit for our schema as well. Thanks for pointing that out. This 
info adds some (https://book.validatingrdf.com/bookHtml011.html#sec125).


For posterity, I've end up with this as my schema (a little simplified):


@prefix xsd:  .
@prefix regen:  .
@prefix qudt:  .
@prefix unit:  .
@prefix geojson:  .
@prefix dash:  .
@prefix rdf:  .
@prefix rdfs:  .

regen:C02-ProjectShape a sh:NodeShape ;
  sh:targetClass regen:C02-Project ;
  sh:property regen:NamePropertyShape ;
  sh:property regen:DescriptionPropertyShape ;
.

regen:NamePropertyShape sh:path schema:name ;
  sh:minCount 1 ;
  sh:maxCount 1 ;
  sh:minLength 1 ;
  sh:datatype xsd:string ;
  sh:group regen:ProjectPageBasicInfoGroup ;
.

regen:DescriptionPropertyShape sh:path schema:description ;
  sh:maxLength 1400 ;
  sh:datatype xsd:string ;
  sh:group regen:ProjectPageDescriptionGroup ;
. 


This satisfies my needs nicely by providing a way to dedupe particular 
fields.

Re: Is it possible to get more info out of the shacl validation messages?

[Andy Seaborne]

> So the failure is clearly due to the "sh:minLength" constraint.

Not so clear :-)

The message is coming from the sh:node because that is the validating 
constraint.


sh:node can refer to a large and complex collection of constraints.

A sh:node generates a violation only once even for multiple violations 
of the referred to shape happen.


You could write and be able to reuse share if written as a property 
shape referred to directly:


"""
regen:C02-ProjectShapeX a sh:NodeShape ;
  sh:targetClass regen:C02-Project ;
  sh:property regen:ProjectTypePropertyShape
.

# Property shapes can have URIs!
regen:ProjectTypePropertyShape
# rdf:type not necessary
rdf:type a sh:PropertyShape ;
sh:path regen:projectType ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:minLength 1 ;
sh:datatype xsd:string ;
sh:group regen:ProjectPageMetadataGroup ;
.
"""

will give

"MinLengthConstraint[1]: String too short: "

If written this way, all the violations of 
regen:ProjectTypePropertyShape will generate messages so you can get one 
for minLength and one for maxCount, say, if they both fail.


Andy

On 08/09/2022 22:11, Kyle Lawlor-Bagcal wrote:

Hello,

I've got the following scenario. Upon running the shacl CLI tool, I'm 
seeing this as output:


[ rdf:type sh:ValidationReport ;
   sh:conforms  false ;
   sh:result    [ rdf:type  sh:ValidationResult ;
  sh:focusNode  _:b0 ;
  sh:resultMessage 
"Node[<http://regen.network/ProjectBaseFieldsShape>] at focusNode 
_:Bfdf188221d60ec452edfe2e7c7c855b1" ;

  sh:resultSeverity sh:Violation ;
  sh:sourceConstraintComponent sh:NodeConstraintComponent ;
  sh:sourceShape regen:C02-ProjectShape ;
  sh:value  _:b0
    ]
] .

Where the relevant pieces of the shacl graph are:

@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix regen: <http://regen.network/> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix geojson: <https://purl.org/geojson/vocab#> .
@prefix dash: <http://datashapes.org/dash#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

regen:C02-ProjectShape a sh:NodeShape ;
   sh:targetClass regen:C02-Project ;
   sh:node regen:ProjectBaseFieldsShape ;
.

regen:ProjectTypeFieldShape a sh:NodeShape ;
   sh:property [
     sh:path regen:projectType ;
     sh:minCount 1 ;
     sh:maxCount 1 ;
     sh:minLength 1 ;
     sh:datatype xsd:string ;
     sh:group regen:ProjectPageMetadataGroup ;
   ] ;
.

regen:ProjectBaseFieldsShape a sh:NodeShape ;
   sh:node regen:NameFieldShape ;
   sh:node regen:DescriptionFieldShape ;
   sh:node regen:LocationFieldShape ;
   sh:node regen:ProjectSizeFieldShape ;
   sh:node regen:ProjectActivityFieldShape ;
   sh:node regen:ProjectStartDateFieldShape ;
   sh:node regen:ProjectEndDateFieldShape ;
   sh:node regen:ProjectTypeFieldShape ;
.

And the relevant pieces of the data graph (json-ld) under validation are:

{
   "@context": {
     "schema": "http://schema.org/";,
     "regen": "http://regen.network/";,
     "qudt": "http://qudt.org/schema/qudt/";,
     "unit": "http://qudt.org/vocab/unit/";,
     "xsd": "http://www.w3.org/2001/XMLSchema#";,
   },
   "@type": "regen:C02-Project",
   "regen:projectType": ""
}

So the failure is clearly due to the "sh:minLength" constraint. But in 
the validation error report, that's not so clear. Is there a way to have 
the fact that the "sh:minLength" constraint was violated here?


Thank you,

Kyle

Re: Is it possible to get more info out of the shacl validation messages?

[Florian Kleedorfer]

You can use the ValidationListener to get more detailed information, as 
described here: https://jena.apache.org/documentation/shacl/index.html

...if executing the SHACL validation in a Java program is an option for you.

Best,
Florian 

Am 9. September 2022 07:59:33 MESZ schrieb "Bögershausen, Merlin" 
:
>Hi Kyle,
>sh:message worked for use in a similar situation.
>https://www.w3.org/TR/shacl/#message
>
>Best Merlin
>
>Von: Kyle Lawlor-Bagcal 
>Gesendet: Thursday, September 8, 2022 11:11:22 PM
>An: users@jena.apache.org 
>Betreff: Is it possible to get more info out of the shacl validation messages?
>
>Hello,
>
>I've got the following scenario. Upon running the shacl CLI tool, I'm
>seeing this as output:
>
>[ rdf:type sh:ValidationReport ;
>   sh:conforms  false ;
>   sh:result[ rdf:type  sh:ValidationResult ;
>  sh:focusNode  _:b0 ;
>  sh:resultMessage
>"Node[<http://regen.network/ProjectBaseFieldsShape>] at focusNode
>_:Bfdf188221d60ec452edfe2e7c7c855b1" ;
>  sh:resultSeverity sh:Violation ;
>  sh:sourceConstraintComponent sh:NodeConstraintComponent ;
>  sh:sourceShape regen:C02-ProjectShape ;
>  sh:value  _:b0
>]
>] .
>
>Where the relevant pieces of the shacl graph are:
>
>@prefix schema: <http://schema.org/> .
>@prefix sh: <http://www.w3.org/ns/shacl#> .
>@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>@prefix regen: <http://regen.network/> .
>@prefix qudt: <http://qudt.org/schema/qudt/> .
>@prefix unit: <http://qudt.org/vocab/unit/> .
>@prefix geojson: <https://purl.org/geojson/vocab#> .
>@prefix dash: <http://datashapes.org/dash#> .
>@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>
>regen:C02-ProjectShape a sh:NodeShape ;
>   sh:targetClass regen:C02-Project ;
>   sh:node regen:ProjectBaseFieldsShape ;
>.
>
>regen:ProjectTypeFieldShape a sh:NodeShape ;
>   sh:property [
> sh:path regen:projectType ;
> sh:minCount 1 ;
> sh:maxCount 1 ;
> sh:minLength 1 ;
> sh:datatype xsd:string ;
> sh:group regen:ProjectPageMetadataGroup ;
>   ] ;
>.
>
>regen:ProjectBaseFieldsShape a sh:NodeShape ;
>   sh:node regen:NameFieldShape ;
>   sh:node regen:DescriptionFieldShape ;
>   sh:node regen:LocationFieldShape ;
>   sh:node regen:ProjectSizeFieldShape ;
>   sh:node regen:ProjectActivityFieldShape ;
>   sh:node regen:ProjectStartDateFieldShape ;
>   sh:node regen:ProjectEndDateFieldShape ;
>   sh:node regen:ProjectTypeFieldShape ;
>.
>
>And the relevant pieces of the data graph (json-ld) under validation are:
>
>{
>   "@context": {
> "schema": "http://schema.org/";,
> "regen": "http://regen.network/";,
> "qudt": "http://qudt.org/schema/qudt/";,
> "unit": "http://qudt.org/vocab/unit/";,
> "xsd": "http://www.w3.org/2001/XMLSchema#";,
>   },
>   "@type": "regen:C02-Project",
>   "regen:projectType": ""
>}
>
>So the failure is clearly due to the "sh:minLength" constraint. But in
>the validation error report, that's not so clear. Is there a way to have
>the fact that the "sh:minLength" constraint was violated here?
>
>Thank you,
>
>Kyle
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Is it possible to get more info out of the shacl validation messages?

[Bögershausen , Merlin]

Hi Kyle,
sh:message worked for use in a similar situation.
https://www.w3.org/TR/shacl/#message

Best Merlin

Von: Kyle Lawlor-Bagcal 
Gesendet: Thursday, September 8, 2022 11:11:22 PM
An: users@jena.apache.org 
Betreff: Is it possible to get more info out of the shacl validation messages?

Hello,

I've got the following scenario. Upon running the shacl CLI tool, I'm
seeing this as output:

[ rdf:type sh:ValidationReport ;
   sh:conforms  false ;
   sh:result[ rdf:type  sh:ValidationResult ;
  sh:focusNode  _:b0 ;
  sh:resultMessage
"Node[<http://regen.network/ProjectBaseFieldsShape>] at focusNode
_:Bfdf188221d60ec452edfe2e7c7c855b1" ;
  sh:resultSeverity sh:Violation ;
  sh:sourceConstraintComponent sh:NodeConstraintComponent ;
  sh:sourceShape regen:C02-ProjectShape ;
  sh:value  _:b0
]
] .

Where the relevant pieces of the shacl graph are:

@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix regen: <http://regen.network/> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix geojson: <https://purl.org/geojson/vocab#> .
@prefix dash: <http://datashapes.org/dash#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

regen:C02-ProjectShape a sh:NodeShape ;
   sh:targetClass regen:C02-Project ;
   sh:node regen:ProjectBaseFieldsShape ;
.

regen:ProjectTypeFieldShape a sh:NodeShape ;
   sh:property [
 sh:path regen:projectType ;
 sh:minCount 1 ;
 sh:maxCount 1 ;
 sh:minLength 1 ;
 sh:datatype xsd:string ;
 sh:group regen:ProjectPageMetadataGroup ;
   ] ;
.

regen:ProjectBaseFieldsShape a sh:NodeShape ;
   sh:node regen:NameFieldShape ;
   sh:node regen:DescriptionFieldShape ;
   sh:node regen:LocationFieldShape ;
   sh:node regen:ProjectSizeFieldShape ;
   sh:node regen:ProjectActivityFieldShape ;
   sh:node regen:ProjectStartDateFieldShape ;
   sh:node regen:ProjectEndDateFieldShape ;
   sh:node regen:ProjectTypeFieldShape ;
.

And the relevant pieces of the data graph (json-ld) under validation are:

{
   "@context": {
 "schema": "http://schema.org/";,
 "regen": "http://regen.network/";,
 "qudt": "http://qudt.org/schema/qudt/";,
 "unit": "http://qudt.org/vocab/unit/";,
 "xsd": "http://www.w3.org/2001/XMLSchema#";,
   },
   "@type": "regen:C02-Project",
   "regen:projectType": ""
}

So the failure is clearly due to the "sh:minLength" constraint. But in
the validation error report, that's not so clear. Is there a way to have
the fact that the "sh:minLength" constraint was violated here?

Thank you,

Kyle

Is it possible to get more info out of the shacl validation messages?

[Kyle Lawlor-Bagcal]

Hello,

I've got the following scenario. Upon running the shacl CLI tool, I'm 
seeing this as output:


[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result    [ rdf:type  sh:ValidationResult ;
 sh:focusNode  _:b0 ;
 sh:resultMessage 
"Node[<http://regen.network/ProjectBaseFieldsShape>] at focusNode 
_:Bfdf188221d60ec452edfe2e7c7c855b1" ;

 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent sh:NodeConstraintComponent ;
 sh:sourceShape regen:C02-ProjectShape ;
 sh:value  _:b0
   ]
] .

Where the relevant pieces of the shacl graph are:

@prefix schema: <http://schema.org/> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix regen: <http://regen.network/> .
@prefix qudt: <http://qudt.org/schema/qudt/> .
@prefix unit: <http://qudt.org/vocab/unit/> .
@prefix geojson: <https://purl.org/geojson/vocab#> .
@prefix dash: <http://datashapes.org/dash#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

regen:C02-ProjectShape a sh:NodeShape ;
  sh:targetClass regen:C02-Project ;
  sh:node regen:ProjectBaseFieldsShape ;
.

regen:ProjectTypeFieldShape a sh:NodeShape ;
  sh:property [
    sh:path regen:projectType ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:minLength 1 ;
    sh:datatype xsd:string ;
    sh:group regen:ProjectPageMetadataGroup ;
  ] ;
.

regen:ProjectBaseFieldsShape a sh:NodeShape ;
  sh:node regen:NameFieldShape ;
  sh:node regen:DescriptionFieldShape ;
  sh:node regen:LocationFieldShape ;
  sh:node regen:ProjectSizeFieldShape ;
  sh:node regen:ProjectActivityFieldShape ;
  sh:node regen:ProjectStartDateFieldShape ;
  sh:node regen:ProjectEndDateFieldShape ;
  sh:node regen:ProjectTypeFieldShape ;
.

And the relevant pieces of the data graph (json-ld) under validation are:

{
  "@context": {
    "schema": "http://schema.org/";,
    "regen": "http://regen.network/";,
    "qudt": "http://qudt.org/schema/qudt/";,
    "unit": "http://qudt.org/vocab/unit/";,
    "xsd": "http://www.w3.org/2001/XMLSchema#";,
  },
  "@type": "regen:C02-Project",
  "regen:projectType": ""
}

So the failure is clearly due to the "sh:minLength" constraint. But in 
the validation error report, that's not so clear. Is there a way to have 
the fact that the "sh:minLength" constraint was violated here?


Thank you,

Kyle

Re: SHACL-based data extraction from a knowledge graph

[Thomas Francart]

Just to let you know - I've given up on this, and instead am automating the
generation of a set of CONSTRUCT SPARQL queries built based on the parsing
of (a very limited subset of) SHACL constraints (following
sh:property/sh:path+sh:node recursively, using sh:in sh:hasValue,
sh:languageIn to filter values to pull from the graph)
It doesn't guarantee 100% conformity with the SHACL definition, especially
wrt to cardinalities - but if the underlying graph doesn't match the
specified shapes, then it is not the objective of this extraction step to
make it conformant.

I will probably release some code when ready.

Thomas


Le lun. 28 mars 2022 à 21:26, Andy Seaborne  a écrit :

> Some inspiration from ShEx may help. The "validation" process is defined
> by assigning triples to non-overlapping partitions defined by
> constraints. There can be more then one way to partition the triples in
> a disjunction or conjunction when there are multiple occurrences of
> triples matching multiple constraints in the conjunction. OR and AND in
> ShExC.
>
> The process can involve backtracking to search through alternatives
> (it's like string regex except "bag regex" is assigning triples to bags
> as the regex passes over). It's also more "closed" by default in style.
>
> SHACL does not have this "use once". The sub-shapes of a shape are more
> independent. But it's only the compositional operations that matter =
> not the basic triple constraints. And it matters less if what is being
> extracted is a graph because it's a set.
>
> Some restrictions are necessary - SHACL-SPARQL does say why a constraint
> matched and can need the rest of the graph.
>
>  Andy
>
> On 10/03/2022 19:19, Florian Kleedorfer wrote:
> > Not sure how that could work. You could keep a set of tiples per focus
> > node validation, add all triples that pass the constraint tests (given
> > that you somehow are able to reconstruct the triple(s) from the data the
> > Shacl logic is working on (which is not triples but, in many instances,
> > sets of nodes - e.g. the result of G.allSP()), and emit the set once
> > you've established that the complete shape is valid for the focus node.
> > I would be very sceptical of adding such a special-interest aspect to
> > code like SHACL that must be relied on and fast as can be.
> >
> > Having said that, I've wanted to modify the way Jena evaluates SHACL
> > recently - maybe a way to extend it would be useful (allowing
> > inheritance or having some kind of callback or somesuch). However, I
> > found that for my use case, the trick with the graph wrapper that
> > observes which triples are pulled by SHACL works just fine and is very
> > simple to implement (the shacl validation algorithm, if you want to
> > modify it, is not that simple and easy to mess up).
> >
> > Am 2022-03-09 14:26, schrieb Thomas Francart:
> >> What is VLib.validateShape actually returns the focusNode + Path +
> >> valueNodes that conform to each shape ? or emit them through a listener
> ?
> >> (
> >>
> https://github.com/apache/jena/blob/5ce8c141d425655bcaa9d7567117659e502a7ff1/jena-shacl/src/main/java/org/apache/jena/shacl/validation/VLib.java#L89
> >>
> >> )
> >> The idea would be to use the Validator as a "filter" that emits the
> >> triples
> >> valid according to shapes, so that they can be aggregated in an output
> >> graph.
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

Re: SHACL-based data extraction from a knowledge graph

[Andy Seaborne]

Some inspiration from ShEx may help. The "validation" process is defined 
by assigning triples to non-overlapping partitions defined by 
constraints. There can be more then one way to partition the triples in 
a disjunction or conjunction when there are multiple occurrences of 
triples matching multiple constraints in the conjunction. OR and AND in 
ShExC.


The process can involve backtracking to search through alternatives 
(it's like string regex except "bag regex" is assigning triples to bags 
as the regex passes over). It's also more "closed" by default in style.


SHACL does not have this "use once". The sub-shapes of a shape are more 
independent. But it's only the compositional operations that matter = 
not the basic triple constraints. And it matters less if what is being 
extracted is a graph because it's a set.


Some restrictions are necessary - SHACL-SPARQL does say why a constraint 
matched and can need the rest of the graph.


Andy

On 10/03/2022 19:19, Florian Kleedorfer wrote:
Not sure how that could work. You could keep a set of tiples per focus 
node validation, add all triples that pass the constraint tests (given 
that you somehow are able to reconstruct the triple(s) from the data the 
Shacl logic is working on (which is not triples but, in many instances, 
sets of nodes - e.g. the result of G.allSP()), and emit the set once 
you've established that the complete shape is valid for the focus node. 
I would be very sceptical of adding such a special-interest aspect to 
code like SHACL that must be relied on and fast as can be.


Having said that, I've wanted to modify the way Jena evaluates SHACL 
recently - maybe a way to extend it would be useful (allowing 
inheritance or having some kind of callback or somesuch). However, I 
found that for my use case, the trick with the graph wrapper that 
observes which triples are pulled by SHACL works just fine and is very 
simple to implement (the shacl validation algorithm, if you want to 
modify it, is not that simple and easy to mess up).


Am 2022-03-09 14:26, schrieb Thomas Francart:

What is VLib.validateShape actually returns the focusNode + Path +
valueNodes that conform to each shape ? or emit them through a listener ?
(
https://github.com/apache/jena/blob/5ce8c141d425655bcaa9d7567117659e502a7ff1/jena-shacl/src/main/java/org/apache/jena/shacl/validation/VLib.java#L89 


)
The idea would be to use the Validator as a "filter" that emits the 
triples

valid according to shapes, so that they can be aggregated in an output
graph.

Re: SHACL-based data extraction from a knowledge graph

[Florian Kleedorfer]

Not sure how that could work. You could keep a set of tiples per focus 
node validation, add all triples that pass the constraint tests (given 
that you somehow are able to reconstruct the triple(s) from the data the 
Shacl logic is working on (which is not triples but, in many instances, 
sets of nodes - e.g. the result of G.allSP()), and emit the set once 
you've established that the complete shape is valid for the focus node. 
I would be very sceptical of adding such a special-interest aspect to 
code like SHACL that must be relied on and fast as can be.


Having said that, I've wanted to modify the way Jena evaluates SHACL 
recently - maybe a way to extend it would be useful (allowing 
inheritance or having some kind of callback or somesuch). However, I 
found that for my use case, the trick with the graph wrapper that 
observes which triples are pulled by SHACL works just fine and is very 
simple to implement (the shacl validation algorithm, if you want to 
modify it, is not that simple and easy to mess up).


Am 2022-03-09 14:26, schrieb Thomas Francart:

What is VLib.validateShape actually returns the focusNode + Path +
valueNodes that conform to each shape ? or emit them through a listener 
?

(
https://github.com/apache/jena/blob/5ce8c141d425655bcaa9d7567117659e502a7ff1/jena-shacl/src/main/java/org/apache/jena/shacl/validation/VLib.java#L89
)
The idea would be to use the Validator as a "filter" that emits the 
triples

valid according to shapes, so that they can be aggregated in an output
graph.

Re: SHACL-based data extraction from a knowledge graph

[Thomas Francart]

What is VLib.validateShape actually returns the focusNode + Path +
valueNodes that conform to each shape ? or emit them through a listener ?
(
https://github.com/apache/jena/blob/5ce8c141d425655bcaa9d7567117659e502a7ff1/jena-shacl/src/main/java/org/apache/jena/shacl/validation/VLib.java#L89
)
The idea would be to use the Validator as a "filter" that emits the triples
valid according to shapes, so that they can be aggregated in an output
graph.

Le mer. 9 mars 2022 à 13:45, Florian Kleedorfer <
florian.kleedor...@austria.fm> a écrit :

> Am 2022-03-09 13:22, schrieb Thomas Francart:
>
> >> I think you could do it with jena. Load the dara into a Graph, then
> >> get
> >> the focus nodes for all shapes you want using VLib.focusNodes.
> >> evaluate
> >> each shape on its focus nodes and compile the intersection of all
> >> focus
> >> nodes that are valid, along with the shapes. Now evaluate the shapes
> >> again
> >> on these valid focus nodes and record all the triples/quads that are
> >> pulled
> >> from the data graph during evaluation.
> >>
> >
> > But does this guarantee that all triples pulled from the data graph are
> > valid triples ?
> > For example I may have
> >
> > ex:myConcept skos:prefLabel "english label"@en, "german label"@de .
> >
> > And my SHACL would specify a Shape that mandates English :
> >
> > ex:MyShape a sh:NodeShape ;
> >  sh:property [
> > sh:property skos:prefLabel ;
> > sh:languageIn ("en") ;
> >  ]
> >
> > In that case, does only the skos:prefLabel with an english lang be
> > pulled
> > from the graph ?
> >
> > I take the hypothesis that any triple pulled from the graph are the one
> > for
> > which the predicate is indicated in sh:property, but this does not
> > guarantee that the triple is valid.
> > Wouldn't this require to know whether each individual triples has
> > matched
> > all the constraints of the shape to output it or not ?
>
> I think you are right. You'd get a bigger set than the triples you
> actually want. You can probably use the validation result to filter out
> the triples that cause violations - although I am not positive it will
> work in every instance. I'd try, though.
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

Re: SHACL-based data extraction from a knowledge graph

[Florian Kleedorfer]

Am 2022-03-09 13:22, schrieb Thomas Francart:

I think you could do it with jena. Load the dara into a Graph, then 
get
the focus nodes for all shapes you want using VLib.focusNodes. 
evaluate
each shape on its focus nodes and compile the intersection of all 
focus
nodes that are valid, along with the shapes. Now evaluate the shapes 
again
on these valid focus nodes and record all the triples/quads that are 
pulled

from the data graph during evaluation.



But does this guarantee that all triples pulled from the data graph are
valid triples ?
For example I may have

ex:myConcept skos:prefLabel "english label"@en, "german label"@de .

And my SHACL would specify a Shape that mandates English :

ex:MyShape a sh:NodeShape ;
 sh:property [
sh:property skos:prefLabel ;
sh:languageIn ("en") ;
 ]

In that case, does only the skos:prefLabel with an english lang be 
pulled

from the graph ?

I take the hypothesis that any triple pulled from the graph are the one 
for

which the predicate is indicated in sh:property, but this does not
guarantee that the triple is valid.
Wouldn't this require to know whether each individual triples has 
matched

all the constraints of the shape to output it or not ?


I think you are right. You'd get a bigger set than the triples you 
actually want. You can probably use the validation result to filter out 
the triples that cause violations - although I am not positive it will 
work in every instance. I'd try, though.

Re: SHACL-based data extraction from a knowledge graph

[Thomas Francart]

Thanks Florian ! I am following up the conversion on the Jena mailing list

Le mer. 9 mars 2022 à 00:56, Florian Kleedorfer <
florian.kleedor...@austria.fm> a écrit :

> I think you could do it with jena. Load the dara into a Graph, then get
> the focus nodes for all shapes you want using VLib.focusNodes. evaluate
> each shape on its focus nodes and compile the intersection of all focus
> nodes that are valid, along with the shapes. Now evaluate the shapes again
> on these valid focus nodes and record all the triples/quads that are pulled
> from the data graph during evaluation.
>

But does this guarantee that all triples pulled from the data graph are
valid triples ?
For example I may have

ex:myConcept skos:prefLabel "english label"@en, "german label"@de .

And my SHACL would specify a Shape that mandates English :

ex:MyShape a sh:NodeShape ;
 sh:property [
sh:property skos:prefLabel ;
sh:languageIn ("en") ;
 ]

In that case, does only the skos:prefLabel with an english lang be pulled
from the graph ?

I take the hypothesis that any triple pulled from the graph are the one for
which the predicate is indicated in sh:property, but this does not
guarantee that the triple is valid.
Wouldn't this require to know whether each individual triples has matched
all the constraints of the shape to output it or not ?

Thanks again !
Thomas


> That last bit requires you to wrap the original data graph object in a
> custom class extending the Graph class in such a way that you intercept all
> reading calls and store the result triples in an internal set before
> handing them back to the client.
>
> After the second evaluation of only the valid focus nodes you should have
> your desired extraction result in the wrapper graph.
>
> I may be wrong about this approach, but it might just work. If you try
> this and succeed, please consider contributing the code to jena. It's not
> the first time this question has come up.
>
> All the best!
> Florian
>
>
> Am 8. März 2022 18:25:13 MEZ schrieb Thomas Francart <
> thomas.franc...@sparna.fr>:
>>
>> Hello !
>>
>> I am facing the following situation :
>>
>>- A large knowledge graph with lots of triples
>>- A need to export multiple RDF datasets from this large Knowledge
>>Graph, each containing a subset of the triples from the graph
>>- Datasets are not limited to a flat list of entities with their
>>properties, but will each contain a small piece of graph
>>- The exact content of each Dataset is specified in SHACL, using
>>standard constraints of cardinalities, sh:node, datatype, languageIn,
>>sh:hasValue, etc. This SHACL will be used as the source for documenting 
>> the
>>exact content of each Dataset using [1]
>>
>> And now the question : can we automate the extraction of data from the
>> large knowledge graph based on the SHACL definition of our datasets ?
>> What we are looking for is a guarantee that the extraction process will
>> produce a dataset that is conformant with the SHACL definition.
>>
>> Has anyone done something similar ? A naîve approach would be a SPARQL
>> query generation based on the SHACL definition of the dataset, but I
>> suspect the query will quickly be too complicated.
>>
>> Thanks !
>> Thomas
>>
>> [1] SHACL Play documentation generator :
>> https://shacl-play.sparna.fr/play/doc
>>
>> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
>


-- 

*Thomas Francart* -* SPARNA*
Web de *données* | Architecture de l'*information* | Accès aux
*connaissances*
blog : blog.sparna.fr, site : sparna.fr, linkedin :
fr.linkedin.com/in/thomasfrancart
tel :  +33 (0)6.71.11.25.97, skype : francartthomas

Re: Can Fuseki SHACL-validate data before inserting them into the graph?

[Moritz Orth]

Thank both of you very much. I’ll have a look at Processor, looks very 
interesting at first sight!

Best regards
Moritz

> Am 06.03.2022 um 10:27 schrieb Martynas Jusevičius :
> 
> Processor can validate request payloads against SPIN and SHACL. The
> constraints are defined as part of the LDT ontology.
> https://github.com/AtomGraph/Processor
> 
> On Sat, 5 Mar 2022 at 19.35, Andy Seaborne  wrote:
> 
>> 
>> 
>> On 04/03/2022 17:24, Moritz Orth wrote:
>>> Hello everyone,
>>> 
>>> I’m currently playing around with SHACL in Jena and just asked myself:
>> Can Fuseki validate data against SHACL shapes prior to inserting them into
>> the graph, refusing to add them when they don’t conform with the shapes?
>> 
>> No, not currently.
>> 
>> Andy
>> 
>>> 
>>> The docs under https://jena.apache.org/documentation/shacl/index.html <
>> https://jena.apache.org/documentation/shacl/index.html> show that
>> something like this is possible using the Java API directly, using
>> GraphValidation.update(). Fuseki allows for creating a SHACL validation
>> report after inserting some data, however I cannot see a possibility to
>> achieve this kind of transaction rollback behaviour that I do with the API.
>>> 
>>> Is there some kind of operation mode for Fuseki that allows you to
>> specify some SHACL shapes on startup, and then validate all triple
>> insertion requests against those shapes?
>>> 
>>> Thanks in advance for some guidance on the topic.
>>> 
>>> Best regards
>>> Moritz
>>> 
>>> 
>> 

Re: Can Fuseki SHACL-validate data before inserting them into the graph?

[Martynas Jusevičius]

Processor can validate request payloads against SPIN and SHACL. The
constraints are defined as part of the LDT ontology.
https://github.com/AtomGraph/Processor

On Sat, 5 Mar 2022 at 19.35, Andy Seaborne  wrote:

>
>
> On 04/03/2022 17:24, Moritz Orth wrote:
> > Hello everyone,
> >
> > I’m currently playing around with SHACL in Jena and just asked myself:
> Can Fuseki validate data against SHACL shapes prior to inserting them into
> the graph, refusing to add them when they don’t conform with the shapes?
>
> No, not currently.
>
>  Andy
>
> >
> > The docs under https://jena.apache.org/documentation/shacl/index.html <
> https://jena.apache.org/documentation/shacl/index.html> show that
> something like this is possible using the Java API directly, using
> GraphValidation.update(). Fuseki allows for creating a SHACL validation
> report after inserting some data, however I cannot see a possibility to
> achieve this kind of transaction rollback behaviour that I do with the API.
> >
> > Is there some kind of operation mode for Fuseki that allows you to
> specify some SHACL shapes on startup, and then validate all triple
> insertion requests against those shapes?
> >
> > Thanks in advance for some guidance on the topic.
> >
> > Best regards
> > Moritz
> >
> >
>

Re: Can Fuseki SHACL-validate data before inserting them into the graph?

[Andy Seaborne]

On 04/03/2022 17:24, Moritz Orth wrote:

Hello everyone,

I’m currently playing around with SHACL in Jena and just asked myself: Can 
Fuseki validate data against SHACL shapes prior to inserting them into the 
graph, refusing to add them when they don’t conform with the shapes?


No, not currently.

Andy



The docs under https://jena.apache.org/documentation/shacl/index.html 
<https://jena.apache.org/documentation/shacl/index.html> show that something 
like this is possible using the Java API directly, using GraphValidation.update(). 
Fuseki allows for creating a SHACL validation report after inserting some data, 
however I cannot see a possibility to achieve this kind of transaction rollback 
behaviour that I do with the API.

Is there some kind of operation mode for Fuseki that allows you to specify some 
SHACL shapes on startup, and then validate all triple insertion requests 
against those shapes?

Thanks in advance for some guidance on the topic.

Best regards
Moritz

Can Fuseki SHACL-validate data before inserting them into the graph?

[Moritz Orth]

Hello everyone,

I’m currently playing around with SHACL in Jena and just asked myself: Can 
Fuseki validate data against SHACL shapes prior to inserting them into the 
graph, refusing to add them when they don’t conform with the shapes?

The docs under https://jena.apache.org/documentation/shacl/index.html 
<https://jena.apache.org/documentation/shacl/index.html> show that something 
like this is possible using the Java API directly, using 
GraphValidation.update(). Fuseki allows for creating a SHACL validation report 
after inserting some data, however I cannot see a possibility to achieve this 
kind of transaction rollback behaviour that I do with the API.

Is there some kind of operation mode for Fuseki that allows you to specify some 
SHACL shapes on startup, and then validate all triple insertion requests 
against those shapes?

Thanks in advance for some guidance on the topic.

Best regards
Moritz

Re: SHACL & TDB

[Adrian Gschwend]

On 27.09.21 18:05, Andy Seaborne wrote:

Hi Andy,

> Other than the service name - where does it say in-memory only? The> 
> validation API works on any graphs. The CLI tools do work in-memory.
Thanks for the clarification. I then over-interpreted the documentation
and draw that wrong conclusion. Good to hear!

> How many millions?
Right now still in the 1 digit range

> I've done some work on SHACL to split work out into inline streaming
> (e.g. anything checking objects which is often the bulk of shapes work +
> domain and range like things), entity wide items until later (e.g. track
> what might be affected cardinality) and things that are unknown (SPARQL)
> until the end. But not in the codebase.

yeah some things can work in streaming in SHACL, others can't.

> ShEx with its "shapes map" has a different approach - the shapes map can
> direct the validation so the app can break it up into chunks or
> calculate from changes. Might be interesting to use that concept sometime.

ah never had a look at that.

thanks

regards

Adrian

Re: SHACL & TDB

[Andy Seaborne]

On 27/09/2021 16:28, Adrian Gschwend wrote:

Hi group,

I recently started playing with SHACL validation in Jena, worked well
with the cli for the few things I tested, thanks for the work!

What I don't really get is where SHACL support in Jena is heading. From
what I understand in the documentation this is currently only usable in
in-memory scenarios.


Other than the service name - where does it say in-memory only? The 
validation API works on any graphs. The CLI tools do work in-memory.


The Fuseki SHACL service works on any database.

How fast that is depends on the many factors.


According to the doc the same is true for using
SHACL in Fuseki.

I guess that this will work up to a certain size of the graph. Is there
a plan/scenario where I could do the same on TDB indexes/backend?

The use-case I'm thinking about would be validating observations in RDF
data cubes with SHACL. This could potentially be millions of
observations so I guess there is a certain limit of what I could
validate in the in-memory setup.


How many millions?

I've done some work on SHACL to split work out into inline streaming 
(e.g. anything checking objects which is often the bulk of shapes work + 
domain and range like things), entity wide items until later (e.g. track 
what might be affected cardinality) and things that are unknown (SPARQL) 
until the end. But not in the codebase.


ShEx with its "shapes map" has a different approach - the shapes map can 
direct the validation so the app can break it up into chunks or 
calculate from changes. Might be interesting to use that concept sometime.


Andy



regards

Adrian

Re: SHACL & TDB

[Florian Kleedorfer]

Hi,

Cannot help with the question as far as jena is concerned. Fwiw, there is 
(limited) support for SHACL in RDF4J Sails, which is also supported by GraphDB 
- as you may know.





Am 27. September 2021 11:28:50 GMT-04:00 schrieb Adrian Gschwend 
:
>Hi group,
>
>I recently started playing with SHACL validation in Jena, worked well
>with the cli for the few things I tested, thanks for the work!
>
>What I don't really get is where SHACL support in Jena is heading. From
>what I understand in the documentation this is currently only usable in
>in-memory scenarios. According to the doc the same is true for using
>SHACL in Fuseki.
>
>I guess that this will work up to a certain size of the graph. Is there
>a plan/scenario where I could do the same on TDB indexes/backend?
>
>The use-case I'm thinking about would be validating observations in RDF
>data cubes with SHACL. This could potentially be millions of
>observations so I guess there is a certain limit of what I could
>validate in the in-memory setup.
>
>regards
>
>Adrian

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

SHACL & TDB

[Adrian Gschwend]

Hi group,

I recently started playing with SHACL validation in Jena, worked well
with the cli for the few things I tested, thanks for the work!

What I don't really get is where SHACL support in Jena is heading. From
what I understand in the documentation this is currently only usable in
in-memory scenarios. According to the doc the same is true for using
SHACL in Fuseki.

I guess that this will work up to a certain size of the graph. Is there
a plan/scenario where I could do the same on TDB indexes/backend?

The use-case I'm thinking about would be validating observations in RDF
data cubes with SHACL. This could potentially be millions of
observations so I guess there is a certain limit of what I could
validate in the in-memory setup.

regards

Adrian

Re: Using SHACL constraint parameters in SPARQL paths

[Andy Seaborne]

Patrick -

That split should work. It's because SPARQL does not allow variables in 
paths.


?subject  $listPredicate/rdf:rest*/rdf:first  ?object

is bad syntax and seems to line up with the error message

5.3 Validation with SPARQL-based Constraints
"""
substitute the variable PATH where it appears in the predicate position 
of a triple pattern

"""
and it says triple pattern which has only a variable or URI in the 
predicate slot not a path.


So "?s $PATH ?o" but nothing more complex.

Andy


On 23/08/2021 22:06, Patrick Golden wrote:
My solution was to just break up the list-lookup part of the SPARQL 
query into two elements:


$this $listPredicate ?listHead .
?listHead rdf:rest*/rdf:first ?missing .

Easy enough!

On 8/23/21 12:11 PM, Patrick Golden wrote:

Hello,

I'm trying to write a sh:ConstraintComponent that validates whether 
two predicates have the same objects. One predicate has multiple 
objects and the other has an object with an ordered RDF list of those 
same nodes. In Turtle, a valid graph looks like:



@prefix ex: <http://example.org/> .

ex:Thing
 ex:p1 ex:a, ex:b, ex:c ;
 ex:p2 ( ex:a ex:b ex:c ) .


I can create a SPARQL constraint that expresses this:


:ListPredEqualityConstraint
 a sh:SPARQLConstraint ;
 sh:prefixes [
 sh:declare
 [
 sh:prefix "ex" ;
 sh:namespace "http://example.org/"^^xsd:anyURI
 ] ,
 ]
 sh:select """
SELECT $this ?missing
WHERE {

 {
   $this ex:p2/rdf:rest*/rdf:first ?missing
   MINUS
   { $this ex:p1 ?missing }
 }
 UNION
 {
   $this ex:p1 ?missing
   MINUS
   { $this ex:p2/rdf:rest*/rdf:first ?missing }
 }
}
""" .


I have multiple pairs of predicates to which this constraint can 
apply, so I wanted to make a generic constraint component which can 
take each of the two predicates as parameters. This is how I tried to 
model that:



:ListMatchConstraintComponent
 a sh:ConstraintComponent ;
 sh:parameter [
 sh:path ex:unorderedPredicate ;
 ] ;
 sh:parameter [
 sh:path ex:listPredicate ;
 ] ;
 sh:nodeValidator [
 a sh:SPARQLSelectValidator ;
 sh:select """
SELECT $this ?missing
WHERE {

 {
   $this $listPredicate/rdf:rest*/rdf:first ?missing
   MINUS
   { $this $unorderedPredicate ?missing }
 }
 UNION
 {
   $this $unorderedPredicate ?missing
   MINUS
   { $this $listPredicate/rdf:rest*/rdf:first ?missing }
 }
}
"""
 ] .


For each predicate pair constraint, I create a shape like this:


:P1P2ListMatchConstraint
 a sh:NodeShape ;
 :unorderedPredicate ex:p1 ;
 :listPredicate ex:p2 .


However, when I run `shacl validate` for the graph against this shape, 
I see the result:


$ shacl v -s shape.ttl -d graph.ttl
org.apache.jena.shacl.parser.ShaclParseException: Bad query: 
Encountered " "/" "/ "" at line 8, column 27.

Was expecting one of:
  ...
  ...
  ...
  ...
  ...
  ...
 "true" ...
 "false" ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
  ...
 "(" ...
  ...
 "[" ...
  ...
 "<<" ...


I am guessing that the values for the parameters in the constraint 
($unorderedPredicate, $listPredicate) are not allowed to be in SPARQL 
property paths (e.g. $this $listPredicate/rdf:rest*/rdf:first 
?missing). Is that the case? Are there alternative ways to achieve 
what I'm trying to do?


Thank you,
Patrick

Re: Using SHACL constraint parameters in SPARQL paths

[Patrick Golden]

My solution was to just break up the list-lookup part of the SPARQL 
query into two elements:


$this $listPredicate ?listHead .
?listHead rdf:rest*/rdf:first ?missing .

Easy enough!

On 8/23/21 12:11 PM, Patrick Golden wrote:

Hello,

I'm trying to write a sh:ConstraintComponent that validates whether two 
predicates have the same objects. One predicate has multiple objects and 
the other has an object with an ordered RDF list of those same nodes. In 
Turtle, a valid graph looks like:



@prefix ex: <http://example.org/> .

ex:Thing
     ex:p1 ex:a, ex:b, ex:c ;
     ex:p2 ( ex:a ex:b ex:c ) .


I can create a SPARQL constraint that expresses this:


:ListPredEqualityConstraint
     a sh:SPARQLConstraint ;
     sh:prefixes [
     sh:declare
     [
     sh:prefix "ex" ;
     sh:namespace "http://example.org/"^^xsd:anyURI
     ] ,
     ]
     sh:select """
SELECT $this ?missing
WHERE {

     {
   $this ex:p2/rdf:rest*/rdf:first ?missing
   MINUS
   { $this ex:p1 ?missing }
     }
     UNION
     {
   $this ex:p1 ?missing
   MINUS
   { $this ex:p2/rdf:rest*/rdf:first ?missing }
     }
}
""" .


I have multiple pairs of predicates to which this constraint can apply, 
so I wanted to make a generic constraint component which can take each 
of the two predicates as parameters. This is how I tried to model that:



:ListMatchConstraintComponent
     a sh:ConstraintComponent ;
     sh:parameter [
     sh:path ex:unorderedPredicate ;
     ] ;
     sh:parameter [
     sh:path ex:listPredicate ;
     ] ;
     sh:nodeValidator [
     a sh:SPARQLSelectValidator ;
     sh:select """
SELECT $this ?missing
WHERE {

     {
   $this $listPredicate/rdf:rest*/rdf:first ?missing
   MINUS
   { $this $unorderedPredicate ?missing }
     }
     UNION
     {
   $this $unorderedPredicate ?missing
   MINUS
   { $this $listPredicate/rdf:rest*/rdf:first ?missing }
     }
}
"""
     ] .


For each predicate pair constraint, I create a shape like this:


:P1P2ListMatchConstraint
     a sh:NodeShape ;
     :unorderedPredicate ex:p1 ;
     :listPredicate ex:p2 .


However, when I run `shacl validate` for the graph against this shape, I 
see the result:


$ shacl v -s shape.ttl -d graph.ttl
org.apache.jena.shacl.parser.ShaclParseException: Bad query: Encountered 
" "/" "/ "" at line 8, column 27.

Was expecting one of:
      ...
      ...
      ...
      ...
      ...
      ...
     "true" ...
     "false" ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
      ...
     "(" ...
      ...
     "[" ...
      ...
     "<<" ...


I am guessing that the values for the parameters in the constraint 
($unorderedPredicate, $listPredicate) are not allowed to be in SPARQL 
property paths (e.g. $this $listPredicate/rdf:rest*/rdf:first ?missing). 
Is that the case? Are there alternative ways to achieve what I'm trying 
to do?


Thank you,
Patrick

Using SHACL constraint parameters in SPARQL paths

[Patrick Golden]

Hello,

I'm trying to write a sh:ConstraintComponent that validates whether two 
predicates have the same objects. One predicate has multiple objects and 
the other has an object with an ordered RDF list of those same nodes. In 
Turtle, a valid graph looks like:



@prefix ex: <http://example.org/> .

ex:Thing
ex:p1 ex:a, ex:b, ex:c ;
ex:p2 ( ex:a ex:b ex:c ) .


I can create a SPARQL constraint that expresses this:


:ListPredEqualityConstraint
a sh:SPARQLConstraint ;
sh:prefixes [
sh:declare
[
sh:prefix "ex" ;
sh:namespace "http://example.org/"^^xsd:anyURI
] ,
]
sh:select """
SELECT $this ?missing
WHERE {

{
  $this ex:p2/rdf:rest*/rdf:first ?missing
  MINUS
  { $this ex:p1 ?missing }
}
UNION
{
  $this ex:p1 ?missing
  MINUS
  { $this ex:p2/rdf:rest*/rdf:first ?missing }
}
}
""" .


I have multiple pairs of predicates to which this constraint can apply, 
so I wanted to make a generic constraint component which can take each 
of the two predicates as parameters. This is how I tried to model that:



:ListMatchConstraintComponent
a sh:ConstraintComponent ;
sh:parameter [
sh:path ex:unorderedPredicate ;
] ;
sh:parameter [
sh:path ex:listPredicate ;
] ;
sh:nodeValidator [
a sh:SPARQLSelectValidator ;
sh:select """
SELECT $this ?missing
WHERE {

{
  $this $listPredicate/rdf:rest*/rdf:first ?missing
  MINUS
  { $this $unorderedPredicate ?missing }
}
UNION
{
  $this $unorderedPredicate ?missing
  MINUS
  { $this $listPredicate/rdf:rest*/rdf:first ?missing }
}
}
"""
] .


For each predicate pair constraint, I create a shape like this:


:P1P2ListMatchConstraint
a sh:NodeShape ;
:unorderedPredicate ex:p1 ;
:listPredicate ex:p2 .


However, when I run `shacl validate` for the graph against this shape, I 
see the result:


$ shacl v -s shape.ttl -d graph.ttl
org.apache.jena.shacl.parser.ShaclParseException: Bad query: Encountered 
" "/" "/ "" at line 8, column 27.

Was expecting one of:
 ...
 ...
 ...
 ...
 ...
 ...
"true" ...
"false" ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
 ...
"(" ...
 ...
"[" ...
 ...
"<<" ...


I am guessing that the values for the parameters in the constraint 
($unorderedPredicate, $listPredicate) are not allowed to be in SPARQL 
property paths (e.g. $this $listPredicate/rdf:rest*/rdf:first ?missing). 
Is that the case? Are there alternative ways to achieve what I'm trying 
to do?


Thank you,
Patrick

RE: SHACL-SPARQL

[Alani, Yasir]

Hi Andy,

Yes, it works now. Thank you very much for this.

Regards

Yasir

-Original Message-
From: Andy Seaborne  
Sent: 05 August 2021 21:30
To: users@jena.apache.org
Subject: Re: SHACL-SPARQL

Firstly -- here's the data (from your email that went the moderator):

You've fixed the aso:GArent vs aso:User.


--
@prefix rdf:   
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VAdOlc%2F7n8VHOepYwCy68mGyg1GdmDWp7S6cIrvSbrU%3D&reserved=0>
 .
@prefix sh:
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fshacl%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ns9lOP2dYeJIJmWFh8pVsYul%2FiR%2BZkF6fxCfxwvkELM%3D&reserved=0>
 .
@prefix xsd:   
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=49y6RKLtI6mNQ09oJ3%2BtQAkyRgqchw9vHfyqkNdSFmo%3D&reserved=0>
 .
@prefix rdfs:  
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ftxsyPnc%2BqK7JAgQu0apnnX7VlG9IyNmlImna8sXXuY%3D&reserved=0>
 .
@prefix ex:
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.example.org%2F%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=F9EYf4u7t7LCGT1CygP6qAvUZuwKUXUUMOZj8ytopow%3D&reserved=0>
 .
@prefix aso:   
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.semanticweb.org%2Faso%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hH7QZ6fiREkz197NqSpYEwuB3DGshIEx2%2BDPYMkGmNc%3D&reserved=0>
 .
@prefix schema: 
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FFve8VLBDm4IH4KAUZMksBWPBoj%2Fl%2FTphwu%2B64XzK%2F4%3D&reserved=0>
 .

aso:alice a aso:User ;
schema:givenName "Alice" ;
schema:familyName "Cooper" ;
schema:name "Alice Cooper" .

aso:bob a aso:User ;
schema:givenName "Bob" ;
schema:familyName "Smith" ;
schema:name "Robert Smith" .
--
and shapes
--
@prefix rdf:   
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F1999%2F02%2F22-rdf-syntax-ns%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VAdOlc%2F7n8VHOepYwCy68mGyg1GdmDWp7S6cIrvSbrU%3D&reserved=0>
 .
@prefix sh:
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fshacl%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ns9lOP2dYeJIJmWFh8pVsYul%2FiR%2BZkF6fxCfxwvkELM%3D&reserved=0>
 .
@prefix xsd:   
<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23&data=04%7C01%7CY.Alani%40tees.ac.uk%7C607386daff1d42443ee608d9584fc9ed%7C43d2115ba55e46b69df7b03388ecfc60%7C0%7C1%7C637637921989080531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M

Re: SHACL-SPARQL

[Andy Seaborne]

Firstly -- here's the data (from your email that went the moderator):

You've fixed the aso:GArent vs aso:User.


--
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh:<http://www.w3.org/ns/shacl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:<http://www.example.org/#> .
@prefix aso:   <http://www.semanticweb.org/aso#> .
@prefix schema: <http://schema.org/#> .

aso:alice a aso:User ;
   schema:givenName "Alice" ;
   schema:familyName "Cooper" ;
   schema:name "Alice Cooper" .

aso:bob a aso:User ;
   schema:givenName "Bob" ;
   schema:familyName "Smith" ;
   schema:name "Robert Smith" .
--
and shapes
------
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh:<http://www.w3.org/ns/shacl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:<http://www.example.org/#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix aso:   <http://www.semanticweb.org/aso#> .
@prefix schema: <http://schema.org/#> .

aso:UserShape a sh:NodeShape ;
  sh:targetClass aso:User ;
  sh:sparql [
a sh:SPARQLConstraint ;
sh:message
"schema:name must equal schema:givenName + schema:familyName";
  sh:prefixes [
sh:declare [
  sh:prefix "schema" ;
  sh:namespace "http://schema.org/"^^xsd:anyURI ;
]
  ] ;
  sh:select
"""SELECT $this (schema:name AS ?path) (?name as ?value)
   WHERE {
  $this schema:name ?name .
  $this schema:givenName ?givenName .
  $this schema:familyName ?familyName .
  FILTER (!isLiteral (?name) ||
 !isLiteral (?givenName) ||
 !isLiteral (?familyName) ||
 concat( str(?givenName), ' ',  str(?familyName)) !=?name)
   }
""" ;
  ] .

There are 2 problems:

1: The sh:namespace is wrong, missing a "#"

"http://schema.org/#"^^xsd:anyURI

2: The SPARQL query has an undefined usage:

FILTER (!isLiteral (?name)

but ?name isn't defined until SELECT (?name as ?value)
making the filter false always

Fixed version:

@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix sh:<http://www.w3.org/ns/shacl#> .
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:<http://www.example.org/#> .
@prefix owl:   <http://www.w3.org/2002/07/owl#> .
@prefix aso:   <http://www.semanticweb.org/aso#> .
@prefix schema: <http://schema.org/#> .

aso:UserShape a sh:NodeShape ;
  sh:targetClass aso:User ;

  sh:sparql [
a sh:SPARQLConstraint ;
sh:message "schema:name must equal schema:givenName + 
schema:familyName";

  sh:prefixes [
sh:declare [
  sh:prefix "schema" ;
  ##1 sh:namespace "http://schema.org/"^^xsd:anyURI ;
  sh:namespace "http://schema.org/#"^^xsd:anyURI ;
]
  ] ;
  sh:select
##2  FILTER
"""SELECT $this (schema:name AS ?path) (?name as ?value)
   WHERE {
  $this schema:name ?name .
  $this schema:givenName ?givenName .
  $this schema:familyName ?familyName .
  FILTER (
  !isLiteral (?givenName) ||
  !isLiteral (?familyName) ||
  concat( str(?givenName), ' ',  str(?familyName)) !=?name)
   }
""" ;
  ] .

gives:

@prefix aso:<http://www.semanticweb.org/aso#> .
@prefix ex: <http://www.example.org/#> .
@prefix owl:<http://www.w3.org/2002/07/owl#> .
@prefix rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:   <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <http://schema.org/#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix xsd:<http://www.w3.org/2001/XMLSchema#> .

[ rdf:type sh:ValidationReport ;
  sh:conforms  false ;
  sh:result
 [ rdf:type  sh:ValidationResult ;
   sh:focusNode  aso:bob ;
   sh:resultMessage
"schema:name must equal schema:givenName + schema:familyName" ;
   sh:resultPath schema:name ;
   sh:resultSeverity sh:Violation ;
   sh:sourceConstraintComponent  sh:SPARQLConstraintComponent ;
   sh:sourceShapeaso:UserShape ;
   sh:value  "Robert Smith"
]
] .

Andy


On 05/08/2021 19:44, Alani, Yasir wrote:

Hello,



Thank you for your previous email.



I am trying to use SHACL-SPARQL to validate some 

SHACL-SPARQL

[Alani, Yasir]

Hello,



Thank you for your previous email.



I am trying to use SHACL-SPARQL to validate some data and it does not seem to 
work as intended. I am trying to validate an example (shape and data) found in 
the book "Validating RDF data".





The shape is as follows:



:UserShape a sh:NodeShape ;

sh:targetClass :User ; //all instances of class user must conform to the 
following SPARQL constraint

sh:sparql [

a sh:SPARQLConstraint ;

sh:message "schema:name must equal schema:givenName + schema:familyName"; 
//this is what I would like the constraint to do

sh:prefixes [

sh:declare [

sh:prefix "schema" ;

sh:namespace "http://schema.org/"^^xsd:anyURI ;

]

] ;

sh:select"""

SELECT $this (schema:name AS ?path) (?name as ?value)

WHERE {

$this schema:name ?name .

$this schema:givenName ?givenName .

$this schema:familyName ?familyName .

FILTER (!isLiteral (?value) ||

!isLiteral (?givenName) ||

!isLiteral (?familyName) ||

concat( str(?givenName), ' ',  str(?familyName)) !=?name

)

}""" ;

] .





The data graph is as follows:



:Alice a :User ;

schema:givenName "Alice" ;

schema:familyName "Cooper" ;

schema:name "Alice Cooper" .



:Bob a :User ;

schema:givenName "Bob" ;

schema:familyName "Smith" ;

schema:name "Robert Smith" .





The Jena code is as follows:



public class ValidationTest {



public static void main(String[] args) {



String SHAPE = "C:\\Users\\Test.txt" ;

String DATA = "C:\\Users\\TestData.txt" ;



Graph shapesGraph = RDFDataMgr.loadGraph(SHAPE, 
Lang.TURTLE) ;

Graph dataGraph = RDFDataMgr.loadGraph(DATA, 
Lang.TURTLE) ;



Shapes shapes = Shapes.parse(shapesGraph) ;



ShaclValidator validator = ShaclValidator.get()  ;

ValidationReport report = 
validator.validate(shapesGraph, dataGraph) ;



System.out.println() ;

RDFDataMgr.write(System.out, report.getModel(), 
Lang.TTL) ;

}

}



The validation result is as follows:





[ ash:ValidationReport ;

  sh:conforms  true

] .



As you can see, one node should conform and one node should not, but this is 
not what I am getting as a validation result. Please advise.



Thank you very much

Yasir

SHACL for referential integrity constraints

[Piotr Nowara]

Hi,

does anyone use SHACL for implementing integrity constraints in Jena/Fuseki
graphs? My use case involves SQL-like checks like not letting delete a
triple if its subject is referred somewhere else in the same graph. Or
maybe you think it is much easier to implement it in pure SPARQL using ASK
queries?

And is it possible to define SHACL constraints between different A) graphs
B) datasets?

Thanks,
Piotr

Re: SHACL warning about cycle

[Florian Kleedorfer]

Thanks for the explanation!
Best regards,
Florian

Am 2020-12-10 17:59, schrieb Andy Seaborne:

On 10/12/2020 13:03, Florian Kleedorfer wrote:

Hi,

I am not aware of anything in the SHACL specs discouraging cycles in 
shapes, but the jena SHACL parser warns about it:


10.12.20 13:53:11.460 [main] WARN  SHACL -  Cycle detected : node 
<https://example.com/test/PersonShape>


for this minimal example:

@prefix ex:   <https://example.com/test/> .
@prefix sh:   <http://www.w3.org/ns/shacl#> .

ex:PersonShape
     a sh:NodeShape;
     sh:targetClass ex:Person ;
     sh:property [ sh:path ex:mother ;
     sh:node ex:PersonShape ] .

ex:alice a ex:Person .

ex:bob a ex:Person ;
     ex:mother ex:alice .


Is that intended behaviour?


There are two ways to get to the same data objects.

Via the sh:targetClass and also via the path from another
ex:PersonShape -- you'll get two violations.

Did you mean:

 sh:property [ sh:path ex:mother ;
   sh:class ex:PersonShape ] .
   

because pointing (sh:node) to the shape is also picking up the target.

You'll still get validation of ex:mother-ex:mother-ex:mother because
the target will trigger on each person.

You can sh:node to a common shape but if that is for reuse of common
patterns, then don't give that shape a target.

Andy

(See also discussion about cycles on the public-rdf-sha...@w3.org 
mailing list)



Does that mean we should try to get rid of any cycles?
Or, alternatively, could we lower the loglevel on this one?

Cheers,
Florian

Re: SHACL warning about cycle

[Andy Seaborne]

On 10/12/2020 13:03, Florian Kleedorfer wrote:

Hi,

I am not aware of anything in the SHACL specs discouraging cycles in 
shapes, but the jena SHACL parser warns about it:


10.12.20 13:53:11.460 [main] WARN  SHACL -  Cycle detected : node 
<https://example.com/test/PersonShape>


for this minimal example:

@prefix ex:   <https://example.com/test/> .
@prefix sh:   <http://www.w3.org/ns/shacl#> .

ex:PersonShape
     a sh:NodeShape;
     sh:targetClass ex:Person ;
     sh:property [ sh:path ex:mother ;
     sh:node ex:PersonShape ] .

ex:alice a ex:Person .

ex:bob a ex:Person ;
     ex:mother ex:alice .


Is that intended behaviour?


There are two ways to get to the same data objects.

Via the sh:targetClass and also via the path from another ex:PersonShape 
-- you'll get two violations.


Did you mean:

 sh:property [ sh:path ex:mother ;
   sh:class ex:PersonShape ] .
   

because pointing (sh:node) to the shape is also picking up the target.

You'll still get validation of ex:mother-ex:mother-ex:mother because the 
target will trigger on each person.


You can sh:node to a common shape but if that is for reuse of common 
patterns, then don't give that shape a target.


Andy

(See also discussion about cycles on the public-rdf-sha...@w3.org 
mailing list)


Does that mean we should try to get rid of 
any cycles?

Or, alternatively, could we lower the loglevel on this one?

Cheers,
Florian

SHACL warning about cycle

[Florian Kleedorfer]

Hi,

I am not aware of anything in the SHACL specs discouraging cycles in 
shapes, but the jena SHACL parser warns about it:


10.12.20 13:53:11.460 [main] WARN  SHACL -  Cycle detected : node 
<https://example.com/test/PersonShape>


for this minimal example:

@prefix ex:   <https://example.com/test/> .
@prefix sh:   <http://www.w3.org/ns/shacl#> .

ex:PersonShape
a sh:NodeShape;
sh:targetClass ex:Person ;
sh:property [ sh:path ex:mother ;
sh:node ex:PersonShape ] .

ex:alice a ex:Person .

ex:bob a ex:Person ;
ex:mother ex:alice .


Is that intended behaviour? Does that mean we should try to get rid of 
any cycles?

Or, alternatively, could we lower the loglevel on this one?

Cheers,
Florian

Re: SHACL demo files

[Erich Bremer]

Okay, I will try to make them myself then.  Thanks Andy!  - Erich

On Wed, Dec 2, 2020 at 4:34 PM Andy Seaborne  wrote:

> Th examples show how to use the API.
>
> "shapes.ttl" and "data?.ttl" stand for the files you wish to use with
> the API.
>
>  Andy
>
> On 02/12/2020 19:24, Erich Bremer wrote:
> > For the two examples at:
> >
> >
> https://github.com/apache/jena/tree/master/jena-shacl/src/main/java/org/apache/jena/shacl/examples
> >
> > where are the shapes.ttl and data1.ttl files?  Are there versions of them
> > that work for the demo?  - Erich
> >
>

Re: SHACL, target all nodes, vocabulary element check,

[Andy Seaborne]

On 02/12/2020 10:48, Andy Seaborne wrote:

Hi Martin,

I am guessing this isbecause advanced features 
(https://www.w3.org/TR/shacl-af) are not supported?


Correct.

A trick ("pattern") is to use sh:targetNode because that always gets 
triggered, whether the object node is in the data or not and even if the 
data graph is empty.


---

In this case what might help is sh:path and a long alternative path 
except that's verbose. For some reason I never understood, the list in 
sh:alternativePath is only ever a pair so you end up with nesting.


That ^^^ bit is wrong - the list of sh:alternativePath is two or more, 
not restricted to a pair.


(thanks Holger for pointing that out).

Andy

SHACL compact syntax can write it compactly which, if nothing else, can 
be used to generate the RDF ("shacl print --out rdf")


shape ex:shape2 {
  targetNode = :WhatEver .
  ex:A|ex:B|ex:C  datatype=xsd:integer .
  }

     HTH
     Andy

Contributions for adding shacl-af features welcome!

On 02/12/2020 10:16, Martin G. Skjæveland wrote:

Hi all,

using SHACL I am trying to implement a check for identifying typically 
typos when using standard vocabularies such as RDF, RDFS and OWL, 
e.g., rdf:label should be rdf*s*:label.


Here is an attempt at finding IRIs in rdfs namespace but that are not 
defined in the standard vocabulary:


[] a sh:NodeShape ;
   sh:name "RDFS vocabulary element." ;
   sh:message "Unrecognised RDFS vocabulary element. Check spelling." ;
   sh:target [
 a sh:SPARQLTarget ;
 sh:select """
   SELECT ?this
   WHERE { { ?this ?p ?o }
 UNION { ?s ?this ?o }
 UNION { ?s ?p ?this }
   FILTER (isIRI(?this) && STRSTARTS(STR(?this), 
"http://www.w3.org/2000/01/rdf-schema#";))

  } """ ;
 ] ;
   sh:in ( rdfs:Class rdfs:Container rdfs:ContainerMembershipProperty 
rdfs:Datatype rdfs:Literal rdfs:Resource rdfs:comment rdfs:domain 
rdfs:isDefinedBy rdfs:label rdfs:member rdfs:range rdfs:seeAlso 
rdfs:subClassOf rdfs:subPropertyOf )

.

This does not work with jena-shacl version 3.16. I am guessing this 
isbecause advanced features (https://www.w3.org/TR/shacl-af) are not 
supported? https://jena.apache.org/documentation/shacl/ says: "It 
implements SHACL Core and SHACL SPARQL Constraints."


Is there a different way of selecting all IRIs as target, which is 
also supported by jena-shacl? Or maybe a better way of doing this?


Thanks!

Martin

Re: SHACL demo files

[Andy Seaborne]

Th examples show how to use the API.

"shapes.ttl" and "data?.ttl" stand for the files you wish to use with 
the API.


Andy

On 02/12/2020 19:24, Erich Bremer wrote:

For the two examples at:

https://github.com/apache/jena/tree/master/jena-shacl/src/main/java/org/apache/jena/shacl/examples

where are the shapes.ttl and data1.ttl files?  Are there versions of them
that work for the demo?  - Erich

SHACL demo files

[Erich Bremer]

For the two examples at:

https://github.com/apache/jena/tree/master/jena-shacl/src/main/java/org/apache/jena/shacl/examples

where are the shapes.ttl and data1.ttl files?  Are there versions of them
that work for the demo?  - Erich

Re: SHACL, target all nodes, vocabulary element check,

[Martin G . Skjæveland]

Thanks! I did not understand your tip on sh:path, but the sh:targetNode 
tip did the trick.


This works:

_:RDFSVocabularyTokenShape a sh:NodeShape ;
  sh:targetNode ex:ANY_NODE ; ## matches any node
  sh:name "RDFS vocabulary element." ;
  sh:message "Unrecognised RDFS vocabulary element. Check spelling." ;
  sh:sparql [ a sh:SPARQLConstraint ;
sh:select """
  PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  SELECT ?value
  WHERE { { ?value ?p ?o }
UNION { ?s ?value ?o }
UNION { ?s ?p ?value }
  FILTER (isIRI(?value) && STRSTARTS(STR(?value), 
"http://www.w3.org/2000/01/rdf-schema#";))
  FILTER (?value NOT IN ( rdfs:Class, rdfs:Container, 
rdfs:ContainerMembershipProperty, rdfs:Datatype, rdfs:Literal, 
rdfs:Resource, rdfs:comment, rdfs:domain, rdfs:isDefinedBy, rdfs:label, 
rdfs:member, rdfs:range, rdfs:seeAlso, rdfs:subClassOf, 
rdfs:subPropertyOf ) ) }  """ ]

.


Validating this input:

  [] rdfs:asdf [] .

gives me this report:

[ ash:ValidationReport ;
  sh:conforms  false ;
  sh:result[ a sh:ValidationResult ;
 sh:focusNode  ex:ANY_NODE ;
 sh:resultMessage  "Unrecognised RDFS 
vocabulary element. Check spelling." ;

 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent 
sh:SPARQLConstraintComponent ;

 sh:sourceShape[]  ;
 sh:value  rdfs:asdf
   ]
] .


Martin

On 02/12/2020 11:48, Andy Seaborne wrote:

Hi Martin,

I am guessing this isbecause advanced features 
(https://www.w3.org/TR/shacl-af) are not supported?


Correct.

A trick ("pattern") is to use sh:targetNode because that always gets 
triggered, whether the object node is in the data or not and even if the 
data graph is empty.


---

In this case what might help is sh:path and a long alternative path 
except that's verbose. For some reason I never understood, the list in 
sh:alternativePath is only ever a pair so you end up with nesting.


SHACL compact syntax can write it compactly whioch, if nothing else, can 
be used to generate the RDF ("shacl print --out rdf")


shape ex:shape2 {
  targetNode = :WhatEver .
  ex:A|ex:B|ex:C  datatype=xsd:integer .
  }

     HTH
     Andy

Contributions for adding shacl-af features welcome!

On 02/12/2020 10:16, Martin G. Skjæveland wrote:

Hi all,

using SHACL I am trying to implement a check for identifying typically 
typos when using standard vocabularies such as RDF, RDFS and OWL, 
e.g., rdf:label should be rdf*s*:label.


Here is an attempt at finding IRIs in rdfs namespace but that are not 
defined in the standard vocabulary:


[] a sh:NodeShape ;
   sh:name "RDFS vocabulary element." ;
   sh:message "Unrecognised RDFS vocabulary element. Check spelling." ;
   sh:target [
 a sh:SPARQLTarget ;
 sh:select """
   SELECT ?this
   WHERE { { ?this ?p ?o }
 UNION { ?s ?this ?o }
 UNION { ?s ?p ?this }
   FILTER (isIRI(?this) && STRSTARTS(STR(?this), 
"http://www.w3.org/2000/01/rdf-schema#";))

  } """ ;
 ] ;
   sh:in ( rdfs:Class rdfs:Container rdfs:ContainerMembershipProperty 
rdfs:Datatype rdfs:Literal rdfs:Resource rdfs:comment rdfs:domain 
rdfs:isDefinedBy rdfs:label rdfs:member rdfs:range rdfs:seeAlso 
rdfs:subClassOf rdfs:subPropertyOf )

.

This does not work with jena-shacl version 3.16. I am guessing this 
isbecause advanced features (https://www.w3.org/TR/shacl-af) are not 
supported? https://jena.apache.org/documentation/shacl/ says: "It 
implements SHACL Core and SHACL SPARQL Constraints."


Is there a different way of selecting all IRIs as target, which is 
also supported by jena-shacl? Or maybe a better way of doing this?


Thanks!

Martin

Re: SHACL, target all nodes, vocabulary element check,

[Andy Seaborne]

Hi Martin,

I am guessing this 
isbecause advanced features (https://www.w3.org/TR/shacl-af) are not 
supported?


Correct.

A trick ("pattern") is to use sh:targetNode because that always gets 
triggered, whether the object node is in the data or not and even if the 
data graph is empty.


---

In this case what might help is sh:path and a long alternative path 
except that's verbose. For some reason I never understood, the list in 
sh:alternativePath is only ever a pair so you end up with nesting.


SHACL compact syntax can write it compactly whioch, if nothing else, can 
be used to generate the RDF ("shacl print --out rdf")


shape ex:shape2 {
 targetNode = :WhatEver .
 ex:A|ex:B|ex:C  datatype=xsd:integer .
 }

HTH
Andy

Contributions for adding shacl-af features welcome!

On 02/12/2020 10:16, Martin G. Skjæveland wrote:

Hi all,

using SHACL I am trying to implement a check for identifying typically 
typos when using standard vocabularies such as RDF, RDFS and OWL, e.g., 
rdf:label should be rdf*s*:label.


Here is an attempt at finding IRIs in rdfs namespace but that are not 
defined in the standard vocabulary:


[] a sh:NodeShape ;
   sh:name "RDFS vocabulary element." ;
   sh:message "Unrecognised RDFS vocabulary element. Check spelling." ;
   sh:target [
     a sh:SPARQLTarget ;
     sh:select """
   SELECT ?this
   WHERE { { ?this ?p ?o }
     UNION { ?s ?this ?o }
     UNION { ?s ?p ?this }
   FILTER (isIRI(?this) && STRSTARTS(STR(?this), 
"http://www.w3.org/2000/01/rdf-schema#";))

  } """ ;
     ] ;
   sh:in ( rdfs:Class rdfs:Container rdfs:ContainerMembershipProperty 
rdfs:Datatype rdfs:Literal rdfs:Resource rdfs:comment rdfs:domain 
rdfs:isDefinedBy rdfs:label rdfs:member rdfs:range rdfs:seeAlso 
rdfs:subClassOf rdfs:subPropertyOf )

.

This does not work with jena-shacl version 3.16. I am guessing this 
isbecause advanced features (https://www.w3.org/TR/shacl-af) are not 
supported? https://jena.apache.org/documentation/shacl/ says: "It 
implements SHACL Core and SHACL SPARQL Constraints."


Is there a different way of selecting all IRIs as target, which is also 
supported by jena-shacl? Or maybe a better way of doing this?


Thanks!

Martin

SHACL, target all nodes, vocabulary element check,

[Martin G . Skjæveland]

Hi all,

using SHACL I am trying to implement a check for identifying typically 
typos when using standard vocabularies such as RDF, RDFS and OWL, e.g., 
rdf:label should be rdf*s*:label.


Here is an attempt at finding IRIs in rdfs namespace but that are not 
defined in the standard vocabulary:


[] a sh:NodeShape ;
  sh:name "RDFS vocabulary element." ;
  sh:message "Unrecognised RDFS vocabulary element. Check spelling." ;
  sh:target [
a sh:SPARQLTarget ;
sh:select """
  SELECT ?this
  WHERE { { ?this ?p ?o }
UNION { ?s ?this ?o }
UNION { ?s ?p ?this }
  FILTER (isIRI(?this) && STRSTARTS(STR(?this), 
"http://www.w3.org/2000/01/rdf-schema#";))

 } """ ;
] ;
  sh:in ( rdfs:Class rdfs:Container rdfs:ContainerMembershipProperty 
rdfs:Datatype rdfs:Literal rdfs:Resource rdfs:comment rdfs:domain 
rdfs:isDefinedBy rdfs:label rdfs:member rdfs:range rdfs:seeAlso 
rdfs:subClassOf rdfs:subPropertyOf )

.

This does not work with jena-shacl version 3.16. I am guessing this 
isbecause advanced features (https://www.w3.org/TR/shacl-af) are not 
supported? https://jena.apache.org/documentation/shacl/ says: "It 
implements SHACL Core and SHACL SPARQL Constraints."


Is there a different way of selecting all IRIs as target, which is also 
supported by jena-shacl? Or maybe a better way of doing this?


Thanks!

Martin

Re: Access to private fields in SHACL Constraints?

[Andy Seaborne]

No problem .. and the compact writer has magic access so there can be 
missing accessors. (I though it was the other, visitor-like, design.)


Andy

On 24/11/2020 18:32, Florian Kleedorfer wrote:


Ok, will do. Sorry the example I gave was outdated, I realized that when 
I checked out the latest sources (I was on 3.16.0). There are still some 
accessors to add.


Best,
Florian

Am 2020-11-24 17:34, schrieb Andy Seaborne:


Yes, please put in a PR for anything missing.

There is compact syntax writer in 3.17.0 and it needs access to
constraints details so it can print so most should be here.

I do see in the current codebase: NodeKindConstraint.getKind()

    Andy

https://github.com/apache/jena/blob/master/jena-shacl/src/main/java/org/apache/jena/shacl/engine/constraint/NodeKindConstraint.java#L58 




On 24/11/2020 12:41, Florian Kleedorfer wrote:

Hi,

I am developing a program based on Jena/SHACL and I think I need a 
small adaptation.


What I want to achieve:
- analyze shacl shapes and generate java class files
- read shapes and data and instantiate objects representing the data

While doing that, I realized that the properties of the 
Constraint-implementations in 
`org.apache.jena.shacl.engine.constraint` are not accessible. E.g. in 
`NodeKindConstraint`, the field `kind` is private, and it has no 
getter method. In the current SHACL use case of jena, the Constraints 
don't need to be accessible (they just check their respective 
conditions). In my use case, I'll need to access that information for 
determining property types etc. (e.g by analyzing sh:nodeKind) and 
therefore need to access the constraints.


Would it be possible to make the Constraints' properties accessible 
with public getters?


I could prepare a PR if that's ok.

Best regards,
Florian

Re: Access to private fields in SHACL Constraints?

[Florian Kleedorfer]

Ok, will do. Sorry the example I gave was outdated, I realized that when 
I checked out the latest sources (I was on 3.16.0). There are still some 
accessors to add.


Best,
Florian

Am 2020-11-24 17:34, schrieb Andy Seaborne:


Yes, please put in a PR for anything missing.

There is compact syntax writer in 3.17.0 and it needs access to
constraints details so it can print so most should be here.

I do see in the current codebase: NodeKindConstraint.getKind()

Andy

https://github.com/apache/jena/blob/master/jena-shacl/src/main/java/org/apache/jena/shacl/engine/constraint/NodeKindConstraint.java#L58


On 24/11/2020 12:41, Florian Kleedorfer wrote:

Hi,

I am developing a program based on Jena/SHACL and I think I need a 
small adaptation.


What I want to achieve:
- analyze shacl shapes and generate java class files
- read shapes and data and instantiate objects representing the data

While doing that, I realized that the properties of the 
Constraint-implementations in 
`org.apache.jena.shacl.engine.constraint` are not accessible. E.g. in 
`NodeKindConstraint`, the field `kind` is private, and it has no 
getter method. In the current SHACL use case of jena, the Constraints 
don't need to be accessible (they just check their respective 
conditions). In my use case, I'll need to access that information for 
determining property types etc. (e.g by analyzing sh:nodeKind) and 
therefore need to access the constraints.


Would it be possible to make the Constraints' properties accessible 
with public getters?


I could prepare a PR if that's ok.

Best regards,
Florian

Re: Access to private fields in SHACL Constraints?

[Andy Seaborne]

Yes, please put in a PR for anything missing.

There is compact syntax writer in 3.17.0 and it needs access to 
constraints details so it can print so most should be here.


I do see in the current codebase: NodeKindConstraint.getKind()

Andy

https://github.com/apache/jena/blob/master/jena-shacl/src/main/java/org/apache/jena/shacl/engine/constraint/NodeKindConstraint.java#L58


On 24/11/2020 12:41, Florian Kleedorfer wrote:

Hi,

I am developing a program based on Jena/SHACL and I think I need a small 
adaptation.


What I want to achieve:
- analyze shacl shapes and generate java class files
- read shapes and data and instantiate objects representing the data

While doing that, I realized that the properties of the 
Constraint-implementations in `org.apache.jena.shacl.engine.constraint` 
are not accessible. E.g. in `NodeKindConstraint`, the field `kind` is 
private, and it has no getter method. In the current SHACL use case of 
jena, the Constraints don't need to be accessible (they just check their 
respective conditions). In my use case, I'll need to access that 
information for determining property types etc. (e.g by analyzing 
sh:nodeKind) and therefore need to access the constraints.


Would it be possible to make the Constraints' properties accessible with 
public getters?


I could prepare a PR if that's ok.

Best regards,
Florian

Access to private fields in SHACL Constraints?

[Florian Kleedorfer]

Hi,

I am developing a program based on Jena/SHACL and I think I need a small 
adaptation.


What I want to achieve:
- analyze shacl shapes and generate java class files
- read shapes and data and instantiate objects representing the data

While doing that, I realized that the properties of the 
Constraint-implementations in `org.apache.jena.shacl.engine.constraint` 
are not accessible. E.g. in `NodeKindConstraint`, the field `kind` is 
private, and it has no getter method. In the current SHACL use case of 
jena, the Constraints don't need to be accessible (they just check their 
respective conditions). In my use case, I'll need to access that 
information for determining property types etc. (e.g by analyzing 
sh:nodeKind) and therefore need to access the constraints.


Would it be possible to make the Constraints' properties accessible with 
public getters?


I could prepare a PR if that's ok.

Best regards,
Florian

Re: SHACL: parse does not have --out

[Adrian Gschwend]

On 24.11.20 00:37, Andy Seaborne wrote:

Hi Andy,

> (3.17.0 will have compact syntax output, 3.16.0 does not)

Ah that explains, thanks for the info.

regards

Adrian

Re: SHACL: parse does not have --out

[Andy Seaborne]

On 23/11/2020 13:52, Adrian Gschwend wrote:

Hi,

According to the SHACL cli docs there should be a --out option:

shacl p --out=FMT FILE

I tried this with 3.16.0 and I get:

shacl p --out t cube-shape.ttl
Unknown argument: out

did that get lost somewhere?


The reverse!

Seems like the 3.17.0 documentation got published.

"shacl print --help" is right.

(3.17.0 will have compact syntax output, 3.16.0 does not)

Andy



regards

Adrian

SHACL: parse does not have --out

[Adrian Gschwend]

Hi,

According to the SHACL cli docs there should be a --out option:

shacl p --out=FMT FILE

I tried this with 3.16.0 and I get:

shacl p --out t cube-shape.ttl
Unknown argument: out

did that get lost somewhere?

regards

Adrian

Re: Aw: Re: SHACL validation doesn't show an error

[Thomas Francart]

Hello

Le lun. 2 nov. 2020 à 08:52, Lorenz Buehmann <
buehm...@informatik.uni-leipzig.de> a écrit :

> I suggested to use SHACL but I thought it's clear that you need to
> create the corresponding SHACL shapes then - I should be more specific
> in the future.
>
> Regarding your question, no this still won't work. Maybe you didn't
> understand the issue at all, but in OWL you have two things to keep in
> mind:
>
> a) Open World Assumption (OWA)
> b) no Unique Names Assumption (UNA)
>
> the UNA basically means that having entities with different URIs does
> not guarantee that those entities are distinct. With owl:AllDifferent
> you basically avoid this.
>
> But ... this does not solve the OWA behavior. Especially with standard
> reasoning, like rule-based or something like tableau algorithm for full
> OWL DL, you won't get any "violations".
>
> What you need is either something to close the world or you use some
> constraint validation mechanism. In Jena you have out-of-the-box SHACL
> support. There are also other constraint languages like SHeX, Pellet ICV
> (now commercial part of Stardog only), etc.
>
> For OWL there are indeed some approaches to convert (parts of) the
> schema to SHACL shapes, e.g.
> https://www.topquadrant.com/from-owl-to-shacl-in-an-automated-way/
>
>
>From that excellent article mentionned above, I have derived simpler
rulesets to convert OWL to SHACL :
https://shacl-play.sparna.fr/play/rules-catalog
The SHACL Play application provides a free owl 2 shacl transformer using
these rules. And also free SHACL validation with human-readable report,
based on TopQuadrant's API.
The rules are not perfect, this is work in progress and the rulesets might
be adjusted in the future, especially regarding inheritance mechanisms and
closed shapes.

Best Regards
Thomas


> So my suggestion, write the SHACL shapes or rethink your infrastructure
> if you don't want to stick to Jena + SHACL
>
>
> On 02.11.20 03:49, alexander.fan...@web.de wrote:
> > Thanks for your answer :) Is there a way to validate the two files (
> data.rdf and schema.rdf ) as .rdf? So without changing the schema... ? I
> tried with the jena reasoner and with adding ALLDifferent to deny the open
> world assumption, but that doesnt help.... ?
> >
> > Alex
> >
> >
> >
> >
> > Gesendet: Sonntag, 01. November 2020 um 12:13 Uhr
> > Von: "Andy Seaborne" 
> > An: users@jena.apache.org
> > Betreff: Re: SHACL validation doesn't show an error
> > SHACL uses shapes - not RDFS range and domain
> >
> > "rdfs:range iirds:Component ;" means the range
> > "is of that class" not that there must be that triple because RDFS can
> > be used to infer the fact and add it to the data.
> >
> > See the SHACL spec : https://www.w3.org/TR/shacl/
> > which has lots of examples of shapes.
> >
> > In this case:
> >
> > In schema.ttl:
> >
> > ----
> > PREFIX iirds: <
> http://iirds.tekom.de/iirds#[http://iirds.tekom.de/iirds#]>
> > PREFIX rdf: <
> http://www.w3.org/1999/02/22-rdf-syntax-ns#[http://www.w3.org/1999/02/22-rdf-syntax-ns#]
> >
> > PREFIX rdfs: <
> http://www.w3.org/2000/01/rdf-schema#[http://www.w3.org/2000/01/rdf-schema#]
> >
> > PREFIX sh: <http://www.w3.org/ns/shacl#[http://www.w3.org/ns/shacl#]>
> > PREFIX xsd: <
> http://www.w3.org/2001/XMLSchema#[http://www.w3.org/2001/XMLSchema#]>
> > PREFIX : <http://example/>
> >
> > :shape1 sh:targetObjectsOf iirds:has-component ;
> > sh:class iirds:Component ;
> > .
> > 
> >
> > and you'll get a violation
> >
> > Add the expected triple to metadata.ttl:
> > 
> > <
> http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de[http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de]
> >
> > rdf:type iirds:Component .
> > 
> >
> > and the violation goes away.
> >
> > From the commandline (shell scripts):
> >
> > Jena SHACL engine:
> >
> > shacl v -s schema.ttl -d metadata.ttl
> >
> > or see the instructions on
> https://github.com/TopQuadrant/shacl[https://github.com/TopQuadrant/shacl]
> for
> > TopQuadrant TopBraid SHACL API
> >
> > shaclvalidate -shapesfile schema.ttl -datafile metadata.ttl
> >
> > Andy
> >
> > On 01/11/2020 02:11, alexander.fan...@web.de wrote:
> >> Hey guys,
> >> i created an Issue one weeg ago and you recommended me to validate my
> schema with jena shacl. I did this, but i still d

Re: Aw: Re: SHACL validation doesn't show an error

[Lorenz Buehmann]

I suggested to use SHACL but I thought it's clear that you need to
create the corresponding SHACL shapes then - I should be more specific
in the future.

Regarding your question, no this still won't work. Maybe you didn't
understand the issue at all, but in OWL you have two things to keep in
mind:

a) Open World Assumption (OWA)
b) no Unique Names Assumption (UNA)

the UNA basically means that having entities with different URIs does
not guarantee that those entities are distinct. With owl:AllDifferent
you basically avoid this.

But ... this does not solve the OWA behavior. Especially with standard
reasoning, like rule-based or something like tableau algorithm for full
OWL DL, you won't get any "violations".

What you need is either something to close the world or you use some
constraint validation mechanism. In Jena you have out-of-the-box SHACL
support. There are also other constraint languages like SHeX, Pellet ICV
(now commercial part of Stardog only), etc.

For OWL there are indeed some approaches to convert (parts of) the
schema to SHACL shapes, e.g.
https://www.topquadrant.com/from-owl-to-shacl-in-an-automated-way/

So my suggestion, write the SHACL shapes or rethink your infrastructure
if you don't want to stick to Jena + SHACL


On 02.11.20 03:49, alexander.fan...@web.de wrote:
> Thanks for your answer :) Is there a way to validate the two files ( data.rdf 
> and schema.rdf ) as .rdf? So without changing the schema... ? I tried with 
> the jena reasoner and with adding ALLDifferent to deny the open world 
> assumption, but that doesnt help ? 
>  
> Alex
>  
>  
>  
>
> Gesendet: Sonntag, 01. November 2020 um 12:13 Uhr
> Von: "Andy Seaborne" 
> An: users@jena.apache.org
> Betreff: Re: SHACL validation doesn't show an error
> SHACL uses shapes - not RDFS range and domain
>
> "rdfs:range iirds:Component ;" means the range
> "is of that class" not that there must be that triple because RDFS can
> be used to infer the fact and add it to the data.
>
> See the SHACL spec : https://www.w3.org/TR/shacl/
> which has lots of examples of shapes.
>
> In this case:
>
> In schema.ttl:
>
> 
> PREFIX iirds: <http://iirds.tekom.de/iirds#[http://iirds.tekom.de/iirds#]>
> PREFIX rdf: 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#[http://www.w3.org/1999/02/22-rdf-syntax-ns#]>
> PREFIX rdfs: 
> <http://www.w3.org/2000/01/rdf-schema#[http://www.w3.org/2000/01/rdf-schema#]>
> PREFIX sh: <http://www.w3.org/ns/shacl#[http://www.w3.org/ns/shacl#]>
> PREFIX xsd: 
> <http://www.w3.org/2001/XMLSchema#[http://www.w3.org/2001/XMLSchema#]>
> PREFIX : <http://example/>
>
> :shape1 sh:targetObjectsOf iirds:has-component ;
> sh:class iirds:Component ;
> .
> 
>
> and you'll get a violation
>
> Add the expected triple to metadata.ttl:
> 
> <http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de[http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de]>
> rdf:type iirds:Component .
> 
>
> and the violation goes away.
>
> From the commandline (shell scripts):
>
> Jena SHACL engine:
>
> shacl v -s schema.ttl -d metadata.ttl
>
> or see the instructions on 
> https://github.com/TopQuadrant/shacl[https://github.com/TopQuadrant/shacl] for
> TopQuadrant TopBraid SHACL API
>
> shaclvalidate -shapesfile schema.ttl -datafile metadata.ttl
>
> Andy
>
> On 01/11/2020 02:11, alexander.fan...@web.de wrote:
>> Hey guys,
>> i created an Issue one weeg ago and you recommended me to validate my schema 
>> with jena shacl. I did this, but i still don't get the expected result...
>> What do i have to change or what mistake did i do ? (i am not allowed to 
>> change the schema by the way).
>> Maybe you have some example code or another idea how to validate my 
>> metadata.rdf ?
>>
>> The problem:
>> As you can see, i have a "topic" containing the property "has-component", 
>> but my schema just allows (rdfs:domain and rdfs:range) a "component" with 
>> the property "has-component".
>> The validation report says in both ways, that everything is confirm..
>>
>> Thanks for you help:)
>> Greetings from Germany
>> Alex
>>
>>
>>
>> My schema is original an .rdf-schema, but i converted it into .ttl in order 
>> to use shacl-shapes. It looks like the following:
>>
>> schema.ttl:
>>
>> @prefix schema: <http://schema.org/[http://schema.org/]> .
>> @prefix rdf: 
>> <http://www.w3.org/1999/02/22-rdf-syntax-ns#[http://www.w3.org/1999/02/22-rdf-syntax-ns#]&

Aw: Re: SHACL validation doesn't show an error

[alexander . fandre]

Thanks for your answer :) Is there a way to validate the two files ( data.rdf 
and schema.rdf ) as .rdf? So without changing the schema... ? I tried with the 
jena reasoner and with adding ALLDifferent to deny the open world assumption, 
but that doesnt help ? 
 
Alex
 
 
 

Gesendet: Sonntag, 01. November 2020 um 12:13 Uhr
Von: "Andy Seaborne" 
An: users@jena.apache.org
Betreff: Re: SHACL validation doesn't show an error
SHACL uses shapes - not RDFS range and domain

"rdfs:range iirds:Component ;" means the range
"is of that class" not that there must be that triple because RDFS can
be used to infer the fact and add it to the data.

See the SHACL spec : https://www.w3.org/TR/shacl/
which has lots of examples of shapes.

In this case:

In schema.ttl:


PREFIX iirds: <http://iirds.tekom.de/iirds#[http://iirds.tekom.de/iirds#]>
PREFIX rdf: 
<http://www.w3.org/1999/02/22-rdf-syntax-ns#[http://www.w3.org/1999/02/22-rdf-syntax-ns#]>
PREFIX rdfs: 
<http://www.w3.org/2000/01/rdf-schema#[http://www.w3.org/2000/01/rdf-schema#]>
PREFIX sh: <http://www.w3.org/ns/shacl#[http://www.w3.org/ns/shacl#]>
PREFIX xsd: 
<http://www.w3.org/2001/XMLSchema#[http://www.w3.org/2001/XMLSchema#]>
PREFIX : <http://example/>

:shape1 sh:targetObjectsOf iirds:has-component ;
sh:class iirds:Component ;
.


and you'll get a violation

Add the expected triple to metadata.ttl:

<http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de[http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de]>
rdf:type iirds:Component .


and the violation goes away.

>From the commandline (shell scripts):

Jena SHACL engine:

shacl v -s schema.ttl -d metadata.ttl

or see the instructions on 
https://github.com/TopQuadrant/shacl[https://github.com/TopQuadrant/shacl] for
TopQuadrant TopBraid SHACL API

shaclvalidate -shapesfile schema.ttl -datafile metadata.ttl

Andy

On 01/11/2020 02:11, alexander.fan...@web.de wrote:
> Hey guys,
> i created an Issue one weeg ago and you recommended me to validate my schema 
> with jena shacl. I did this, but i still don't get the expected result...
> What do i have to change or what mistake did i do ? (i am not allowed to 
> change the schema by the way).
> Maybe you have some example code or another idea how to validate my 
> metadata.rdf ?
>
> The problem:
> As you can see, i have a "topic" containing the property "has-component", but 
> my schema just allows (rdfs:domain and rdfs:range) a "component" with the 
> property "has-component".
> The validation report says in both ways, that everything is confirm..
>
> Thanks for you help:)
> Greetings from Germany
> Alex
>
>
>
> My schema is original an .rdf-schema, but i converted it into .ttl in order 
> to use shacl-shapes. It looks like the following:
>
> schema.ttl:
>
> @prefix schema: <http://schema.org/[http://schema.org/]> .
> @prefix rdf: 
> <http://www.w3.org/1999/02/22-rdf-syntax-ns#[http://www.w3.org/1999/02/22-rdf-syntax-ns#]>
>  .
> @prefix iirds: <http://iirds.tekom.de/iirds#[http://iirds.tekom.de/iirds#]> .
> @prefix rdfs: 
> <http://www.w3.org/2000/01/rdf-schema#[http://www.w3.org/2000/01/rdf-schema#]>
>  .
> iirds:Topic a rdfs:Class ;
> rdfs:comment "A topic is a unit of information covering a single subject."@en 
> ;
> rdfs:label "Topic"@en , "Topic"@de ;
> rdfs:subClassOf iirds:InformationUnit ;
> iirds:description "IRI: required"@en , "The resource of a topic is a file in 
> the iiRDS package."@en .
>
> iirds:has-component a rdf:Property ;
> rdfs:comment "Relates to a component that is part of another component."@en , 
> "Verweist auf eine Kompoente, die Teil einer anderen Komponente ist."@de ;
> rdfs:domain iirds:Component ;
> rdfs:label "has component"@en , "hat Komponente"@de ;
> rdfs:range iirds:Component ;
> rdfs:subPropertyOf iirds:iirdsRelationConcept ;
> iirds:description "Cardinality: 
> http://iirds.tekom.de/iirds#Component[http://iirds.tekom.de/iirds#Component] 
> [0..*]"@en , ""@en ;
> schema:domainIncludes iirds:Component ;
> schema:rangeIncludes iirds:Component .
>
> iirds:Component a rdfs:Class ;
> rdfs:comment "Describes a component of the technical system that the 
> documentation refers to."@en ;
> rdfs:label "Component"@en , "Komponente"@de ;
> rdfs:subClassOf iirds:ProductMetadata ;
> iirds:description "IRI: required"@en , "Components may have relations to 
> ot[...] The iirds#Component may also be used as a docking point for external 
> component definitions."@en .
>

Re: SHACL validation doesn't show an error

[Andy Seaborne]

SHACL uses shapes - not RDFS range and domain

"rdfs:range iirds:Component ;" means the range
"is of that class" not that there must be that triple because RDFS can 
be used to infer the fact and add it to the data.


See the SHACL spec : https://www.w3.org/TR/shacl/
which has lots of examples of shapes.

In this case:

In schema.ttl:


PREFIX iirds: <http://iirds.tekom.de/iirds#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX sh:  <http://www.w3.org/ns/shacl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX :<http://example/>

:shape1 sh:targetObjectsOf iirds:has-component ;
sh:class  iirds:Component ;
.


and you'll get a violation

Add the expected triple to metadata.ttl:

<http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de>
rdf:type  iirds:Component .


and the violation goes away.

From the commandline (shell scripts):

Jena SHACL engine:

 shacl v -s schema.ttl -d metadata.ttl

or see the instructions on https://github.com/TopQuadrant/shacl for 
TopQuadrant TopBraid SHACL API


shaclvalidate  -shapesfile schema.ttl -datafile metadata.ttl

Andy

On 01/11/2020 02:11, alexander.fan...@web.de wrote:

Hey guys,
i created an Issue one weeg ago and you recommended me to validate my schema 
with jena shacl. I did this, but i still don't get the expected result...
What do i have to change or what mistake did i do ? (i am not allowed to change 
the schema by the way).
Maybe you have some example code or another idea how to validate my 
metadata.rdf ?

The problem:
As you can see, i have a "topic" containing the property "has-component", but my schema just allows 
(rdfs:domain and rdfs:range) a "component" with the property "has-component".
The validation report says in both ways, that everything is confirm..

Thanks for you help:)
Greetings from Germany
Alex



My schema is original an .rdf-schema, but i converted it into .ttl in order to 
use shacl-shapes. It looks like the following:

schema.ttl:

@prefix schema: <http://schema.org/> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix iirds: <http://iirds.tekom.de/iirds#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
iirds:Topic  a rdfs:Class ;
 rdfs:comment   "A topic is a unit of information covering a single 
subject."@en ;
 rdfs:label "Topic"@en , "Topic"@de ;
 rdfs:subClassOfiirds:InformationUnit ;
 iirds:description  "IRI: required"@en , "The resource of a topic is a file 
in the iiRDS package."@en .

iirds:has-component  a rdf:Property ;
 rdfs:comment   "Relates to a component that is part of another 
component."@en , "Verweist auf eine Kompoente, die Teil einer anderen Komponente 
ist."@de ;
 rdfs:domainiirds:Component ;
 rdfs:label "has component"@en , "hat Komponente"@de ;
 rdfs:range iirds:Component ;
 rdfs:subPropertyOf iirds:iirdsRelationConcept ;
 iirds:description  "Cardinality: http://iirds.tekom.de/iirds#Component 
[0..*]"@en , ""@en ;
 schema:domainIncludes  iirds:Component ;
 schema:rangeIncludes   iirds:Component .

iirds:Component  a rdfs:Class ;
 rdfs:comment   "Describes a component of the technical system that the 
documentation refers to."@en ;
 rdfs:label "Component"@en , "Komponente"@de ;
 rdfs:subClassOfiirds:ProductMetadata ;
 iirds:description  "IRI: required"@en , "Components may have relations to 
ot[...] The iirds#Component may also be used as a docking point for external component 
definitions."@en .





My metadata.rdf converted into metadata.ttl looks like the following:

metadata.ttl:

@prefix pifan: <http://customer.docufy.de/pifan#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix iirds: <http://iirds.tekom.de/iirds#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
[...]
<http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de>
 a   iirds:Topic ;
 iirds:dateOfCreation"2020-08-06T12:24:07.285+02:00"@de-de ;
 iirds:has-component 
<http://iirds.docufy.de/metadata/85e7506eb2e33f90c0a802687f559f0c> ;
 iirds:relates-to-component  
<http://iirds.docufy.de/metadata/85e7506eb2e33f90c0a802687f559f0c> ;
 iirds:relates-to-product-feature
 <http://iirds.docufy.de/metadata/b63e4b15b2dc2

SHACL validation doesn't show an error

[alexander . fandre]

Hey guys,
i created an Issue one weeg ago and you recommended me to validate my schema 
with jena shacl. I did this, but i still don't get the expected result... 
What do i have to change or what mistake did i do ? (i am not allowed to change 
the schema by the way).
Maybe you have some example code or another idea how to validate my 
metadata.rdf ?

The problem:
As you can see, i have a "topic" containing the property "has-component", but 
my schema just allows (rdfs:domain and rdfs:range) a "component" with the 
property "has-component". 
The validation report says in both ways, that everything is confirm..

Thanks for you help:)
Greetings from Germany
Alex



My schema is original an .rdf-schema, but i converted it into .ttl in order to 
use shacl-shapes. It looks like the following:

schema.ttl:

@prefix schema: <http://schema.org/> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix iirds: <http://iirds.tekom.de/iirds#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
iirds:Topic  a rdfs:Class ;
rdfs:comment   "A topic is a unit of information covering a single 
subject."@en ;
rdfs:label "Topic"@en , "Topic"@de ;
rdfs:subClassOfiirds:InformationUnit ;
iirds:description  "IRI: required"@en , "The resource of a topic is a 
file in the iiRDS package."@en .

iirds:has-component  a rdf:Property ;
rdfs:comment   "Relates to a component that is part of another 
component."@en , "Verweist auf eine Kompoente, die Teil einer anderen 
Komponente ist."@de ;
rdfs:domainiirds:Component ;
rdfs:label "has component"@en , "hat Komponente"@de ;
rdfs:range iirds:Component ;
rdfs:subPropertyOf iirds:iirdsRelationConcept ;
iirds:description  "Cardinality: 
http://iirds.tekom.de/iirds#Component [0..*]"@en , ""@en ;
schema:domainIncludes  iirds:Component ;
schema:rangeIncludes   iirds:Component .

iirds:Component  a rdfs:Class ;
rdfs:comment   "Describes a component of the technical system that 
the documentation refers to."@en ;
rdfs:label "Component"@en , "Komponente"@de ;
rdfs:subClassOfiirds:ProductMetadata ;
iirds:description  "IRI: required"@en , "Components may have relations 
to ot[...] The iirds#Component may also be used as a docking point for external 
component definitions."@en .





My metadata.rdf converted into metadata.ttl looks like the following:

metadata.ttl:

@prefix pifan: <http://customer.docufy.de/pifan#> .
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix iirds: <http://iirds.tekom.de/iirds#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
[...]
<http://iirds.docufy.de/topics/05d2c8268b68ff6444a49358ca7fe925/1/de-de>
a   iirds:Topic ;
iirds:dateOfCreation"2020-08-06T12:24:07.285+02:00"@de-de ;
iirds:has-component 
<http://iirds.docufy.de/metadata/85e7506eb2e33f90c0a802687f559f0c> ;
iirds:relates-to-component  
<http://iirds.docufy.de/metadata/85e7506eb2e33f90c0a802687f559f0c> ;
iirds:relates-to-product-feature

<http://iirds.docufy.de/metadata/b63e4b15b2dc2d83c0a8026877f6aa88> , 
<http://iirds.docufy.de/metadata/10b4c299b2ddae19c0a8026824aa7410> , 
<http://iirds.docufy.de/metadata/dbbb7334b2e2a9e5c0a8026860d20c17> ;
iirds:title "Kontaktdaten"@de-de .
[...]


My code is the following:

//try with jena shacl
Graph shapesGraph = RDFDataMgr.loadGraph("schema.ttl");
Graph dataGraph = RDFDataMgr.loadGraph("metadata.ttl"); 
Shapes shapes = Shapes.parse(shapesGraph);  
ValidationReport report = ShaclValidator.get().validate(shapes, dataGraph);
ShLib.printReport(report);
System.out.println();
RDFDataMgr.write(System.out, report.getModel(), Lang.TTL);

//try with topbraid shacl
Model dataModel = org.topbraid.jenax.util.JenaUtil.createDefaultModel();
dataModel.read("metadata.ttl");
Model shapeModel = org.topbraid.jenax.util.JenaUtil.createDefaultModel();
shapeModel.read("schema.ttl");  
Resource reportResource = ValidationUtil.validateModel(dataModel, shapeModel, 
true);
File reportFile = new File("report.ttl");

Re: SHACL-C

[Andy Seaborne]

On 21/07/2020 10:07, Holger Knublauch wrote:


On 21/07/2020 18:29, Andy Seaborne wrote:

The grammar does not have words

'order', 'group', 'description', 'name', 'defaultValue'

in the propertyParam or nodeParam rules

So you can't concat the sh namespace with the token string.


Thanks. I have mixed this up and thought I had generalized that rule. 
Should have checked :)


Another missing term is sh:defaultValue. So how do people feel about 
adding that line to the grammar? Sounds like an easy fix.


Further we could theoretically add sh:name and (less attractive) 
sh:description.


And shall we add subClassOf?


The form

>> shapeClass ex:Company rdfs:subClassOf ex:Organization {

does not cover cases I am coming across.

My ideal is all description in one file. Modularising using IMPORT for 
this is not nice. The domain is SHACLC shapes but also RDFS sub*of.


That means a general RDFS subClassOf declaration, not specific to 
implicitClass shapes. They (implicitClass shapes) are a pattern in 
SHACL, not fundamental to SHACL.


The class may not be a shape and it would apply for "class=" and throughout.

Having subClassOf and subPropertyOf in the same file as SHACLC makes for 
as single place for a "schema".


CLASS ex:Company .
CLASS ex:Company subClassOf ex:Organization .

(the DOTS are unnecessary - like PREFIX).

The shapeClass-subClassOf might be useful as a short cut.

Andy



Holger





propertyParam   :

'deactivated' | 'severity' | 'message' |
'class' | 'datatype' | 'nodeKind' |
'minExclusive' | 'minInclusive' | 'maxExclusive' | 'maxInclusive' |
'minLength' | 'maxLength' | 'pattern' | 'flags' | 'languageIn' | 
'uniqueLang' |

'equals' | 'disjoint' | 'lessThan' | 'lessThanOrEquals' |
'qualifiedValueShape' | 'qualifiedMinCount' | 'qualifiedMaxCount' | 
'qualifiedValueShapesDisjoint' |

'closed' | 'ignoredProperties' | 'hasValue' | 'in' ;

    Andy

On 20/07/2020 23:34, Holger Knublauch wrote:

Hi Andy,

not quite sure what you mean: is the spec unclear, or does it have an 
error? If yes, what would be better wording?


Thanks,
Holger


On 20/07/2020 19:03, Andy Seaborne wrote:



On 19/07/2020 23:21, Holger Knublauch wrote:

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they 
got overlooked as they fit is quite naturally into the grammar. 
Maybe the WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes 
and node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue


"concatenating the sh namespace with the string value of 
/propertyParam/"


("string value" taken to mean the string that is the token)

Today, 2020-07-20, the words aren't in the propertyParam grammar rule.

    Andy

Re: SHACL-C

[Holger Knublauch]

On 21/07/2020 18:29, Andy Seaborne wrote:

The grammar does not have words

'order', 'group', 'description', 'name', 'defaultValue'

in the propertyParam or nodeParam rules

So you can't concat the sh namespace with the token string.


Thanks. I have mixed this up and thought I had generalized that rule. 
Should have checked :)


Another missing term is sh:defaultValue. So how do people feel about 
adding that line to the grammar? Sounds like an easy fix.


Further we could theoretically add sh:name and (less attractive) 
sh:description.


And shall we add subClassOf?

Holger





propertyParam   :

'deactivated' | 'severity' | 'message' |
'class' | 'datatype' | 'nodeKind' |
'minExclusive' | 'minInclusive' | 'maxExclusive' | 'maxInclusive' |
'minLength' | 'maxLength' | 'pattern' | 'flags' | 'languageIn' | 
'uniqueLang' |

'equals' | 'disjoint' | 'lessThan' | 'lessThanOrEquals' |
'qualifiedValueShape' | 'qualifiedMinCount' | 'qualifiedMaxCount' | 
'qualifiedValueShapesDisjoint' |

'closed' | 'ignoredProperties' | 'hasValue' | 'in' ;

    Andy

On 20/07/2020 23:34, Holger Knublauch wrote:

Hi Andy,

not quite sure what you mean: is the spec unclear, or does it have an 
error? If yes, what would be better wording?


Thanks,
Holger


On 20/07/2020 19:03, Andy Seaborne wrote:



On 19/07/2020 23:21, Holger Knublauch wrote:

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they 
got overlooked as they fit is quite naturally into the grammar. 
Maybe the WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes 
and node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue


"concatenating the sh namespace with the string value of 
/propertyParam/"


("string value" taken to mean the string that is the token)

Today, 2020-07-20, the words aren't in the propertyParam grammar rule.

    Andy

Re: SHACL-C

[Andy Seaborne]

The grammar does not have words

'order', 'group', 'description', 'name', 'defaultValue'

in the propertyParam or nodeParam rules

So you can't concat the sh namespace with the token string.


propertyParam   :

'deactivated' | 'severity' | 'message' |
'class' | 'datatype' | 'nodeKind' |
'minExclusive' | 'minInclusive' | 'maxExclusive' | 'maxInclusive' |
'minLength' | 'maxLength' | 'pattern' | 'flags' | 'languageIn' | 
'uniqueLang' |

'equals' | 'disjoint' | 'lessThan' | 'lessThanOrEquals' |
'qualifiedValueShape' | 'qualifiedMinCount' | 'qualifiedMaxCount' | 
'qualifiedValueShapesDisjoint' |

'closed' | 'ignoredProperties' | 'hasValue' | 'in' ;

Andy

On 20/07/2020 23:34, Holger Knublauch wrote:

Hi Andy,

not quite sure what you mean: is the spec unclear, or does it have an 
error? If yes, what would be better wording?


Thanks,
Holger


On 20/07/2020 19:03, Andy Seaborne wrote:



On 19/07/2020 23:21, Holger Knublauch wrote:

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe 
the WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes and 
node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue


"concatenating the sh namespace with the string value of /propertyParam/"

("string value" taken to mean the string that is the token)

Today, 2020-07-20, the words aren't in the propertyParam grammar rule.

    Andy

Re: SHACL-C [was: misleading parse exception message in Shacl.]

[Andy Seaborne]

On 19/07/2020 23:21, Holger Knublauch wrote:

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe the 
WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes and 
node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue


"concatenating the sh namespace with the string value of /propertyParam/"

("string value" taken to mean the string that is the token)

Today, 2020-07-20, the words aren't in the propertyParam grammar rule.

Andy

Re: SHACL-C [was: misleading parse exception message in Shacl.]

[Holger Knublauch]

On 19/07/2020 19:53, Andy Seaborne wrote:


Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe the 
WG focus was validation and these aren't "validation".


All terms from the sh: namespace are supported at property shapes and 
node shapes, see


https://w3c.github.io/shacl/shacl-compact-syntax/#rule-propertyValue

e.g.

    ex:property xsd:string [0..1] order=0 .

should work. Theoretically this could be extended to allow other 
prefixes such as dash: there too. This would then also cover 
rdfs:subClassOf, e.g.


shapeClass ex:Company rdfs:subClassOf ex:Organization {
    ...
}

As the Compact Syntax is a living spec we could easily add this if there 
is sufficient consensus.


The larger question of course becomes at what stage the syntax is no 
longer compact. If we add more features, people could just as well use 
TTL, which has the advantage of being more regular. I have no strong 
opinion. (Likely better continued on the SHACL CG list)


Holger




dash:editor, and your own annotations:

There was a brief discussion on the SHACL CG list about allowing RDF 
in SHACL-C. I didn't see a conclusion.


It can be done, in rather ungraceful way, with IMPORTS but you have 
ask "why bother" if its splitting the shapes into compact and RDF parts.


Similarly, if there is an RDF block in a SHACL-C file: at least 
everything is in one file but having to wire two sections of the file 
by using the shape URIs is again, to me, kind of contrary to the 
compact, ease of use, aspect of SHACL-C.


It looks like it would nearly work with inline Turtle inside the 
compact shape with some parser contortions; property + the compact 
class/datatype constraint would be ambiguous, but otherwise I think it 
could be done because most things are using keywords. Another way 
would be syntax to say "here be Turtle, same subject as the 
node/property a this point".


All options that allow RDF are assuming the shape writer understands 
the compact syntax as a specialised way to write some RDF and also 
what the RDF structure looks like if they are going to add RDF into 
it. So it all may be a step too far.


What I'd like in a SHACL-C file is being able to have RDFS 
subclass/subproperty declarations.


    Andy

On 17/07/2020 17:27, Chris Tomlinson wrote:

Hi Andy,

I haven’t looked into SHACLC. We do use features such as sh:group, 
sh:order, dash:editor and so on; as well as a few annotations of our 
own that are relevant to editing and some validation controls. 
Off-hand it isn’t clear how to use SHACLC and weave these other 
features in.


The notation is nicely compact and if there’s an integration approach 
for additional features I’ll look deeper.


Thanks,
Chris

SHACL-C [was: misleading parse exception message in Shacl.]

[Andy Seaborne]

Hi Chris,

Oddly, sh:group/sh:order aren't in SHACLC - they look like they got 
overlooked as they fit is quite naturally into the grammar. Maybe the WG 
focus was validation and these aren't "validation".


dash:editor, and your own annotations:

There was a brief discussion on the SHACL CG list about allowing RDF in 
SHACL-C. I didn't see a conclusion.


It can be done, in rather ungraceful way, with IMPORTS but you have ask 
"why bother" if its splitting the shapes into compact and RDF parts.


Similarly, if there is an RDF block in a SHACL-C file: at least 
everything is in one file but having to wire two sections of the file by 
using the shape URIs is again, to me, kind of contrary to the compact, 
ease of use, aspect of SHACL-C.


It looks like it would nearly work with inline Turtle inside the compact 
shape with some parser contortions; property + the compact 
class/datatype constraint would be ambiguous, but otherwise I think it 
could be done because most things are using keywords. Another way would 
be syntax to say "here be Turtle, same subject as the node/property a 
this point".


All options that allow RDF are assuming the shape writer understands the 
compact syntax as a specialised way to write some RDF and also what the 
RDF structure looks like if they are going to add RDF into it. So it all 
may be a step too far.


What I'd like in a SHACL-C file is being able to have RDFS 
subclass/subproperty declarations.


Andy

On 17/07/2020 17:27, Chris Tomlinson wrote:

Hi Andy,

I haven’t looked into SHACLC. We do use features such as sh:group, sh:order, 
dash:editor and so on; as well as a few annotations of our own that are 
relevant to editing and some validation controls. Off-hand it isn’t clear how 
to use SHACLC and weave these other features in.

The notation is nicely compact and if there’s an integration approach for 
additional features I’ll look deeper.

Thanks,
Chris

Re: misleading parse exception message in Shacl.

[Chris Tomlinson]

Hi Andy,

I haven’t looked into SHACLC. We do use features such as sh:group, sh:order, 
dash:editor and so on; as well as a few annotations of our own that are 
relevant to editing and some validation controls. Off-hand it isn’t clear how 
to use SHACLC and weave these other features in.

The notation is nicely compact and if there’s an integration approach for 
additional features I’ll look deeper.

Thanks,
Chris


> On Jul 17, 2020, at 5:37 AM, Andy Seaborne  wrote:
> 
> Be interested to hear experiences using SHACL Compact Syntax.
> 
> It's Lang.SHACLC
> 
> SHACL-CS doesn't cover all SHACL but what it does cover is easier to read and 
> write.
> 
> 1/ What is missing from SHACL-CS from your perspective?
> 2/ Is it, in fact, actually helpful for managing SHACL at scale or not?
> 
>Andy
> 
> https://w3c.github.io/shacl/shacl-compact-syntax/
> 
> 
> On 16/07/2020 22:31, Chris Tomlinson wrote:
>> Andy,
>> That's great news! Updating to 3.16.0 is on the ToDo list. I'm moving it to 
>> the top.
>> Thanks very much,
>> Chris
>>> On Jul 16, 2020, at 16:20, Andy Seaborne  wrote:
>>> 
>>> Fixed in 3.16.0:
>>> 
>>> "shacl parse" gives:
>>> 
>>> No sh:path on a property shape: 
>>> node=<http://example/bdsContentLocationShape> sh:property 
>>> <http://example/bdsContentLocationShape-contentLocationStatement>
>>> 
>>> when there exists at least one triple with
>>> bds:ContentLocationShape-contentLocationStatement as subject
>>> 
>>> and
>>> 
>>> Missing property shape: node=<http://example/bdsContentLocationShape> 
>>> sh:property 
>>> <http://example/bdsContentLocationShape-contentLocationStatement>
>>> 
>>> if there are none:
>>> 
>>> 
>>> (and no stacktraces)
>>> 
>>> but what you show if 3.15.0.
>>> 
>>> Test RDF::
>>> 
>>> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
>>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>>> PREFIX sh:  <http://www.w3.org/ns/shacl#>
>>> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
>>> 
>>> PREFIX bds: <http://example/bds>
>>> PREFIX bdo: <http://example/bdo>
>>> 
>>> bds:ContentLocationShape
>>>  a sh:NodeShape ;
>>>  sh:property bds:ContentLocationShape-contentLocationStatement ;
>>>  sh:targetClass bdo:ContentLocation .
>>> 
>>> #bds:ContentLocationShape-contentLocationStatement rdf:type 
>>> sh:PropertyShape .
>>> 
>>> 
>>>> On 16/07/2020 21:44, Chris Tomlinson wrote:
>>>> Hi,
>>>> I’ve gotten a parse exception:
>>>> org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property 
>>>> shape: <http://purl.bdrc.io/ontology/shapes/core/ContentLocationShape>
>>>>at 
>>>> org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
>>>>at 
>>>> org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
>>>>at 
>>>> org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
>>>>at 
>>>> org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
>>>>at 
>>>> org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
>>>>at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
>>>> performing:
>>>> Shapes shapes = Shapes.parse(testGraph);
>>>> on the graph:
>>>> bds:ContentLocationShape
>>>>   a sh:NodeShape ;
>>>>   sh:property bds:ContentLocationShape-contentLocationStatement ;
>>>>   sh:targetClass bdo:ContentLocation .
>>>> In the above graph there are no triples with
>>>> bds:ContentLocationShape-contentLocationStatement
>>>> as subject so the Shapes.parse raises an exception which seems reasonable; 
>>>> however, the message should refer to the missing definition of a putative 
>>>> PropertyShape reference rather than to the NodeShape that contains the 
>>>> reference.
>>>> In the simple case above it’s trivial by a casual inspection what the 
>>>> problem is, but when there are a large number of PropertyShape refs and 
>>>> all that the message says is that the NodeShape doesn’t have an sh:path, 
>>>> its pretty opaque as to what the problem is.
>>>> Maybe there’s a way to improve the exception message?
>>>> Thanks,
>>>> Chris

Re: misleading parse exception message in Shacl.

[Andy Seaborne]

Be interested to hear experiences using SHACL Compact Syntax.

It's Lang.SHACLC

SHACL-CS doesn't cover all SHACL but what it does cover is easier to 
read and write.


1/ What is missing from SHACL-CS from your perspective?
2/ Is it, in fact, actually helpful for managing SHACL at scale or not?

Andy

https://w3c.github.io/shacl/shacl-compact-syntax/


On 16/07/2020 22:31, Chris Tomlinson wrote:

Andy,

That's great news! Updating to 3.16.0 is on the ToDo list. I'm moving it to the 
top.

Thanks very much,
Chris


On Jul 16, 2020, at 16:20, Andy Seaborne  wrote:

Fixed in 3.16.0:

"shacl parse" gives:

No sh:path on a property shape: node=<http://example/bdsContentLocationShape> 
sh:property <http://example/bdsContentLocationShape-contentLocationStatement>

when there exists at least one triple with
bds:ContentLocationShape-contentLocationStatement as subject

and

Missing property shape: node=<http://example/bdsContentLocationShape> sh:property 
<http://example/bdsContentLocationShape-contentLocationStatement>

if there are none:


(and no stacktraces)

but what you show if 3.15.0.

Test RDF::

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX sh:  <http://www.w3.org/ns/shacl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX bds: <http://example/bds>
PREFIX bdo: <http://example/bdo>

bds:ContentLocationShape
  a sh:NodeShape ;
  sh:property bds:ContentLocationShape-contentLocationStatement ;
  sh:targetClass bdo:ContentLocation .

#bds:ContentLocationShape-contentLocationStatement rdf:type sh:PropertyShape .



On 16/07/2020 21:44, Chris Tomlinson wrote:
Hi,
I’ve gotten a parse exception:
org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property shape: 
<http://purl.bdrc.io/ontology/shapes/core/ContentLocationShape>
at 
org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
performing:
Shapes shapes = Shapes.parse(testGraph);
on the graph:
bds:ContentLocationShape
   a sh:NodeShape ;
   sh:property bds:ContentLocationShape-contentLocationStatement ;
   sh:targetClass bdo:ContentLocation .
In the above graph there are no triples with
bds:ContentLocationShape-contentLocationStatement
as subject so the Shapes.parse raises an exception which seems reasonable; 
however, the message should refer to the missing definition of a putative 
PropertyShape reference rather than to the NodeShape that contains the 
reference.
In the simple case above it’s trivial by a casual inspection what the problem 
is, but when there are a large number of PropertyShape refs and all that the 
message says is that the NodeShape doesn’t have an sh:path, its pretty opaque 
as to what the problem is.
Maybe there’s a way to improve the exception message?
Thanks,
Chris

Re: misleading parse exception message in Shacl.

[Chris Tomlinson]

Andy,

That's great news! Updating to 3.16.0 is on the ToDo list. I'm moving it to the 
top.

Thanks very much,
Chris

> On Jul 16, 2020, at 16:20, Andy Seaborne  wrote:
> 
> Fixed in 3.16.0:
> 
> "shacl parse" gives:
> 
> No sh:path on a property shape: node=<http://example/bdsContentLocationShape> 
> sh:property <http://example/bdsContentLocationShape-contentLocationStatement>
> 
> when there exists at least one triple with
> bds:ContentLocationShape-contentLocationStatement as subject
> 
> and
> 
> Missing property shape: node=<http://example/bdsContentLocationShape> 
> sh:property <http://example/bdsContentLocationShape-contentLocationStatement>
> 
> if there are none:
> 
> 
> (and no stacktraces)
> 
> but what you show if 3.15.0.
> 
> Test RDF::
> 
> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
> PREFIX sh:  <http://www.w3.org/ns/shacl#>
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
> 
> PREFIX bds: <http://example/bds>
> PREFIX bdo: <http://example/bdo>
> 
> bds:ContentLocationShape
>  a sh:NodeShape ;
>  sh:property bds:ContentLocationShape-contentLocationStatement ;
>  sh:targetClass bdo:ContentLocation .
> 
> #bds:ContentLocationShape-contentLocationStatement rdf:type sh:PropertyShape .
> 
> 
>> On 16/07/2020 21:44, Chris Tomlinson wrote:
>> Hi,
>> I’ve gotten a parse exception:
>> org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property 
>> shape: <http://purl.bdrc.io/ontology/shapes/core/ContentLocationShape>
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
>>at 
>> org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
>>at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
>> performing:
>> Shapes shapes = Shapes.parse(testGraph);
>> on the graph:
>> bds:ContentLocationShape
>>   a sh:NodeShape ;
>>   sh:property bds:ContentLocationShape-contentLocationStatement ;
>>   sh:targetClass bdo:ContentLocation .
>> In the above graph there are no triples with
>> bds:ContentLocationShape-contentLocationStatement
>> as subject so the Shapes.parse raises an exception which seems reasonable; 
>> however, the message should refer to the missing definition of a putative 
>> PropertyShape reference rather than to the NodeShape that contains the 
>> reference.
>> In the simple case above it’s trivial by a casual inspection what the 
>> problem is, but when there are a large number of PropertyShape refs and all 
>> that the message says is that the NodeShape doesn’t have an sh:path, its 
>> pretty opaque as to what the problem is.
>> Maybe there’s a way to improve the exception message?
>> Thanks,
>> Chris

Re: misleading parse exception message in Shacl.

[Andy Seaborne]

Fixed in 3.16.0:

"shacl parse" gives:

No sh:path on a property shape: 
node=<http://example/bdsContentLocationShape> sh:property 
<http://example/bdsContentLocationShape-contentLocationStatement>


when there exists at least one triple with
bds:ContentLocationShape-contentLocationStatement as subject

and

Missing property shape: node=<http://example/bdsContentLocationShape> 
sh:property 
<http://example/bdsContentLocationShape-contentLocationStatement>


if there are none:


(and no stacktraces)

but what you show if 3.15.0.

Test RDF::

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
PREFIX sh:  <http://www.w3.org/ns/shacl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX bds: <http://example/bds>
PREFIX bdo: <http://example/bdo>

bds:ContentLocationShape
  a sh:NodeShape ;
  sh:property bds:ContentLocationShape-contentLocationStatement ;
  sh:targetClass bdo:ContentLocation .

#bds:ContentLocationShape-contentLocationStatement rdf:type 
sh:PropertyShape .



On 16/07/2020 21:44, Chris Tomlinson wrote:

Hi,

I’ve gotten a parse exception:

org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property shape: 
<http://purl.bdrc.io/ontology/shapes/core/ContentLocationShape>
at 
org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
performing:

Shapes shapes = Shapes.parse(testGraph);

on the graph:

bds:ContentLocationShape
   a sh:NodeShape ;
   sh:property bds:ContentLocationShape-contentLocationStatement ;
   sh:targetClass bdo:ContentLocation .
In the above graph there are no triples with

bds:ContentLocationShape-contentLocationStatement

as subject so the Shapes.parse raises an exception which seems reasonable; 
however, the message should refer to the missing definition of a putative 
PropertyShape reference rather than to the NodeShape that contains the 
reference.

In the simple case above it’s trivial by a casual inspection what the problem 
is, but when there are a large number of PropertyShape refs and all that the 
message says is that the NodeShape doesn’t have an sh:path, its pretty opaque 
as to what the problem is.

Maybe there’s a way to improve the exception message?

Thanks,
Chris

misleading parse exception message in Shacl.

[Chris Tomlinson]

Hi,

I’ve gotten a parse exception:

org.apache.jena.shacl.parser.ShaclParseException: No sh:path on a property 
shape: 
at 
org.apache.jena.shacl.parser.ShapesParser.findPropertyShapes(ShapesParser.java:285)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShape$(ShapesParser.java:214)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapeStep(ShapesParser.java:196)
at 
org.apache.jena.shacl.parser.ShapesParser.parseRootShape(ShapesParser.java:140)
at 
org.apache.jena.shacl.parser.ShapesParser.parseShapes(ShapesParser.java:84)
at org.apache.jena.shacl.Shapes.parse(Shapes.java:55)
performing:

Shapes shapes = Shapes.parse(testGraph);

on the graph:

bds:ContentLocationShape
  a sh:NodeShape ;
  sh:property bds:ContentLocationShape-contentLocationStatement ;
  sh:targetClass bdo:ContentLocation .
In the above graph there are no triples with  

bds:ContentLocationShape-contentLocationStatement 

as subject so the Shapes.parse raises an exception which seems reasonable; 
however, the message should refer to the missing definition of a putative 
PropertyShape reference rather than to the NodeShape that contains the 
reference.

In the simple case above it’s trivial by a casual inspection what the problem 
is, but when there are a large number of PropertyShape refs and all that the 
message says is that the NodeShape doesn’t have an sh:path, its pretty opaque 
as to what the problem is.

Maybe there’s a way to improve the exception message?

Thanks,
Chris

Re: one jena-shacl question - was Re: two jena-shacl questions

[Chris Tomlinson]

Hi Andy,

Thank you so much for your patience and help. I think I’ve got a handle on 
things now and will forge ahead. 

I appreciate you raising JENA-1905 
<https://issues.apache.org/jira/browse/JENA-1905>, JENA-1906 
<https://issues.apache.org/jira/browse/JENA-1906>, and JENA-1907 
<https://issues.apache.org/jira/browse/JENA-1907>. I’ll comment on the issues 
as appropriate.

Thank you again,
Chris


> On Jun 1, 2020, at 4:44 PM, Andy Seaborne  wrote:
> 
> 
> 
> On 01/06/2020 21:08, Chris Tomlinson wrote:
>> Hi Andy,
>> Not trying to be pedantic below but I’m trying to understand how to think in 
>> shacl and establish some expectations of the validation process.
> 
> If it help, the general pattern is
> 
> Target ->
>  (Node shape -> property shape->)*
>  Constraint*
> 
>>> On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:
>>> 
>>> Do we agree that this is a test case?
>>> (one file, data and shapes combined)
>>> Only command line tools needed.
>> I agree that the combined data and shapes file exhibits differences in 
>> report results, when interchanging bds:PersonShape and bds:PersonLocalShape.
>>> 
>>> @prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>> @prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
>>> @prefix sh:<http://www.w3.org/ns/shacl#> .
>>> @prefix bdo:   <http://purl.bdrc.io/ontology/core/> .
>>> @prefix bdr:   <http://purl.bdrc.io/resource/> .
>>> @prefix bds:   <http://purl.bdrc.io/ontology/shapes/core/> .
>>> 
>>> ## Data:
>>> 
>>> bdr:NM0895CB6787E8AC6E
>>> a   bdo:PersonName ;
>>> .
>>> 
>>> bdr:P707  a  bdo:Person ;
>>>bdo:personName   bdr:NM0895CB6787E8AC6E ;
>>> .
>>> 
>>> ## Shapes:
>>> 
>>> #bds:PersonShape   # 2
>>> bds:PersonLocalShape  # 1
>>>sh:property bds:PersonShape-personName ;
>>>sh:targetClass  bdo:Person ;
>>> .
>>> 
>>> bds:PersonShape-personName
>>>sh:message  "PersonName is not well-formed, wrong Class or missing 
>>> rdfs:label"@en ;
>>>sh:node bds:PersonNameShape ;
>>>sh:path bdo:personName ;
>>> .
>>> 
>>> bds:PersonNameShape  a  sh:NodeShape ;
>>>sh:property bds:PersonNameShape-personNameLabel ;
>>>sh:targetClass  bdo:PersonName ;
>>> .
>>> 
>>> bds:PersonNameShape-personNameLabel
>>>sh:message  ":PersonName must have exactly one rdfs:label"@en ;
>>>sh:minCount 1 ;
>>>sh:path rdfs:label ;
>>> .
>>> 
>>> 
>>> The differences seems to be that the hash order is different and it affects 
>>> finding targets, combined with the fact that targets are nested:
>> I see JENA-1907 <https://issues.apache.org/jira/browse/JENA-1907> raises the 
>> issue; I understand:
>>> If A is processed first as a target then the parser shapes now includes B 
>>> so processing B is skipped.
>>> Note - the effect is only in the number of times constriants are executed , 
>>> once or twice, not whether they are omitted.
>> to say that, in the current test case w/ the hash order issue, when nesting 
>> occurs owing to sh:node, then when a violation is found by (A) 
>> bds:PersonShape-personName, then the validation does not "go deeper" to 
>> consider (B) bds:PersonNameShape, by itself. W/o sh:node, in 
>> bds:PersonShape-personName, then both  bds:PersonShape-personName and 
>> bds:PersonNameShape are parsed as independent targets and  executed 
>> independently.
>>> bds:PersonLocalShape (target)
>>> -> bds:PersonLocalShape
>>>   -> bds:PersonNameShape (target)
>>> -> bds:PersonNameShape-personNameLabel
>> I think the second line above is supposed to be
>> -> bds:PersonShape-personName
>>> Both targets match bdr:P707, one by class, one by property.
>> I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, 
>> meaning, to me, that the constraints expressed in that shape need to be 
>> evaluated w/ P707 being the subject (== focus node). I take this to be “by 
>> class”.
>> I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
>> think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
>> sh:targetClass

Re: one jena-shacl question - was Re: two jena-shacl questions

[Andy Seaborne]

On 01/06/2020 21:08, Chris Tomlinson wrote:

Hi Andy,

Not trying to be pedantic below but I’m trying to understand how to think in 
shacl and establish some expectations of the validation process.


If it help, the general pattern is

Target ->
  (Node shape -> property shape->)*
  Constraint*


On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:

Do we agree that this is a test case?
(one file, data and shapes combined)
Only command line tools needed.


I agree that the combined data and shapes file exhibits differences in report 
results, when interchanging bds:PersonShape and bds:PersonLocalShape.




@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh:<http://www.w3.org/ns/shacl#> .
@prefix bdo:   <http://purl.bdrc.io/ontology/core/> .
@prefix bdr:   <http://purl.bdrc.io/resource/> .
@prefix bds:   <http://purl.bdrc.io/ontology/shapes/core/> .

## Data:

bdr:NM0895CB6787E8AC6E
 a   bdo:PersonName ;
.

bdr:P707  a  bdo:Person ;
bdo:personName   bdr:NM0895CB6787E8AC6E ;
.

## Shapes:

#bds:PersonShape   # 2
bds:PersonLocalShape  # 1
sh:property bds:PersonShape-personName ;
sh:targetClass  bdo:Person ;
.

bds:PersonShape-personName
sh:message  "PersonName is not well-formed, wrong Class or missing 
rdfs:label"@en ;
sh:node bds:PersonNameShape ;
sh:path bdo:personName ;
.

bds:PersonNameShape  a  sh:NodeShape ;
sh:property bds:PersonNameShape-personNameLabel ;
sh:targetClass  bdo:PersonName ;
.

bds:PersonNameShape-personNameLabel
sh:message  ":PersonName must have exactly one rdfs:label"@en ;
sh:minCount 1 ;
sh:path rdfs:label ;
.


The differences seems to be that the hash order is different and it affects 
finding targets, combined with the fact that targets are nested:


I see JENA-1907 <https://issues.apache.org/jira/browse/JENA-1907> raises the 
issue; I understand:


If A is processed first as a target then the parser shapes now includes B so 
processing B is skipped.
Note - the effect is only in the number of times constriants are executed , 
once or twice, not whether they are omitted.



to say that, in the current test case w/ the hash order issue, when nesting occurs owing 
to sh:node, then when a violation is found by (A) bds:PersonShape-personName, then the 
validation does not "go deeper" to consider (B) bds:PersonNameShape, by itself. 
W/o sh:node, in bds:PersonShape-personName, then both  bds:PersonShape-personName and 
bds:PersonNameShape are parsed as independent targets and  executed independently.



bds:PersonLocalShape (target)
-> bds:PersonLocalShape
   -> bds:PersonNameShape (target)
 -> bds:PersonNameShape-personNameLabel


I think the second line above is supposed to be

 -> bds:PersonShape-personName



Both targets match bdr:P707, one by class, one by property.


I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, meaning, 
to me, that the constraints expressed in that shape need to be evaluated w/ 
P707 being the subject (== focus node). I take this to be “by class”.

I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
sh:targetClass bdo:PersonName.


1/
bds:PersonShape
  sh:targetClass  bdo:Person
  -> bdr:P707

and is has
  sh:property bds:PersonShape-personName ;
->
 sh:node bds:PersonNameShape ;
->
 sh:property bds:PersonNameShape-personNameLabel ;

2/
bds:PersonNameShape  a  sh:NodeShape ;
sh:property bds:PersonNameShape-personNameLabel ;
sh:targetClass  bdo:PersonName ; <-- which is part of bdr:P707
->  bdr:NM0895CB6787E8AC6E ;

so two ways to get to bds:PersonNameShape-personNameLabel from target 
declarations.


(try "shacl validate -v")

In case1: you can see the paths:
2 targets.
each with one focus node
leading to the same property shape /PersonNameShape-personNameLabel
which has a constraint.

(I checked the spec and it is onlt says to execute once if the same 
focus node comes up multiple times for the same target shape but here 
there are two different target shapes. TQ shacl agrees.)


F: Focus node
S: Node Shape
P: Property Shape.
C: Constraint

NodeShape[http://purl.bdrc.io/ontology/shapes/core/PersonLocalShape]
N: FocusNodes(1): [http://purl.bdrc.io/resource/P707]
  F: http://purl.bdrc.io/resource/P707
  S: NodeShape[http://purl.bdrc.io/ontology/shapes/core/PersonLocalShape]
  P: 
PropertyShape[http://purl.bdrc.io/ontology/shapes/core/PersonShape-personName 
-> <http://purl.bdrc.io/ontology/core/personName>]

  C: http://purl.bdrc.io/resource/P707 :: Node
  S: NodeShape[http://purl.bdrc.io/ontology/shapes/core/Perso

Re: one jena-shacl question - was Re: two jena-shacl questions

[Chris Tomlinson]

Hi Andy,

Not trying to be pedantic below but I’m trying to understand how to think in 
shacl and establish some expectations of the validation process.

> On May 31, 2020, at 9:40 AM, Andy Seaborne  wrote:
> 
> Do we agree that this is a test case?
> (one file, data and shapes combined)
> Only command line tools needed.

I agree that the combined data and shapes file exhibits differences in report 
results, when interchanging bds:PersonShape and bds:PersonLocalShape.


> 
> @prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix sh:<http://www.w3.org/ns/shacl#> .
> @prefix bdo:   <http://purl.bdrc.io/ontology/core/> .
> @prefix bdr:   <http://purl.bdrc.io/resource/> .
> @prefix bds:   <http://purl.bdrc.io/ontology/shapes/core/> .
> 
> ## Data:
> 
> bdr:NM0895CB6787E8AC6E
> a   bdo:PersonName ;
> .
> 
> bdr:P707  a  bdo:Person ;
>bdo:personName   bdr:NM0895CB6787E8AC6E ;
> .
> 
> ## Shapes:
> 
> #bds:PersonShape   # 2
> bds:PersonLocalShape  # 1
>sh:property bds:PersonShape-personName ;
>sh:targetClass  bdo:Person ;
> .
> 
> bds:PersonShape-personName
>sh:message  "PersonName is not well-formed, wrong Class or missing 
> rdfs:label"@en ;
>sh:node bds:PersonNameShape ;
>sh:path bdo:personName ;
> .
> 
> bds:PersonNameShape  a  sh:NodeShape ;
>sh:property bds:PersonNameShape-personNameLabel ;
>sh:targetClass  bdo:PersonName ;
> .
> 
> bds:PersonNameShape-personNameLabel
>sh:message  ":PersonName must have exactly one rdfs:label"@en ;
>sh:minCount 1 ;
>sh:path rdfs:label ;
> .
> 
> 
> The differences seems to be that the hash order is different and it affects 
> finding targets, combined with the fact that targets are nested:

I see JENA-1907 <https://issues.apache.org/jira/browse/JENA-1907> raises the 
issue; I understand:

> If A is processed first as a target then the parser shapes now includes B so 
> processing B is skipped.
> Note - the effect is only in the number of times constriants are executed , 
> once or twice, not whether they are omitted.


to say that, in the current test case w/ the hash order issue, when nesting 
occurs owing to sh:node, then when a violation is found by (A) 
bds:PersonShape-personName, then the validation does not "go deeper" to 
consider (B) bds:PersonNameShape, by itself. W/o sh:node, in 
bds:PersonShape-personName, then both  bds:PersonShape-personName and 
bds:PersonNameShape are parsed as independent targets and  executed 
independently.


> bds:PersonLocalShape (target)
> -> bds:PersonLocalShape
>   -> bds:PersonNameShape (target)
> -> bds:PersonNameShape-personNameLabel

I think the second line above is supposed to be 

-> bds:PersonShape-personName


> Both targets match bdr:P707, one by class, one by property.

I understand the NodeShape, bds:PersonLocalShape, matching bdr:P707, meaning, 
to me, that the constraints expressed in that shape need to be evaluated w/ 
P707 being the subject (== focus node). I take this to be “by class”.

I do not understand how NodeShape, bds:PersonNameShape, matches bdr:P707. I 
think bds:PersonNameShape matches bdr:NM0895CB6787E8AC6E because of 
sh:targetClass bdo:PersonName.


> It should execute twice -

I’m not following the referent “it” (but see below, I think I may).

My understanding of (target) bds:PersonLocalShape is that for resources of 
targetClass, bdo:Person, check that the constraints expressed in 
bds:PersonShape-personName conform for all objects of bdo:personName where the 
subject of that property path is bdr:P707 (in this case); and

(target) bds:PersonNameShape says that for resources of targetClass, 
bdo:PersonName, check that the constraints in PersonShape-personNameLabel 
conform where the resource is a bdo:PersonName, in this case 
bdr:NM0895CB6787E8AC6E.

I don’t see what’s supposed to execute twice.


> but did you mean to do this in the first place? Note while it is a minCount 
> failure, because of going through the sh;node, the message is the "wrong 
> Class" one because executing via bds:PersonShape-personName makes that the 
> message.

I meant to express that for a bdo:Person there must be at least 1 
bdo:personName - via bds:PersonShape-personName (the test case omits 
sh:minCount 1 in bds:PersonShape-personName);

and that a conforming bdoPersonName must have exactly 1 rdfs:label (the test 
case omits sh:maxCount 1 in bds:PersonShape-personNameLabel).

I used "sh:node bds:PersonNameShape" in the declaration for 
bds:PersonShape-per

Re: one jena-shacl question - was Re: two jena-shacl questions

[Andy Seaborne]

Do we agree that this is a test case?
(one file, data and shapes combined)
Only command line tools needed.


@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh:<http://www.w3.org/ns/shacl#> .
@prefix bdo:   <http://purl.bdrc.io/ontology/core/> .
@prefix bdr:   <http://purl.bdrc.io/resource/> .
@prefix bds:   <http://purl.bdrc.io/ontology/shapes/core/> .

## Data:

bdr:NM0895CB6787E8AC6E
 a   bdo:PersonName ;
.

bdr:P707  a  bdo:Person ;
bdo:personName   bdr:NM0895CB6787E8AC6E ;
.

## Shapes:

#bds:PersonShape   # 2
bds:PersonLocalShape  # 1
sh:property bds:PersonShape-personName ;
sh:targetClass  bdo:Person ;
.

bds:PersonShape-personName
sh:message  "PersonName is not well-formed, wrong Class or 
missing rdfs:label"@en ;

sh:node bds:PersonNameShape ;
sh:path bdo:personName ;
.

bds:PersonNameShape  a  sh:NodeShape ;
sh:property bds:PersonNameShape-personNameLabel ;
sh:targetClass  bdo:PersonName ;
.

bds:PersonNameShape-personNameLabel
sh:message  ":PersonName must have exactly one rdfs:label"@en ;
sh:minCount 1 ;
sh:path rdfs:label ;
.


The differences seems to be that the hash order is different and it 
affects finding targets, combined with the fact that targets are nested:


bds:PersonLocalShape (target)
 -> bds:PersonLocalShape
   -> bds:PersonNameShape (target)
 -> bds:PersonNameShape-personNameLabel

Both targets match bdr:P707, one by class, one by property.

It should execute twice -

 but did you mean to do this in the first place? Note while it is a 
minCount failure, because of going through the sh;node, the message is 
the "wrong Class" one because executing via bds:PersonShape-personName 
makes that the message.


You can see the differences with "shacl print".

Andy


On 29/05/2020 20:39, Chris Tomlinson wrote:

Hi Andy,

Thank you for the reply. Focussing on just the first question. I have prepared 
small self-contained tests of jena-shacl from 3.14.0 (JS) and TopQuadrant Shacl 
1.3.2 (TQ).

The apps differ only according to differences imposed by the JS and TQ APIs:

 ShaclName_validateGraphJS.java <https://pastebin.com/5382xZeL>

 ShaclName_validateGraphTQ.java <https://pastebin.com/3BxmyhqA>


The DATA_P707.ttl <https://pastebin.com/ugCZfABj> contains the three needed 
triples from the ontology and the bare minimum from the example P707 with two 
different errors in two of the PersonName instances.

The ShapeName_01.ttl <https://pastebin.com/jDqzvPTe> contains the shape 
definitions and all tests are performed only by changing the name on line 9.

The ShaclName_validateGraphJS-results-PersonShape.txt 
<https://pastebin.com/seEfWKNa> shows the results when the JS app is run with 
the name bds:PersonShape and gives the expected results.

The ShaclName_validateGraphJS-results-PersonLocalShape… 
<https://pastebin.com/q1SWMC4H> shows the results when the JS app is run with 
the name bds:PersonLocalShape and gives unexpected results. Namely, the expected 
violation regarding the PersonName which uses skos:prefLabel instead of rdfs:label is 
erroneously reported as conforming.

The ShaclName_validateGraphJS-results-varying.txt 
<https://pastebin.com/CNwnE5kg> shows results for names ranging from “P”, “Pe”, 
“Per” thru “PersonLocal”, “PersonShape” upto “PersonLocalShape”, “PersonLocalShaper”, 
and finally “PersonLocalShapers” for the JS app. In the table a “0” means the 
unexpected result and a “1” means the expected result - 7 names produce unexpected 
results and 20 names produce expected results.

The ShaclName_validateGraphTQ-results.txt <https://pastebin.com/BQnStjVq> shows the 
results when the TQ app is run for any spelling of the name on line 9 of ShapeName_01.ttl 
<https://pastebin.com/jDqzvPTe>. The results are the expected results as with some 
spellings of the name in the JS case. TQ shows no variation owing to the name on line 9 as 
is expected.

(Note: The TQ engine needed to be re-initialized for each use otherwise it 
accumulated results. This is why there is an init of the ShaclSimpleValidator 
at each use in the JS app even though it is not needed. I just wanted to 
produce as much as possible an apples-to-apples comparison of JS and TQ.)

(Note: The TQ report does not include sh:conforms true ; in the results, just: 
[ a   sh:ValidationReport ] . I don’t know if this conforms to the SHACL 
spec but that’s another matter.)

The results from the command line tests show the same as the above.

Running  with line 9 of  ShapeName_01.ttl <https://pastebin.com/jDqzvPTe> set 
to bds:PersonLocalShape:

 shacl v -s ShapeName_01.ttl -d DATA_P707

one jena-shacl question - was Re: two jena-shacl questions

[Chris Tomlinson]

Hi Andy,

Thank you for the reply. Focussing on just the first question. I have prepared 
small self-contained tests of jena-shacl from 3.14.0 (JS) and TopQuadrant Shacl 
1.3.2 (TQ).

The apps differ only according to differences imposed by the JS and TQ APIs:

ShaclName_validateGraphJS.java <https://pastebin.com/5382xZeL>

ShaclName_validateGraphTQ.java <https://pastebin.com/3BxmyhqA>


The DATA_P707.ttl <https://pastebin.com/ugCZfABj> contains the three needed 
triples from the ontology and the bare minimum from the example P707 with two 
different errors in two of the PersonName instances.

The ShapeName_01.ttl <https://pastebin.com/jDqzvPTe> contains the shape 
definitions and all tests are performed only by changing the name on line 9.

The ShaclName_validateGraphJS-results-PersonShape.txt 
<https://pastebin.com/seEfWKNa> shows the results when the JS app is run with 
the name bds:PersonShape and gives the expected results.

The ShaclName_validateGraphJS-results-PersonLocalShape… 
<https://pastebin.com/q1SWMC4H> shows the results when the JS app is run with 
the name bds:PersonLocalShape and gives unexpected results. Namely, the 
expected violation regarding the PersonName which uses skos:prefLabel instead 
of rdfs:label is erroneously reported as conforming.

The ShaclName_validateGraphJS-results-varying.txt 
<https://pastebin.com/CNwnE5kg> shows results for names ranging from “P”, “Pe”, 
“Per” thru “PersonLocal”, “PersonShape” upto “PersonLocalShape”, 
“PersonLocalShaper”, and finally “PersonLocalShapers” for the JS app. In the 
table a “0” means the unexpected result and a “1” means the expected result - 7 
names produce unexpected results and 20 names produce expected results.

The ShaclName_validateGraphTQ-results.txt <https://pastebin.com/BQnStjVq> shows 
the results when the TQ app is run for any spelling of the name on line 9 of 
ShapeName_01.ttl <https://pastebin.com/jDqzvPTe>. The results are the expected 
results as with some spellings of the name in the JS case. TQ shows no 
variation owing to the name on line 9 as is expected. 

(Note: The TQ engine needed to be re-initialized for each use otherwise it 
accumulated results. This is why there is an init of the ShaclSimpleValidator 
at each use in the JS app even though it is not needed. I just wanted to 
produce as much as possible an apples-to-apples comparison of JS and TQ.)

(Note: The TQ report does not include sh:conforms true ; in the results, just: 
[ a   sh:ValidationReport ] . I don’t know if this conforms to the SHACL 
spec but that’s another matter.)

The results from the command line tests show the same as the above.

Running  with line 9 of  ShapeName_01.ttl <https://pastebin.com/jDqzvPTe> set 
to bds:PersonLocalShape:

shacl v -s ShapeName_01.ttl -d DATA_P707.ttl > 
PersonLocalShape_JS_Results.ttl <https://pastebin.com/M9s859Kc>

produces the unexpected results, namely there is no detail regarding the 
missing rdfs:label on bdr:NM0895CB6787E8AC6E.

However, running with line 9 of  ShapeName_01.ttl 
<https://pastebin.com/jDqzvPTe> set to bds:PersonShape:

shacl v -s ShapeName_01.ttl -d DATA_P707.ttl > PersonShape_JS_Results.ttl 
<https://pastebin.com/DhBNucpX>

produces the expected results, in that the detail regarding the missing 
rdfs:label on bdr:NM0895CB6787E8AC6E is present among the results.

I did not set up the TQ command line but I think the above TQ results make this 
testing unnecessary.

I think these tests show that there is an unexpected dependence on a shape name 
in the JS library and not in the TQ library. I think this is an error and I can 
open a JIRA issue if appropriate. 

A consideration I have is that we want to be able to use the fuseki shacl 
endpoint for some processing and hence need to understand the expected behavior 
of the JS library which is integrated.

Thank you again for your help
Chris





> On May 29, 2020, at 6:26 AM, Andy Seaborne  wrote:
> 
>> Question 1: regarding the name  bds:PersonShape at line 9 of 
>> ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>. With that name the results 
>> of running ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB> are 
>> as expected, see ShapeName-results-PersonShape.txt 
>> <https://pastebin.com/Hbk4dj04>.
>> There are two errors in P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU> 
>> regarding bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are 
>> reported in the ShapeName-results-PersonShape.txt 
>> <https://pastebin.com/Hbk4dj04> file.
>> However, if the name at line 9 of ShapeName_01.ttl 
>> <https://pastebin.com/spJJAsJ3> is changed to: bds:PersonLocalShape or 
>> bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E reports, (see 
>> ShapeName-results-PersonLocalShape

Re: two jena-shacl questions

[Andy Seaborne]

On 28/05/2020 20:47, Chris Tomlinson wrote:

Hi,

I have a two questions regarding behavior I’m seeing w/ jena-shacl in 3.14.0.

The data file is P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU>, the shape graph is at 
ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>, and the test code is 
ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB>.



Can we focus on one question please?

This is a complex setup and I'm not sure I have reproduced it correctly. 
With the ontology added, it isn't small.




Question 1: regarding the name  bds:PersonShape at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3>. With that name the results of running 
ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB> are as expected, see 
ShapeName-results-PersonShape.txt <https://pastebin.com/Hbk4dj04>.

There are two errors in P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU> regarding 
bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are reported in the 
ShapeName-results-PersonShape.txt <https://pastebin.com/Hbk4dj04> file.

However, if the name at line 9 of ShapeName_01.ttl <https://pastebin.com/spJJAsJ3> is 
changed to: bds:PersonLocalShape or bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E 
reports, (see ShapeName-results-PersonLocalShape.txt <https://pastebin.com/f4F9h1E2>):

 [ a sh:ValidationReport ;
   sh:conforms true ] .

instead of:

[ ash:ValidationReport ;
   sh:conforms  false ;
   sh:result[ a sh:ValidationResult ;
  sh:focusNode  bdr:NM0895CB6787E8AC6E ;
  sh:resultMessage  ":PersonName must have exactly one 
rdfs:label"@en ;
  sh:resultPath rdfs:label ;
  sh:resultSeverity sh:Violation ;
  sh:sourceConstraintComponent  sh:MinCountConstraintComponent ;
  sh:sourceShape
bds:PersonNameShape-personNameLabel
]
] .

which is the result with bds:PersonShape at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3>. In fact changing the name to bds:FrogTarts 
also produces the expected results.

Summary: If the shape name at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3> is either bds:PersonShape or bds:FrogTarts then 
the results are as expected; while if the shape name is either bds:PersonLocalShape 
or bds:Frogs then one of the detail results disappears and is replaced by  
sh:conforms true.

Why this dependence on the shape name? The shape name isn’t referred to elsewhere in 
ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>.



A way to check is run both Jena Shacl and TQ Shacl and see if they get 
the same violations


I ran the shapes and data in both and get 32 violations (with no 
ontology added)


and then running with the datafile as P707+ontology.  Now 5 results each.

shacl v -s ShapeName_01.ttl -d P707_nameErrs02.ttl > V1.ttl

tb-shacl -shapesfile ShapeName_01.ttl -datafile P707_nameErrs02.ttl

The name of the shape does not seem to make a difference when run like this.

Have you tries with targetNode to select the node to validate? With a 
subset of thee shapes? That would make discussing it much easier as 
would a self-contained data (the ontology isn't particularly small).


Do you have an example which has one target shape and shows differences?


This:

bds:PersonShape-personName
a   sh:PropertyShape ;
sh:classbdo:PersonName ;
sh:message  "PersonName is not well-formed, wrong Class or 
missing rdfs:label"@en ;

sh:minCount 1 ;
sh:node bds:PersonNameShape ;
sh:nodeKind sh:IRI ;
sh:path bdo:personName ;
.

(and others) could be split up into separate shapes, one per constraint 
(this has node kind, node shape, and minCount) which might make the 
report clearer


bds:PersonNameShape  also has a target - it can get called via two 
different routes.


It's quite complicated to track what's going on.





Question 2: With the same files as illustration, I’m wanting to understand how 
deep the:

 sv.validate(shapes, dataGraph, rez.asNode());

goes? What I mean is that simply calling:

 Model topReport = process(shapes, dataGraph, rez);


Since passing 'rez' is like choosing one node out of the target set, it 
is possible to write with targetNode - does this behave the same?




at line 74 of ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB> 
produces just the result:



I get three separate reports all in one model, with 0, 1 and 2 violations.


[ ash:ValidationReport ;
   sh:conforms  false ;
   sh:result[ a sh:ValidationResult ;
  sh:focusNode  bdr:P707 ;
  sh:resultMessage   

two jena-shacl questions

[Chris Tomlinson]

Hi,

I have a two questions regarding behavior I’m seeing w/ jena-shacl in 3.14.0.

The data file is P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU>, the shape 
graph is at ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>, and the test code 
is ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB>.


Question 1: regarding the name  bds:PersonShape at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3>. With that name the results of running 
ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB> are as expected, 
see ShapeName-results-PersonShape.txt <https://pastebin.com/Hbk4dj04>. 

There are two errors in P707_nameErrs02.ttl <https://pastebin.com/8wZeMiEU> 
regarding bdr:NMC2A097019ABA499F and bdr:NM0895CB6787E8AC6E which are reported 
in the ShapeName-results-PersonShape.txt <https://pastebin.com/Hbk4dj04> file.

However, if the name at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3> is changed to: bds:PersonLocalShape or 
bds:Frogs; then detail for bdr:NM0895CB6787E8AC6E reports, (see 
ShapeName-results-PersonLocalShape.txt <https://pastebin.com/f4F9h1E2>):

[ a sh:ValidationReport ; 
  sh:conforms true ] .

instead of:

[ ash:ValidationReport ;
  sh:conforms  false ;
  sh:result[ a sh:ValidationResult ;
 sh:focusNode  bdr:NM0895CB6787E8AC6E ;
 sh:resultMessage  ":PersonName must have exactly 
one rdfs:label"@en ;
 sh:resultPath rdfs:label ;
 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent  sh:MinCountConstraintComponent ;
 sh:sourceShape
bds:PersonNameShape-personNameLabel
   ]
] .

which is the result with bds:PersonShape at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3>. In fact changing the name to bds:FrogTarts 
also produces the expected results.

Summary: If the shape name at line 9 of ShapeName_01.ttl 
<https://pastebin.com/spJJAsJ3> is either bds:PersonShape or bds:FrogTarts then 
the results are as expected; while if the shape name is either 
bds:PersonLocalShape or bds:Frogs then one of the detail results disappears and 
is replaced by  sh:conforms true.

Why this dependence on the shape name? The shape name isn’t referred to 
elsewhere in ShapeName_01.ttl <https://pastebin.com/spJJAsJ3>.



Question 2: With the same files as illustration, I’m wanting to understand how 
deep the:

sv.validate(shapes, dataGraph, rez.asNode());

goes? What I mean is that simply calling:

Model topReport = process(shapes, dataGraph, rez);

at line 74 of ShaclName_validateGraph.java <https://pastebin.com/qvUy2XeB> 
produces just the result:

[ ash:ValidationReport ;
  sh:conforms  false ;
  sh:result[ a sh:ValidationResult ;
 sh:focusNode  bdr:P707 ;
 sh:resultMessage  "PersonName is not well-formed, 
wrong Class or missing rdfs:label"@en ;
 sh:resultPath bdo:personName ;
 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent  sh:NodeConstraintComponent ;
 sh:sourceShapebds:PersonShape-personName ;
 sh:value  bdr:NM0895CB6787E8AC6E
   ] ;
  sh:result[ a sh:ValidationResult ;
 sh:focusNode  bdr:P707 ;
 sh:resultMessage  "PersonName is not well-formed, 
wrong Class or missing rdfs:label"@en ;
 sh:resultPath bdo:personName ;
 sh:resultSeverity sh:Violation ;
 sh:sourceConstraintComponent  sh:ClassConstraintComponent ;
 sh:sourceShapebds:PersonShape-personName ;
 sh:value  bdr:NMC2A097019ABA499F
   ]
] .

without going deeper to produce the more detailed results for each of the 
PersonNames in error.

Is this a result of validate node semantics?

As can be seen the detailed results are produced by using validate node on the 
sh:value objects in the above two results. Is this the appropriate way of 
extracting more useful detail than the generic results reported from the 
violations reported by the “top-level” call to validate node?


I hope the questions and files are reasonably clear.

Thanks for help with these two questions,
Chris

Re: SHACL validation of updates with Fuseki

[Benjamin Geer]

Hi Andy,

Would it work if the same SHACL rules applied to all graphs?
>

That would be fine for us.


>
> * the validation is only on the triple added (e.g. sh:datatype) - and
> does not need access to the database so it can be done in parallel
> outside the transaction.
>
> * the validation needs local changes (e.g. minCount) to the entity
> (subject and all triples with that subject) - that can be used to reduce
> the number of validations done. If a entity isn't touched, no validation
> necessary.
>
> * global - needs access to the whole database. Not much can be done
> except execute inline at the end of the transaction.
>

Ideally we'd want some of each, but we'll be glad to take whatever ends up
having acceptable performance in our use case. Any validation would be
better than no validation.

Ben

Re: SHACL validation of updates with Fuseki

[Chris Tomlinson]

Hi Andy,

Our jena-shacl use case in fuseki involves a limited set of graph types each 
with its own set of shapes, most of which do not apply to other graph types, 
although some apply across all graphs like requiring at least one 
skos:prefLabel from among a list of languages.

Each changed/new graph needs to be validated in the context of a comparatively 
small subset of all of the named graphs: the ontology graph, and graphs 
containing resources referenced from the subject graph. Pretty much your case:

>> * the validation needs local changes (e.g. minCount) to the entity (subject 
>> and all triples with that subject) - that can be used to reduce the number 
>> of validations done. If a entity isn't touched, no validation necessary.


We’re currently using ont-policy.rdf and imports to group shapes ontologies 
into graphs and provide an include facility. We have code that interrogates a 
custom element in the OntologySpec that is used to PUT a named shape graph to 
fuseki. So I’m not sure about the proposed features 
https://afs.github.io/shacl-datasets.html 
<https://afs.github.io/shacl-datasets.html>.

I haven’t looked at shacl-c.

Thank you,
Chris



> On May 20, 2020, at 2:50 PM, Andy Seaborne  wrote:
> 
> Hi Ben,
> 
> Not currently I'm afaird but certainly something to provide.
> 
> Question to everyone:
> 
> Would it work if the same SHACL rules applied to all graphs? Or are there 
> cases where different graph have different sets of shapes?
> 
> It is possible to prune the validation work significantly because many 
> constraints don't need the whole dataset so having many shapes, most of which 
> don't apply to a graph should not have too much impact.
> 
> What is more the validation is focused on changes:
> 
> * the validation is only on the triple added (e.g. sh:datatype) - and does 
> not need access to the database so it can be done in parallel outside the 
> transaction.
> 
> * the validation needs local changes (e.g. minCount) to the entity (subject 
> and all triples with that subject) - that can be used to reduce the number of 
> validations done. If a entity isn't touched, no validation necessary.
> 
> * global - needs access to the whole database. Not much can be done except 
> execute inline at the end of the transaction.
> 
> (from
> https://lists.apache.org/thread.html/rc4df58fba718a0cbfe9305cee9ab24c6c25bc162c468f9336f059b85%40%3Cusers.jena.apache.org%3E
> )
> 
> or does it need something more compliucated, may be even targeting graphs?
> 
>   https://afs.github.io/shacl-datasets.html
> 
> Another thing to add is SHACL-C (Compact syntax), at least for reading, for 
> manageability in the case of many relatively simple constraints.
> 
>Andy
> 
> 
> 
> On 20/05/2020 13:08, Benjamin Geer wrote:
>> Hello,
>> Is it possible to configure Fuseki to use 
>> org.apache.jena.shacl.GraphValidation, so that each update is accepted only 
>> if, after the changes, the union of all named graphs in the dataset would be 
>> valid according to SHACL shapes that are configured on the server? In other 
>> words, to do what the Shacl02_validateTransaction example does, but for 
>> updates submitted to Fuseki?
>> Ben
>> ---
>> Data and Service Center for the Humanities (DaSCH)
>> University of Basel, Switzerland
>> https://dasch.swiss <https://dasch.swiss/>

Re: SHACL validation of updates with Fuseki

[Andy Seaborne]

Hi Ben,

Not currently I'm afaird but certainly something to provide.

Question to everyone:

Would it work if the same SHACL rules applied to all graphs? Or are 
there cases where different graph have different sets of shapes?


It is possible to prune the validation work significantly because many 
constraints don't need the whole dataset so having many shapes, most of 
which don't apply to a graph should not have too much impact.


What is more the validation is focused on changes:

* the validation is only on the triple added (e.g. sh:datatype) - and 
does not need access to the database so it can be done in parallel 
outside the transaction.


* the validation needs local changes (e.g. minCount) to the entity 
(subject and all triples with that subject) - that can be used to reduce 
the number of validations done. If a entity isn't touched, no validation 
necessary.


* global - needs access to the whole database. Not much can be done 
except execute inline at the end of the transaction.


(from
https://lists.apache.org/thread.html/rc4df58fba718a0cbfe9305cee9ab24c6c25bc162c468f9336f059b85%40%3Cusers.jena.apache.org%3E
)

or does it need something more compliucated, may be even targeting graphs?

   https://afs.github.io/shacl-datasets.html

Another thing to add is SHACL-C (Compact syntax), at least for reading, 
for manageability in the case of many relatively simple constraints.


Andy



On 20/05/2020 13:08, Benjamin Geer wrote:

Hello,

Is it possible to configure Fuseki to use 
org.apache.jena.shacl.GraphValidation, so that each update is accepted only if, 
after the changes, the union of all named graphs in the dataset would be valid 
according to SHACL shapes that are configured on the server? In other words, to 
do what the Shacl02_validateTransaction example does, but for updates submitted 
to Fuseki?

Ben

---
Data and Service Center for the Humanities (DaSCH)
University of Basel, Switzerland
https://dasch.swiss <https://dasch.swiss/>

SHACL validation of updates with Fuseki

[Benjamin Geer]

Hello,

Is it possible to configure Fuseki to use 
org.apache.jena.shacl.GraphValidation, so that each update is accepted only if, 
after the changes, the union of all named graphs in the dataset would be valid 
according to SHACL shapes that are configured on the server? In other words, to 
do what the Shacl02_validateTransaction example does, but for updates submitted 
to Fuseki?

Ben

---
Data and Service Center for the Humanities (DaSCH)
University of Basel, Switzerland
https://dasch.swiss <https://dasch.swiss/>

Re: SHACL Endpoint questions

[Andy Seaborne]

Just come across this:

https://www.w3.org/TR/2016/WD-shacl-20160814/#filterShape

that didn't make the final SHACL spec.

(can be used on targets and on individual sh:property's).

Andy

On 19/05/2020 19:08, Andy Seaborne wrote:



On 19/05/2020 18:44, Chris Tomlinson wrote:

Hi Andy,

Thanks for the very helpful feedback.

1) I did not understand the proper use of sh:inversePath. I thought it 
was to verify that the target of the target/value of the sh:path 
property had a property equal to the value of sh:inversePath. I see 
that is just not correct.


2) I’ve found an effective solution to the problem of limiting 
validation to just the triples that should be in the graph of a 
resource such as bdr:P707 by creating a new shapes module that uses  [ 
] sh:deactivated true   on any propertyShapes that leave the graph in 
question.


I’m getting closer to being able to formulate a plausible extension to 
the shacl endpoint.


looking forward to it.

Having ?graph=..&node=.. makes sense.



Thank you again for your help in the midst of all the 3.15.0 work,
Chris



On May 16, 2020, at 5:45 AM, Andy Seaborne  wrote:



On 15/05/2020 00:57, Chris Tomlinson wrote:

Hello Andy,
I have standalone code using validator.validate(Shapes, Graph, Node) 
where the graph is a merge of the target graph, e.g., P707, and the 
ontology graph. This works fine to validate examples like P707 
generating sh:results just for references to P705 which is not 
otherwise included in the merged graph, which is what I expect.
If the code was running in Fuseki and the graph is the dataset graph 
(equiv union graph I think) then I would like to know how far out 
from the node the validation process will reach.


That depends on the target (or, here, implicit class target) and the 
shape itself.


digression

... something that I've experimented with - analysing the shapes to 
determine execution strategy. There are some useful cases:


* the validation is only on the triple added (e.g. sh:datatype) - and 
does not need access to the database so it can be done in parallel 
outside the transaction.
* the validation needs local changes (e.g. minCount) to the entity 
(subject and all triples with that subject) - that can be used to 
reduce the number of validations done. If a entity isn't touched, no 
validation necessary.
* global - needs access to the whole database. Not much can be done 
except execute inline at the end of the transaction. Often these are 
SPARQL constraits where you can e.g. count the triples.


/digression


For example, given that the shapes include the shape:
bds:PersonShape-hasParent
 a   sh:PropertyShape ;
 sh:class    bdo:Person ;
 sh:description  "this Person may have at most two 
parents."@en ;

 sh:inversePath  bdo:hasChild ;


??


 sh:maxCount 2 ;
 sh:path bdo:hasParent ;
.
Then I thought that the validation process would check just that:
 P705 rdf:type bdo:Person .
as well as validating the count constraint; and in the case of the 
shape:



Yes - there are two constraints: sh:class and sh:maxCount


bds:PersonShape-hasFather
 a   sh:PropertyShape ;
 sh:description  "this Person may have a father."@en ;
 sh:inversePath  bdo:hasChild ;


Is that supposed to be:

sh:path [ sh:inversePath  bdo:hasChild  ]

?

A property shape has a sh:path and that sh:path can be a inverse path.

sh:inversePath isn't used on the property shape itself.


 sh:maxCount 1 ;
 sh:node bds:MaleShape ;
 sh:path bdo:hasFather ;


and now we have two sh:paths?

(If that is you shape, the sh:inversePath is going to be ignored as 
it is out of place.)



.
will in addition check that:
 P705 bdo:gender bdr:GenderMale .
and not check any other constraints on P705, such as its students or 
kinship relations.


If P705 is reached with "sh:path bdo:hasFather"

The purpose being that when a user has “edited” an existing resource 
or “created” a new resource then we just want to validate the 
changed or new resource without having the validation process 
traverse all resources reachable from P707 via arbitrary length 
paths, which is unnecessary.
Assuming the validator.validate(Shapes, Graph, Node) works along the 
lines I’ve sketched, then since the shacl endpoint doesn’t use this 
method it would take an extension to the endpoint or a new endpoint 
to accomplish want I’ve described.


See the code.

    validator.validate(Shapes, Graph, Node)

executes the shapes (any that apply) to the single focus node.  It 
does check the shapes to see which apply so the target clause (inc 
implicit targets) has to be something that would include the node.




I’m happy to raise an issue and create a PR if that makes sense.


Great.

    Andy


Thank you again very much,
Chris

On May 14, 2020, at 4:16 PM, Andy Seaborne  wrote:

On 1

Re: SHACL Endpoint questions

[Andy Seaborne]

On 19/05/2020 18:44, Chris Tomlinson wrote:

Hi Andy,

Thanks for the very helpful feedback.

1) I did not understand the proper use of sh:inversePath. I thought it was to 
verify that the target of the target/value of the sh:path property had a 
property equal to the value of sh:inversePath. I see that is just not correct.

2) I’ve found an effective solution to the problem of limiting validation to 
just the triples that should be in the graph of a resource such as bdr:P707 by 
creating a new shapes module that uses  [ ] sh:deactivated true   on any 
propertyShapes that leave the graph in question.

I’m getting closer to being able to formulate a plausible extension to the 
shacl endpoint.


looking forward to it.

Having ?graph=..&node=.. makes sense.



Thank you again for your help in the midst of all the 3.15.0 work,
Chris



On May 16, 2020, at 5:45 AM, Andy Seaborne  wrote:



On 15/05/2020 00:57, Chris Tomlinson wrote:

Hello Andy,
I have standalone code using validator.validate(Shapes, Graph, Node) where the 
graph is a merge of the target graph, e.g., P707, and the ontology graph. This 
works fine to validate examples like P707 generating sh:results just for 
references to P705 which is not otherwise included in the merged graph, which 
is what I expect.
If the code was running in Fuseki and the graph is the dataset graph (equiv 
union graph I think) then I would like to know how far out from the node the 
validation process will reach.


That depends on the target (or, here, implicit class target) and the shape 
itself.

digression

... something that I've experimented with - analysing the shapes to determine 
execution strategy. There are some useful cases:

* the validation is only on the triple added (e.g. sh:datatype) - and does not 
need access to the database so it can be done in parallel outside the 
transaction.
* the validation needs local changes (e.g. minCount) to the entity (subject and 
all triples with that subject) - that can be used to reduce the number of 
validations done. If a entity isn't touched, no validation necessary.
* global - needs access to the whole database. Not much can be done except 
execute inline at the end of the transaction. Often these are SPARQL constraits 
where you can e.g. count the triples.

/digression


For example, given that the shapes include the shape:
bds:PersonShape-hasParent
 a   sh:PropertyShape ;
 sh:classbdo:Person ;
 sh:description  "this Person may have at most two parents."@en ;
 sh:inversePath  bdo:hasChild ;


??


 sh:maxCount 2 ;
 sh:path bdo:hasParent ;
.
Then I thought that the validation process would check just that:
 P705 rdf:type bdo:Person .
as well as validating the count constraint; and in the case of the shape:



Yes - there are two constraints: sh:class and sh:maxCount


bds:PersonShape-hasFather
 a   sh:PropertyShape ;
 sh:description  "this Person may have a father."@en ;
 sh:inversePath  bdo:hasChild ;


Is that supposed to be:

sh:path [ sh:inversePath  bdo:hasChild  ]

?

A property shape has a sh:path and that sh:path can be a inverse path.

sh:inversePath isn't used on the property shape itself.


 sh:maxCount 1 ;
 sh:node bds:MaleShape ;
 sh:path bdo:hasFather ;


and now we have two sh:paths?

(If that is you shape, the sh:inversePath is going to be ignored as it is out 
of place.)


.
will in addition check that:
 P705 bdo:gender bdr:GenderMale .
and not check any other constraints on P705, such as its students or kinship 
relations.


If P705 is reached with "sh:path bdo:hasFather"


The purpose being that when a user has “edited” an existing resource or 
“created” a new resource then we just want to validate the changed or new 
resource without having the validation process traverse all resources reachable 
from P707 via arbitrary length paths, which is unnecessary.
Assuming the validator.validate(Shapes, Graph, Node) works along the lines I’ve 
sketched, then since the shacl endpoint doesn’t use this method it would take 
an extension to the endpoint or a new endpoint to accomplish want I’ve 
described.


See the code.

validator.validate(Shapes, Graph, Node)

executes the shapes (any that apply) to the single focus node.  It does check 
the shapes to see which apply so the target clause (inc implicit targets) has 
to be something that would include the node.



I’m happy to raise an issue and create a PR if that makes sense.


Great.

Andy


Thank you again very much,
Chris

On May 14, 2020, at 4:16 PM, Andy Seaborne  wrote:

On 14/05/2020 19:06, Chris Tomlinson wrote:

Hi Andy,
I want to validate a named graph in the context of the union graph. I don’t want to 
validate the union graph. The union graph has information in it such as the ontology 
which defines subClass and subPro

Re: SHACL Endpoint questions

[Chris Tomlinson]

Hi Andy,

Thanks for the very helpful feedback.

1) I did not understand the proper use of sh:inversePath. I thought it was to 
verify that the target of the target/value of the sh:path property had a 
property equal to the value of sh:inversePath. I see that is just not correct.

2) I’ve found an effective solution to the problem of limiting validation to 
just the triples that should be in the graph of a resource such as bdr:P707 by 
creating a new shapes module that uses  [ ] sh:deactivated true   on any 
propertyShapes that leave the graph in question.

I’m getting closer to being able to formulate a plausible extension to the 
shacl endpoint.

Thank you again for your help in the midst of all the 3.15.0 work,
Chris


> On May 16, 2020, at 5:45 AM, Andy Seaborne  wrote:
> 
> 
> 
> On 15/05/2020 00:57, Chris Tomlinson wrote:
>> Hello Andy,
>> I have standalone code using validator.validate(Shapes, Graph, Node) where 
>> the graph is a merge of the target graph, e.g., P707, and the ontology 
>> graph. This works fine to validate examples like P707 generating sh:results 
>> just for references to P705 which is not otherwise included in the merged 
>> graph, which is what I expect.
>> If the code was running in Fuseki and the graph is the dataset graph (equiv 
>> union graph I think) then I would like to know how far out from the node the 
>> validation process will reach.
> 
> That depends on the target (or, here, implicit class target) and the shape 
> itself.
> 
> digression
> 
> ... something that I've experimented with - analysing the shapes to determine 
> execution strategy. There are some useful cases:
> 
> * the validation is only on the triple added (e.g. sh:datatype) - and does 
> not need access to the database so it can be done in parallel outside the 
> transaction.
> * the validation needs local changes (e.g. minCount) to the entity (subject 
> and all triples with that subject) - that can be used to reduce the number of 
> validations done. If a entity isn't touched, no validation necessary.
> * global - needs access to the whole database. Not much can be done except 
> execute inline at the end of the transaction. Often these are SPARQL 
> constraits where you can e.g. count the triples.
> 
> /digression
> 
>> For example, given that the shapes include the shape:
>> bds:PersonShape-hasParent
>> a   sh:PropertyShape ;
>> sh:classbdo:Person ;
>> sh:description  "this Person may have at most two parents."@en ;
>> sh:inversePath  bdo:hasChild ;
> 
> ??
> 
>> sh:maxCount 2 ;
>> sh:path bdo:hasParent ;
>> .
>> Then I thought that the validation process would check just that:
>> P705 rdf:type bdo:Person .
>> as well as validating the count constraint; and in the case of the shape:
> 
> 
> Yes - there are two constraints: sh:class and sh:maxCount
> 
>> bds:PersonShape-hasFather
>> a   sh:PropertyShape ;
>> sh:description  "this Person may have a father."@en ;
>> sh:inversePath  bdo:hasChild ;
> 
> Is that supposed to be:
> 
> sh:path [ sh:inversePath  bdo:hasChild  ]
> 
> ?
> 
> A property shape has a sh:path and that sh:path can be a inverse path.
> 
> sh:inversePath isn't used on the property shape itself.
> 
>> sh:maxCount 1 ;
>> sh:node bds:MaleShape ;
>> sh:path bdo:hasFather ;
> 
> and now we have two sh:paths?
> 
> (If that is you shape, the sh:inversePath is going to be ignored as it is out 
> of place.)
> 
>> .
>> will in addition check that:
>> P705 bdo:gender bdr:GenderMale .
>> and not check any other constraints on P705, such as its students or kinship 
>> relations.
> 
> If P705 is reached with "sh:path bdo:hasFather"
> 
>> The purpose being that when a user has “edited” an existing resource or 
>> “created” a new resource then we just want to validate the changed or new 
>> resource without having the validation process traverse all resources 
>> reachable from P707 via arbitrary length paths, which is unnecessary.
>> Assuming the validator.validate(Shapes, Graph, Node) works along the lines 
>> I’ve sketched, then since the shacl endpoint doesn’t use this method it 
>> would take an extension to the endpoint or a new endpoint to accomplish want 
>> I’ve described.
> 
> See the code.
> 
>validator.validate(Shapes, Graph, Node)
> 
> executes the shapes (any that apply) to the single focus node.  It does check 
> the shapes to see which apply so the 

Re: SHACL Endpoint questions

[Andy Seaborne]

Related/minor:

https://issues.apache.org/jira/browse/JENA-1897

?graph= tidied up so that GSP and SHACL validation service have the same 
behaviour.


Andy

On 16/05/2020 11:45, Andy Seaborne wrote:



On 15/05/2020 00:57, Chris Tomlinson wrote:

Hello Andy,

I have standalone code using validator.validate(Shapes, Graph, Node) 
where the graph is a merge of the target graph, e.g., P707, and the 
ontology graph. This works fine to validate examples like P707 
generating sh:results just for references to P705 which is not 
otherwise included in the merged graph, which is what I expect.


If the code was running in Fuseki and the graph is the dataset graph 
(equiv union graph I think) then I would like to know how far out from 
the node the validation process will reach.


That depends on the target (or, here, implicit class target) and the 
shape itself.


digression

  ... something that I've experimented with - analysing the shapes to 
determine execution strategy. There are some useful cases:


* the validation is only on the triple added (e.g. sh:datatype) - and 
does not need access to the database so it can be done in parallel 
outside the transaction.
* the validation needs local changes (e.g. minCount) to the entity 
(subject and all triples with that subject) - that can be used to reduce 
the number of validations done. If a entity isn't touched, no validation 
necessary.
* global - needs access to the whole database. Not much can be done 
except execute inline at the end of the transaction. Often these are 
SPARQL constraits where you can e.g. count the triples.


/digression



For example, given that the shapes include the shape:

bds:PersonShape-hasParent
 a   sh:PropertyShape ;
 sh:class    bdo:Person ;
 sh:description  "this Person may have at most two parents."@en ;
 sh:inversePath  bdo:hasChild ;


??


 sh:maxCount 2 ;
 sh:path bdo:hasParent ;
.

Then I thought that the validation process would check just that:

 P705 rdf:type bdo:Person .

as well as validating the count constraint; and in the case of the shape:



Yes - there are two constraints: sh:class and sh:maxCount



bds:PersonShape-hasFather
 a   sh:PropertyShape ;
 sh:description  "this Person may have a father."@en ;
 sh:inversePath  bdo:hasChild ;


Is that supposed to be:

sh:path [ sh:inversePath  bdo:hasChild  ]

?

A property shape has a sh:path and that sh:path can be a inverse path.

sh:inversePath isn't used on the property shape itself.


 sh:maxCount 1 ;
 sh:node bds:MaleShape ;
 sh:path bdo:hasFather ;


and now we have two sh:paths?

(If that is you shape, the sh:inversePath is going to be ignored as it 
is out of place.)



.

will in addition check that:

 P705 bdo:gender bdr:GenderMale .

and not check any other constraints on P705, such as its students or 
kinship relations.


If P705 is reached with "sh:path bdo:hasFather"



The purpose being that when a user has “edited” an existing resource 
or “created” a new resource then we just want to validate the changed 
or new resource without having the validation process traverse all 
resources reachable from P707 via arbitrary length paths, which is 
unnecessary.


Assuming the validator.validate(Shapes, Graph, Node) works along the 
lines I’ve sketched, then since the shacl endpoint doesn’t use this 
method it would take an extension to the endpoint or a new endpoint to 
accomplish want I’ve described.


See the code.

     validator.validate(Shapes, Graph, Node)

executes the shapes (any that apply) to the single focus node.  It does 
check the shapes to see which apply so the target clause (inc implicit 
targets) has to be something that would include the node.




I’m happy to raise an issue and create a PR if that makes sense.


Great.

     Andy



Thank you again very much,
Chris




On May 14, 2020, at 4:16 PM, Andy Seaborne  wrote:

On 14/05/2020 19:06, Chris Tomlinson wrote:

Hi Andy,
I want to validate a named graph in the context of the union graph. 
I don’t want to validate the union graph. The union graph has 
information in it such as the ontology which defines subClass and 
subProperty relations needed to successfully validate a target graph 
such as http://purl.bdrc.io/graph/P707 
<http://purl.bdrc.io/graph/P707>.


I don't understand "in the context of the union graph."

Isn't "Context" in RDF is "merge the graphs"?

Validation is a process that operates on a shapes graph (which is 
parsed so really its just shapes - anything else in it is ignored) 
and a data graph.


There's no structure to the data graph - it is everything being 
validated.


I did suggest some SHACL extensions

   https://afs.github.io/shacl-datasets.html

but they are hypothetical extensions.


In code, you coul

Re: SHACL Endpoint questions

[Andy Seaborne]

On 15/05/2020 00:57, Chris Tomlinson wrote:

Hello Andy,

I have standalone code using validator.validate(Shapes, Graph, Node) where the 
graph is a merge of the target graph, e.g., P707, and the ontology graph. This 
works fine to validate examples like P707 generating sh:results just for 
references to P705 which is not otherwise included in the merged graph, which 
is what I expect.

If the code was running in Fuseki and the graph is the dataset graph (equiv 
union graph I think) then I would like to know how far out from the node the 
validation process will reach.


That depends on the target (or, here, implicit class target) and the 
shape itself.


digression

 ... something that I've experimented with - analysing the shapes to 
determine execution strategy. There are some useful cases:


* the validation is only on the triple added (e.g. sh:datatype) - and 
does not need access to the database so it can be done in parallel 
outside the transaction.
* the validation needs local changes (e.g. minCount) to the entity 
(subject and all triples with that subject) - that can be used to reduce 
the number of validations done. If a entity isn't touched, no validation 
necessary.
* global - needs access to the whole database. Not much can be done 
except execute inline at the end of the transaction. Often these are 
SPARQL constraits where you can e.g. count the triples.


/digression



For example, given that the shapes include the shape:

bds:PersonShape-hasParent
 a   sh:PropertyShape ;
 sh:classbdo:Person ;
 sh:description  "this Person may have at most two parents."@en ;
 sh:inversePath  bdo:hasChild ;


??


 sh:maxCount 2 ;
 sh:path bdo:hasParent ;
.

Then I thought that the validation process would check just that:

 P705 rdf:type bdo:Person .

as well as validating the count constraint; and in the case of the shape:



Yes - there are two constraints: sh:class and sh:maxCount



bds:PersonShape-hasFather
 a   sh:PropertyShape ;
 sh:description  "this Person may have a father."@en ;
 sh:inversePath  bdo:hasChild ;


Is that supposed to be:

sh:path [ sh:inversePath  bdo:hasChild  ]

?

A property shape has a sh:path and that sh:path can be a inverse path.

sh:inversePath isn't used on the property shape itself.


 sh:maxCount 1 ;
 sh:node bds:MaleShape ;
 sh:path bdo:hasFather ;


and now we have two sh:paths?

(If that is you shape, the sh:inversePath is going to be ignored as it 
is out of place.)



.

will in addition check that:

 P705 bdo:gender bdr:GenderMale .

and not check any other constraints on P705, such as its students or kinship 
relations.


If P705 is reached with "sh:path bdo:hasFather"



The purpose being that when a user has “edited” an existing resource or 
“created” a new resource then we just want to validate the changed or new 
resource without having the validation process traverse all resources reachable 
from P707 via arbitrary length paths, which is unnecessary.

Assuming the validator.validate(Shapes, Graph, Node) works along the lines I’ve 
sketched, then since the shacl endpoint doesn’t use this method it would take 
an extension to the endpoint or a new endpoint to accomplish want I’ve 
described.


See the code.

validator.validate(Shapes, Graph, Node)

executes the shapes (any that apply) to the single focus node.  It does 
check the shapes to see which apply so the target clause (inc implicit 
targets) has to be something that would include the node.




I’m happy to raise an issue and create a PR if that makes sense.


Great.

Andy



Thank you again very much,
Chris




On May 14, 2020, at 4:16 PM, Andy Seaborne  wrote:

On 14/05/2020 19:06, Chris Tomlinson wrote:

Hi Andy,
I want to validate a named graph in the context of the union graph. I don’t want to 
validate the union graph. The union graph has information in it such as the ontology 
which defines subClass and subProperty relations needed to successfully validate a 
target graph such as http://purl.bdrc.io/graph/P707 
<http://purl.bdrc.io/graph/P707>.


I don't understand "in the context of the union graph."

Isn't "Context" in RDF is "merge the graphs"?

Validation is a process that operates on a shapes graph (which is parsed so 
really its just shapes - anything else in it is ignored) and a data graph.

There's no structure to the data graph - it is everything being validated.

I did suggest some SHACL extensions

   https://afs.github.io/shacl-datasets.html

but they are hypothetical extensions.


In code, you could make a temporary union of two or more graphs to make a 
single data graph.

"a named graph in the context of the union graph."

So the NG is in addition to the dataset graphs? or is in in the dataset alrea