- From: Simon Steyskal <simon.steyskal@wu.ac.at>
- Date: Fri, 19 Apr 2019 07:01:00 +0200
- To: Irene Polikoff <irene@topquadrant.com>
- Cc: Felix Sasaki <felix@sasakiatcf.com>, public-shacl@w3.org
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 05:01:28 UTC