W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

Re: shapes-ISSUE-141 (Mixed ranges): How to represent mixed datatype-or-class ranges [SHACL - Core]

From: Holger Knublauch <holger@topquadrant.com>
Date: Wed, 30 Mar 2016 10:41:32 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <56FB20BC.3070008@topquadrant.com>
On 29/03/2016 2:42, Peter F. Patel-Schneider wrote:
>
>> 2) Improve syntax of sh:or (and sh:and) to allow for property constraints:
>>
>> schema:AddressShape
>>      a sh:Shape ;
>>      sh:property [
>>          sh:predicate schema:address ;
>>          sh:or (
>>              [ sh:datatype xsd:string ]
>>              [ sh:class schema:PostalAddress ]
>>          )
>>      ] .
>>
>> (The values of the list would be sh:PropertyConstraints that use the same sh:predicate from the surrounding property constraint.)
> How is typing of these anonymous constraints going to work?  In your example
> they are not sh:PropertyConstraints.  How is the predicate going to be pushed
> into them?

The typeless nodes would be treated similarly to default value types. 
Not sure if it's worth generalizing a mechanism for that. Pushing the 
predicate into the evaluation is an implementation detail. We have a 
separate ticket open (ISSUE-135) that is about generalizing and/or. This 
will likely either lead to a generalization of sh:hasShape or a similar 
function. Other implementation strategies, such as generating nested 
SPARQL for the OR options, would work. What matters is that the spec 
defines what needs to be produced (i.e. input and output). Once we agree 
on the direction (for the user facing syntax) we can work out these details.

>
>> A follow-up of 2) would be that we could drop sh:classIn and sh:datatypeIn to avoid too many syntaxes for the same thing.
>
> I think that the good solution would have been to have an sh:typeIn construct
> that allows for both classes and datatypes.  However, the current semantics
> for sh:class and sh:classIn do not match up with the current semantics of
> sh:datatype.  sh:datatype is instead analogous to sh:directType.  Mixing the
> SHACL subclass typing from sh:classIn with the direct Literal typing of
> sh:datatype would lead to confusion.

I think sh:type and sh:typeIn are still worth exploring. I still believe 
there would be value in bringing sh:class and sh:datatype together (just 
like RDFS and OWL do it too). While I don't have any statistics or any 
systematic evaluation of potential users, I believe that such a mixed 
semantics would be intuitively well-understood by most users:
- for classes, I believe most users would expect that subclasses are 
included
- for datatypes, I believe most users would expect only the asserted 
datatype

As we don't have formal evidence in one direction or another, we could 
either just leave it as currently defined (with two separate 
constructs), or go ahead and define what we believe is best and expose 
it to the user community in a future working draft, then see what people 
stumble across.

Holger
Received on Wednesday, 30 March 2016 00:42:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC