- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Thu, 29 Oct 2015 17:10:05 -0400
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Holger, OK, I see it now: sh:datatype ( xsd:string rdf:langString ) So are you still proposing sh:or? -- Arthur On Thu, Oct 29, 2015 at 4:34 PM, Holger Knublauch <holger@topquadrant.com> wrote: > On 10/30/15 6:22 AM, Arthur Ryman wrote: >> >> Holger, >> >> The way this was handled in OSLC was to allowed multiple values for >> oslc:range, which is like sh:class here. The semantics was UNION of >> the classes which is the same as your proposed Or. Why not simply >> allow a multiple-valued property, or a List if you really want to >> stick with single-valued properties? > > > Yes, an rdf:List is what I am proposing. All other constraint properties are > single-valued, and I would not support making an exception just for this > single case. It would also introduce unintuitive consequences with > subclassing. > > Holger > > > >> >> -- Arthur >> >> On Fri, Oct 23, 2015 at 1:11 AM, RDF Data Shapes Working Group Issue >> Tracker <sysbot+tracker@w3.org> wrote: >>> >>> shapes-ISSUE-104 (Union ranges): Should sh:datatype and sh:class have >>> better support for OR? [SHACL Spec] >>> >>> http://www.w3.org/2014/data-shapes/track/issues/104 >>> >>> Raised by: Holger Knublauch >>> On product: SHACL Spec >>> >>> While playing with SHACL in practice, I noticed a gap in the spec. >>> >>> It is quite common to have properties that can take multiple types of >>> values. sh:text is one example where we hard-coded the pattern >>> rdf:langString OR xsd:string, but a similar variation is xsd:date OR >>> xsd:dateTime. Another example is skos:member, which is skos:Concept OR >>> skos:Collection. schema.org is full of such examples. >>> >>> To express such unions, the current syntax is very verbose and not >>> suitable for static analysis: >>> >>> ex:MyShape >>> sh:property [ >>> sh:predicate ex:property ; >>> sh:maxCount 1 ; >>> ] ; >>> sh:constraint [ >>> sh:or ( >>> [ >>> sh:property [ >>> sh:predicate ex:property ; >>> sh:datatype xsd:string ; >>> ] >>> ] >>> [ >>> sh:property [ >>> sh:predicate ex:property ; >>> sh:datatype rdf:langString ; >>> ] >>> ] >>> ) >>> ] . >>> >>> An option would be to use OWL's unionOf: >>> >>> ex:MyShape >>> sh:property [ >>> sh:predicate ex:property ; >>> sh:maxCount 1 ; >>> sh:datatype [ >>> a owl:Class ; >>> owl:unionOf ( xsd:string rdf:langString ) >>> ] >>> ] . >>> >>> which is much better because it allows us to put everything into a single >>> sh:property node. However, it adds a dependency on OWL, setting wrong >>> expectations about inferencing and all kinds of other unsupported features >>> such as further nested classes, NOT, AND etc, which are usually unnecessary. >>> >>> I believe we should support this syntax: >>> >>> ex:MyShape >>> sh:property [ >>> sh:predicate ex:property ; >>> sh:maxCount 1 ; >>> sh:datatype ( xsd:string rdf:langString ) >>> ] . >>> >>> In this proposal, the values of sh:datatype, sh:directType and sh:class >>> may either be IRIs of classes or an rdf:List of IRIs. The SPARQL queries in >>> the spec would need to be adjusted accordingly. We can delete sh:text >>> instead. >>> >>> I believe this covers a large number of additional use cases while >>> keeping the complexity and implementation burden to a minimum. I believe it >>> is of strategic importance to have a natural way to express schema.org and >>> other common use cases with SHACL. >>> >>> >>> > >
Received on Thursday, 29 October 2015 21:10:34 UTC