Re: Language Tags Requirement

On 4/25/15 7:40 PM, Holger Knublauch wrote:
> We had already approved a requirement
>
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Language_Tags
>
>
> If there is no distinction between core and complex requirements anyway,
> then why did we introduce another one? Jose confirmed that his intention
> was to have this in the core language, so something sounds like a
> contradiction to me here. If we go down this route, then we could also
> add duplicate requirements for all others listed under Complex
> constraints, such as mathematical operators. I am still unclear what we
> voted on. I believe we could very well add something like sh:lang, but I
> would not consider this "core enough" and rather put this into something
> like shx:lang, i.e. a library of other high-level terms that are not
> expected to be supported by every implementation of SHACL Core. Such an
> shx: library could include many other less frequently needed requirements.


It is possible that when we do define "core" that we will discover that 
parts of some of our requirements are core and other parts are not. The 
requirements are not perfect, and quite honestly I don't know how they 
were generated from the use cases. My question about operations based on 
class rather than property is a good case in point. We have "R5.2: 
Property Min/Max Cardinality" that is specific to properties, yet no 
"Type min/max cardinality" for classes. That would imply, and it did to 
me, that min/max only applies to properties. Min/max for classes is a 
specific requirement of DCMI, as is min/max for properties.

I suspect that the separation between "simple" and "complex" was not 
based on the use cases but on some notion of implementation. If so, we 
should correct that, since the requirements should not be specific to 
implementation.

Personally, I find that the method of use cases -> requirements often 
doesn't result in a coherent whole. I do not get a picture of what SHACL 
is trying to do. I do get such a picture from the DCMI DSP[1], which I 
have linked to often on this list. It provides an overall view of what 
the proposed standard is attempting to do. Having such a view of SHACL 
would be very useful. In fact, I would go so far as to say that if we 
cannot create a simple diagram that describes SHACL we will not have 
succeeded in our task.

kc
[1] http://dublincore.org/documents/dc-dsp/

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Sunday, 26 April 2015 16:02:30 UTC