Re: Question on value based constraints

sh:xone specifies the condition that each value node conforms to exactly one of the provided shapes.

It’s basically “exclusive or”. 

I believe this means that the “one” in xone has nothing to do with maxCount 1. 

Max count 1 would mean you can only have one address. Xone means that all your addresses need to match one of the shapes. 

Håvard

> On 19 Apr 2019, at 07:01, Simon Steyskal <simon.steyskal@wu.ac.at> wrote:
> 
> Hi Irene!
> 
>> sh:path ex:hasAdress ;
>>  sh:or (
>>      [
>>        sh:datatype xsd:string ;
>>      ]
>>      [
>>        sh:class ex:ComplexAddress ;
>>      ]
>>    ) ;
>> .
> 
> 
> But this doesn't take the value of ex:addressType into account ->
> 
>>> How do I model the choice between the two address' shapes based on
>>> the
>>> values "simpleAddress" vs. "complexAddress"?
> 
>> You do not really need xone. If a person can only have one address,
>> then add:
>> sh:maxCount 1 ;
> 
> in which case it would be equivalent to sh:xone again, right? ;)
> e.g.,
> 
> sh:property [
>    sh:path ex:hasAddress ;
>    sh:maxCount 1 ;
>    sh:or (
>      [
>        sh:datatype xsd:string ;
>      ]
>      [
>        sh:class ex:ComplexAddress ;
>      ]
>    )
> ] .
> 
> is just a slightly more verbose version of ->
> 
> sh:property [
>    sh:path ex:hasAddress ;
>    sh:xone (
>      [
>        sh:datatype xsd:string ;
>      ]
>      [
>        sh:class ex:ComplexAddress ;
>      ]
>    )
> ] .
> 
> 
> br, simon
> 
> ---
> DDipl.-Ing. Simon Steyskal
> Institute for Information Business, WU Vienna
> 
> www: http://www.steyskal.info/  twitter: @simonsteys
> 
> Am 2019-04-18 23:51, schrieb Irene Polikoff:
>> Felix,
>> If you want to have a property ex:hasAddress and its values be either
>> a string or a resource which in turn has properties like steel, city,
>> zip, etc., then you can simply use:
>> sh:path ex:hasAdress ;
>>  sh:or (
>>      [
>>        sh:datatype xsd:string ;
>>      ]
>>      [
>>        sh:class ex:ComplexAddress ;
>>      ]
>>    ) ;
>> .
>> You do not really need xone. If a person can only have one address,
>> then add:
>> sh:maxCount 1 ;
>> In this response, I am assuming that your complex addresses look as
>> follows:
>> ex:Address1 ex:ComplexAddress;
>> ex:street “100 Main Street”;
>> ex:city “Any City”;
>> etc.
>> You would then have a shape that checks for validity of complex
>> addresses. This can be done directly on a class (implicit target).
>> For example
>> ex:ComplexAddress a owl:Class, sh:NodeShape;
>> sh:property [
>> sh:path ex:street ;
>> sh:minCount 1
>> sh:datatype xsd:string;];
>> sh:property [
>> sh:path ex:city ;
>> sh:minCount 1
>> sh:datatype xsd:string;];
>> And so on
>> If your complex addresses for some other reason do not have a type
>> statement, then do
>> sh:path ex:hasAdress ;
>>  sh:or (
>>      [
>>        sh:datatype xsd:string ;
>>      ]
>>      [
>>        sh:node ex:ComplexAddressShape ;
>>      ]
>>    ) ;
>> .
>> And also define a shape ex:ComplexAddressShape similar to above as
>> something that has city, street, etc. properties.
>> x:one would be needed if your people could have either
>> ex:streetAddress property or a group of properties
>> ex:city+ex:street+…
>> In other words, there was no intermediate resource to represent
>> complex address.
>> Irene
>>> On Apr 18, 2019, at 1:13 AM, Felix Sasaki <felix@sasakiatcf.com>
>>> wrote:
>>> Perfect, thanks a lot, Simon. This is also in line with what I found
>>> in this tutorial:
>> https://de.slideshare.net/mobile/jpcik/rdf-data-validation-2017-shacl
>>> Regards,
>>> Felix
>>> Am Donnerstag, 18. April 2019 schrieb Simon Steyskal
>>> <simon.steyskal@wu.ac.at>:
>>> fwiw, sh:and isn't really necessary though.. is this what you wanted
>>> ->
>>> https://gist.github.com/simonstey/e3add7ff0740dd95a4c80d26840ca3e3
>>> [1] ?
>>> br simon
>>> ---
>>> DDipl.-Ing. Simon Steyskal
>>> Institute for Information Business, WU Vienna
>>> www: http://www.steyskal.info/  twitter: @simonsteys
>>> Am 2019-04-17 18:41, schrieb Simon Steyskal:
>>> Hi!
>>> have you tried combining sh:xone with two sh:and constraints?
>>> e.g. something along the lines of:
>>> sh:xone (
>>> sh:and (
>>> ex:hasAddress sh:datatype xsd:string
>>> ex:addrType sh:hasValue "simple"
>>> )
>>> sh:and (
>>> ex:hasAddress sh:class ex:complexAddr
>>> ex:addrType sh:hasValue "comolex"
>>> )
>>> )
>>> (I'm on mobile right now so just pseudocode)
>>> br simon
>>> -------- Original message --------
>>> From: Felix Sasaki <felix@sasakiatcf.com>
>>> Date: 4/17/19 18:26 (GMT+01:00)
>>> To: public-shacl@w3.org
>>> Subject: Question on value based constraints
>>> HI all,
>>> I have a question on how to model alternative constraints based on
>>> literal values.
>>> Let's assume the two alternatives ways to express an address:
>>> ALTERNATIVE 1:
>>> ex:person1 ex:hasAddress "Street xzy plz 12345 ..."
>>> ex:person1 ex:addressType "simpleAddress".
>>> ALTERNATIVE 2:
>>> ex:person1 ex:hasAddress ex:someComplexAddress1 # object is an
>>> instance of class ex:complexAddress
>>> ex:person1 ex:addressType "complexAddress".
>>> I want to define two alternative shapes for addresses: one is
>>> simple,
>>> i.e. the literal value "Street xzy plz 12345 ...", and one is
>>> complex,
>>> i.e. an instance of ex:complexAddress.
>>> How do I model the choice between the two address' shapes based on
>>> the
>>> values "simpleAddress" vs. "complexAddress"?
>>> Regards,
>>> Felix
>> Links:
>> ------
>> [1] https://gist.github.com/simonstey/e3add7ff0740dd95a4c80d26840ca3e3
> 

Received on Friday, 19 April 2019 06:11:30 UTC