Re: In search of value shapes

Excellent!  Thanks

On Wed, Apr 10, 2019 at 3:25 PM Håvard Ottestad <hmottestad@gmail.com>
wrote:

> Hi Gary,
>
> This is what I posted that Holger answered.
>
> https://github.com/w3c/data-shapes/issues/108
>
>
> And my comment here on jan 18:
> https://github.com/eclipse/rdf4j-storage/pull/149
>
> That’s how I ended up implementing this in my SHACL engine (I think).
>
> Since these things aren’t specified in the spec everyone is going to be
> doing their own thing here.
>
> Håvard
>
>
> On 10 Apr 2019, at 18:12, Gary Murphy <gary@schemaapp.com> wrote:
>
> Håvard,
>
> If you happen to still have those instructions could you forward a copy to
> me? Thanks.
>
> Gary.
>
> On Tue, Mar 26, 2019 at 10:00 AM Håvard Ottestad <hmottestad@gmail.com>
> wrote:
>
>> I ended up asking Holger, and he kindly explained how he recommends to
>> use it for nested violations (eg. sh:or). So RDF4J does the same.
>>
>> Håvard
>>
>> On 26 Mar 2019, at 14:33, Gary Murphy <gary@schemaapp.com> wrote:
>>
>> 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
>>
>>
>
> --
> 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 Wednesday, 10 April 2019 19:28:08 UTC