- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 11 Nov 2016 10:27:00 +1000
- To: public-data-shapes-wg@w3.org
Both cases can be covered with existing features (sh:or and sh:not) and I am against adding redundant special handling just for stem. The same argument could be applied to almost every other constraint type, e.g. sh:datatype. Unless I am missing something, I propose closing without action. Holger On 8/11/2016 23:39, RDF Data Shapes Working Group Issue Tracker wrote: > shapes-ISSUE-194 (valueStem): stems in value sets > > http://www.w3.org/2014/data-shapes/track/issues/194 > > Raised by: Eric Prud'hommeaux > On product: > > The current SHACL definition for stem (see 4.5.4 sh:stem <http://w3c.github.io/data-shapes/shacl/#StemConstraintComponent>) treats them as a Parameter while ShEx uses them in value sets (see 4.4.6 Values Constraint <https://shexspec.github.io/spec/#values>). The SHACL definition use doesn't offer much value over an XSD pattern. It's pretty common for clinical value sets to require any value with starting with one of a number of base IRIs (e.g. terminologies like LOINC, SNOMED, CPT, ...). > > Another diff is that ShEx value sets have exclusions which can in turn be stems (see 10 Value Sets <http://shex.io/primer/#h-value-sets>) > > >
Received on Friday, 11 November 2016 00:27:37 UTC