Re: Language Tags Requirement

> On 4/26/15 11:46 AM, Karen Coyle wrote:
>
>> Holger, I agree with Jose on this. We are developing requirements. We
>> have not yet decided which requirements are core or not. (BTW, the Dublin
>> Core community is right now working on identifying its core requirements
>> for application profiles and validation, which we will share with this
>> group. It will be a small list -- less than 2 dozen requirements.) The
>> requirements do not "duplicate things already solved..." etc. they are
>> something entirely different.
>>
>
> 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.
>

Language tags aren't a less frequent feature if you work in multilingual
projects and they are an important part of RDF:

http://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal

In my opinion all SHACL implementations and profiles should have support
for them that's why I think it makes sense to have 2 requirements, one for
complex constraints related to language tags, and another for just basic
support for language tags.

The discussion about what is SHACL core, SHACL high level language, SHACL
sparql, etc. and which features have each one is a different topic and I
think we should separate it from requirements identification.

Notice that I was also happy with having only one requirement for language
tags but it was Richard who suggested that the approved requirement was
about complex constraints and that's why I asked to separate it in two
requirements.


>
>> I don't understand the "once we decided that we leave the question open
>> whether something becomes high-level language or complex feature..." This
>> puzzles me because I think they are two different things: the high-level
>> language is how SHACL is expressed; complex features is a categorization of
>> types of SHACL functions. They are two different planes and cannot be
>> compared. There could be high level language terms defined for complex
>> features if we decide that those features can be expressed in that way.
>> Neither of these defines the core.
>>
>> We obviously need to define our own terms, since we aren't understanding
>> them in the same way.
>>
>
> In my interpretation of the terminology, "High level language" is an RDF
> vocabulary such as sh:property, sh:minCount etc. "Core" is a high level
> language representing frequently needed constraints that the group finds
> important enough. "Complex" is the fallback mechanism, e.g. using SPARQL,
> to represent things that go beyond the Core, and which can be used to
> define new high level terms as macros.
>

>From my point of view the goal is to identify SHACL as a high level
language that can describe/validate all RDF concepts. That language can
have extension mechanisms to support complex constraints but at least, it
must support the basic RDF concepts.

-- 
-- Jose Labra