W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > June 2017

Re: compiling ShEx oneOf to SHACL

From: Irene Polikoff <irene@topquadrant.com>
Date: Tue, 6 Jun 2017 13:19:06 -0400
Cc: public-rdf-shapes@w3.org
Message-Id: <9A849ABE-4D4F-4088-9E2F-420AFAD9A387@topquadrant.com>
To: Eric Prud'hommeaux <eric@w3.org>

> On Jun 6, 2017, at 4:46 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
> * Irene Polikoff <irene@topquadrant.com> [2017-06-05 17:09-0400]
>> I think you could do
>> 
>> sh:xone ( 
> 
> Is there some reason to use sh:xone instead of sh:or?
> 

Nope. In this case, XONE and OR are the same since the conditions are already mutually exclusive. I stayed with XONE only because of the next comment where I said that maxCounts would not be required if the co-occurance was handled elsewhere.
> 
>> [
>> sh:property [ sh:path foaf:name ; sh:minCount 1 ;];
>                                                   ^ sh:maxCount 1
>> sh:property [ sh:path foaf:familyName ; sh:maxCount 0 ; ];
>> sh:property [sh:path foaf:givenName ; sh:maxCount 0 ; ] 
>> ]
>> 
>> [
>> sh:property [sh:path foaf:familyName ;sh:minCount 1 ;] ;
>                                                       ^ sh:maxCount 1
>> sh:property [sh:path ex:givenName ; sh:minCount 1 ;]; 
>                                                     ^ sh:maxCount 1
>> sh:property [ sh:path foaf:name ; sh:maxCount 0 ;]
>> ] 
>> 
>> ) 
> 
> That makes sense. I added a couple max counts to make it like the ShEx
> example.
> 
> 
>> Or you could skip the use of maxCount=0 in the sh:xone and instead create separate “co-occurance” shapes that say that certain properties should be used together - by using subjectsOf target e.g.
>> 
>> ex:MustHaveGivenName sh:targetSubjectsOf foaf:familyName ;
>> sh:property [sh:path foaf:givenName ; sh:minCount 1 ;]
>> 
>> ex:MustHaveFamilyName sh:targetSubjectsOf foaf:givenName ;
>> sh:property [sh:path foaf:familyName ; sh:minCount 1 ;]
> 
> That seems like a bold rule as you lose contextual control. That would mean you couldn't use either foaf:givenName or foaf:familyName individually anywhere else in your schema.

For a generic translator from ShEx, you are right - this could be too broad. But when one knows their domain, this is an option.
> 
> 
>> It may make sense to create a re-usable co-occurance constant component as part of an extension library, so one didn’t have to create a shape for each predicate in the pair (or more) of predicates that are used together.
> 
> This could provide a useful ShEx library for SHACL, but is it doable in the general case or only where the disjuncts are themselves simple conjunctions of properties?

I have not thought about this much, so I don’t know. There are several property pair constraints already in SHACL Core. One can certainly  define a co-existance constraint for a pair of properties and for some other defined number of properties such as 3, 4, 5. I know that in the past we have created such thing as a SPIN template. I think this would cover 95+% of use cases. Can it be defined for a list of properties of an arbitrary size? In JavaScript, probably.
> 
> 
>>> On Jun 5, 2017, at 2:48 PM, Eric Prud'hommeaux <eric@w3.org> wrote:
>>> 
>>> * Irene Polikoff <irene@topquadrant.com> [2017-06-05 10:54-0400]
>>>> You can use sh:xone instead of sh:or, then you will not need any NOT statements
>>> 
>>> sh:xone works for disjuncts with a single property in them but if
>>> you have more, as in foaf:givenName and foaf:familyName, it doesn't
>>> prevent complete matches of one disjunct with partial matches of
>>> another.
>>> [[
>>> For each value node v let N be the number of the shapes that are
>>> members of $xone where v conforms to the shape.
>>> ]]
>>> (What's "$xone"?)
>>> 
>>> To illustrate this, <F_extraGiven> and <F_extraFamily> pass the shape
>>> below:
>>> 
>>> <P_name>        foaf:name "Bob Smith".
>>> <P_givenFamily>                         foaf:givenName "Bob" ; foaf:familyName "Smith" .
>>> <F_missing>     <p> <o> .
>>> <F_extraBoth>   foaf:name "Bob Smith" ; foaf:givenName "Bob" ; foaf:familyName "Smith" .
>>> <F_extraGiven>  foaf:name "Bob Smith" ; foaf:givenName "Bob" .
>>> <F_extraFamily> foaf:name "Bob Smith" ;                        foaf:familyName "Smith" .
>>> 
>>> 
>>>> http://w3c.github.io/data-shapes/shacl/#XoneConstraintComponent <http://w3c.github.io/data-shapes/shacl/#XoneConstraintComponent>
>>>> 
>>>> 
>>>>> On Jun 5, 2017, at 7:02 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
>>>>> 
>>>>> I'm considering the feasibility of compiling ShEx to SHACL. Is there a
>>>>> shorter way to compile this ShEx oneOf:
>>>>> 
>>>>> <NameShape> {
>>>>>  foaf:name LITERAL
>>>>> | foaf:givenName LITERAL ; foaf:familyName LITERAL
>>>>> }
>>>>> 
>>>>> than this SHACL?:
>>>>> 
>>>>> :UserShape
>>>>> sh:or (
>>>>>  [ sh:and (
>>>>>    [ sh:property
>>>>>      [ sh:path foaf:name; sh:minCount 1; sh:maxCount 1 ] ]
>>>>>    [ sh:not [
>>>>>       sh:property
>>>>>         [ sh:path foaf:givenName; sh:minCount 1; sh:maxCount 1 ] ] ]
>>>>>    [ sh:not [
>>>>>       sh:property
>>>>>         [ sh:path foaf:familyName; sh:minCount 1; sh:maxCount 1 ] ] ] ) ]
>>>>>  [ sh:and (
>>>>>    [ sh:not [ sh:property
>>>>>      [ sh:path foaf:name; sh:minCount 1; sh:maxCount 1 ] ] ]
>>>>>    [ sh:property
>>>>>      [ sh:path foaf:givenName; sh:minCount 1; sh:maxCount 1 ] ]
>>>>>    [ sh:property
>>>>>      [ sh:path foaf:familyName; sh:minCount 1; sh:maxCount 1 ] ] ) ] ) .
>>>>> 
>>>>> -- 
>>>>> -ericP
>>>>> 
>>>>> office: +1.617.599.3509
>>>>> mobile: +33.6.80.80.35.59
>>>>> 
>>>>> (eric@w3.org)
>>>>> Feel free to forward this message to any list for any purpose other than
>>>>> email address distribution.
>>>>> 
>>>>> There are subtle nuances encoded in font variation and clever layout
>>>>> which can only be seen by printing this message on high-clay paper.
>>>>> 
>>>> 
>>> 
>>> -- 
>>> -ericP
>>> 
>>> office: +1.617.599.3509
>>> mobile: +33.6.80.80.35.59
>>> 
>>> (eric@w3.org)
>>> Feel free to forward this message to any list for any purpose other than
>>> email address distribution.
>>> 
>>> There are subtle nuances encoded in font variation and clever layout
>>> which can only be seen by printing this message on high-clay paper.
>> 
> 
> -- 
> -ericP
> 
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
> 
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
Received on Tuesday, 6 June 2017 17:19:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:50 UTC