- 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