Re: shapes-ISSUE-194 (valueStem): stems in value sets

I will also agree with Holger here, this is a special cases that can be
handled with the existing constructs and something that we can be
independently enabled in the compact syntax.
However, I would be of course open to proposals that does not complicate
the existing design.

On Fri, Nov 11, 2016 at 2:27 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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>)
>>
>>
>>
>>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT