- From: Håvard Ottestad <hmottestad@gmail.com>
- Date: Fri, 19 Apr 2019 08:10:58 +0200
- To: Simon Steyskal <simon.steyskal@wu.ac.at>
- Cc: Irene Polikoff <irene@topquadrant.com>, Felix Sasaki <felix@sasakiatcf.com>, public-shacl@w3.org
- Message-Id: <98F9B129-6D0C-4D03-B7A4-FC86C4123D6E@gmail.com>
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