- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 30 Mar 2016 10:41:32 +1000
- To: public-data-shapes-wg@w3.org
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