- From: Gary Murphy <gary@schemaapp.com>
- Date: Tue, 26 Mar 2019 09:33:07 -0400
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-shacl@w3.org
- Message-ID: <CADnyxpu_KuXO+U1CEdDVj3z8NpY984Ykpf19weLOzzTQHqzbtg@mail.gmail.com>
do we have any documentation on patterns of use for sh:details?
I found your post at https://github.com/TopQuadrant/shacl/issues/14 that
outlines the effect and mentions docs could be coming, but
https://www.w3.org/TR/shacl/#results-detail is pretty short on details
(pardon the pun)
and as much as I like the Playground for testing, I'd be using the java
implementation for any real work.
On Wed, Mar 20, 2019 at 6:51 PM Holger Knublauch <holger@topquadrant.com>
wrote:
> Yes, the WG had discussed this during the design of SHACL and decided to
> not include "nested" violations from sh:node (and similar constraint types)
> into the top-level validation report. Instead, sh:details was introduced
> and, for example, the TopBraid SHACL API (in Java) does support a flag to
> activate these details. I don't think the JavaScript-based SHACL playground
> has this option.
>
> Holger
>
>
> On 21/03/2019 2:48 am, Gary Murphy wrote:
>
> using nested NodeShapes called in with sh:node gives a result that is very
> close, but lacks clarity in the report:
>
> Given our old friend Bob:
> ex:Bob
> a schema:Person ;
> schema:givenName "Robert" ;
> schema:familyName "Junior" ;
> schema:birthDate "1971-07-07x"^^xsd:string ;
> schema:deathDate "1968-09-10"^^xsd:date ;
>
> and the shacl rules
> schema:DateTimeNodeShape
> a sh:NodeShape ;
> sh:or (
> [ sh:datatype xsd:dateTime ]
> [ sh:datatype xsd:date ]
> [
> sh:datatype xsd:string ;
> sh:pattern
> "^\\d{4}-\\d{2}-\\d{2}(T\\d{2}:\\d{2}:\\d{2}[0-9+Z-]*)?$" ;
> ]
> ) ;
> sh:name "dateTime" ;
> sh:message "date must be xsd:date, xsd:dateTime or xsd:string in ISO
> format, eg 2018-12-18T12:00:00.000+0500" ;
> sh:severity sh:Warning ;
> .
>
> schema:PersonShape
> a sh:NodeShape ;
> sh:targetClass schema:Person ;
> sh:property [
> sh:path schema:birthDate ;
> sh:node schema:DateTimeNodeShape ;
> sh:lessThan schema:deathDate ;
> sh:maxCount 1 ;
> ] ;
> .
>
> A violation of sh:Warning in the DateTimeNodeShape and it's sh:message are
> ignored, and the UI would receive the unhelpful report
>
> [
> a sh:ValidationResult ;
> sh:resultSeverity sh:Violation ;
> sh:sourceConstraintComponent sh:NodeConstraintComponent ;
> sh:sourceShape _:n396 ;
> sh:focusNode <http://example.org/ns#Bob> ;
> sh:value "1971-07-07x" ;
> sh:resultPath schema:birthDate ;
> sh:resultMessage "Value does not have shape schema:DateTimeNodeShape" ;
> ] .
>
> ps -- thanks for spotting the +-Z slip in the regex; my datasets never
> crossed this, but clearly +Z- is what was meant ;)
>
> On Wed, Mar 20, 2019 at 11:43 AM Gary Murphy <gary@schemaapp.com> wrote:
>
>> Thanks -- I think NodeShape is probably what I'm needing as this allows
>> segmenting the sh:message apart from the rest of the rules, and for
>> UI-building purposes, avoids duplicate sh:property blocks
>>
>> On Tue, Mar 19, 2019 at 8:51 PM Irene Polikoff <irene@topquadrant.com>
>> wrote:
>>
>>> A PropertyShape must have sh:path - see
>>> https://www.w3.org/TR/shacl/#property-shapes
>>>
>>> If there is no {myshape:DateShape sh:path ?something} triple, you have
>>> an invalid shapes graph.
>>>
>>> You could create a node shape defining conditions on the value. Then,
>>> use it like this:
>>>
>>> myshape:PersonShape a sh:NodeShape ;
>>> sh:property [
>>> sh:path ex:birthDate ;
>>> sh:node myshape:DateShape;
>>> sh:lessThan ex:deathDate ;
>>> sh:message "Birth date must be before death date unless time
>>> travel is possible” .}
>>>
>>> In this example, myshape:DateShape is a node shape. For example:
>>>
>>> myshape:DateShape a sh:NodeShape ;
>>> sh:datatype xsd:string ;
>>>
>>> sh:pattern "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}[0-9.+-Z]*$”.
>>>
>>>
>>> You can also use sh:or in the node shape, but your syntax is incorrect.
>>> It would be something like
>>>
>>> myshape:DateShape a sh:NodeShape ;
>>> sh:or (
>>> [
>>> sh:datatype xsd:dateTime;
>>> ]
>>> [
>>> sh:datatype xsd:string ;
>>>
>>> sh:pattern "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}[0-9.+-Z]*$”;
>>> ]
>>> ) .
>>>
>>> Although, I think your sh:pattern value may have some syntax issues as
>>> well.
>>>
>>>
>>> On Mar 19, 2019, at 2:17 PM, Gary Murphy <gary@schemaapp.com> wrote:
>>>
>>> Seeking some guidance with a frequent pattern: I have several
>>> properties which are all constrained to xsd:dateTime or xsd:string with a
>>> regex for ISO dates, but each of these properties also has other
>>> constraints such as maxCount = 1
>>>
>>> So for a familiar example, in Person, for birthDate, I have these
>>> alternatives in sh:or clauses, plus I have the maxCount and the sh:lessThan
>>> deathDate rules, but when the data value is the wrong type, the violation
>>> takes the sh:message for the entire test, reporting only that the
>>> sh:OrConstraintComponent was violated and then a second violation for
>>> sh:LessThanConstraintComponent.
>>>
>>> I can of course split these into successive sh:property rules for the
>>> same sh:path and each with it's own sh:message, but the same datatype
>>> constraints apply also to deathDate and every other date value in my
>>> graph. I'd far prefer to define the rules for all date-like paths in one
>>> place.
>>>
>>> Is it possible to define a generic "value shape" where the rules are
>>> applied to the current path rather than to a path defined in the shape
>>> itself?
>>>
>>> something like
>>>
>>> myshape:DateShape a sh:PropertyShape ;
>>> [ sh:datatype xsd:dateTime ]
>>> [ sh:datatype xsd:date ]
>>> [ sh:datatype xsd:string ;
>>> sh:pattern
>>> "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}[0-9.+-Z]*$" ;
>>> ]
>>> ) ;
>>> sh:name "dateTime" ;
>>> gist:start "2017-12-18T17:00:00Z"^^xsd:dateTime ;
>>> sh:message "Date must be xsd:date xsd:dateTime or string in ISO
>>> format, eg 2018-12-18T12:00:00.000+0500" .
>>>
>>> myshape:PersonShape a sh:NodeShape ;
>>> sh:property [
>>> sh:path ex:birthDate ;
>>> sh:??? myshape:DateShape ; # can this be done?
>>> sh:lessThan ex:deathDate ;
>>> sh:message "Birth date must be before death date unless time
>>> travel is possible" .
>>>
>>> Is there any mechanism in shacl to apply a path-agnostic shape?
>>> --
>>> Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham
>>> N 'C', Guelph
>>>
>>>
>>>
>>
>> --
>> Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham N
>> 'C', Guelph
>>
>
>
> --
> Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham N
> 'C', Guelph
>
>
--
Gary Lawrence Murphy <gary@schemaapp.com> - Hunch Manifest, 15 Wyndham N
'C', Guelph
Received on Tuesday, 26 March 2019 13:33:42 UTC