Re: Request for review of Shapes Constraint Language (SHACL) before CR

On 03/02/2017 12:56 AM, Holger Knublauch wrote:
> Hi Addison,
>
> my sincere apologies for the late notice. Since the beginning of the 
> year we had W3C staff changes and operated without a formal WG chair. 
> We have failed to check our obligations in the process properly. The 
> need for the i18n review was only brought to our attention by Sandro 
> when he joined the WG last week.
>

Indeed, it's an unfortunately state of affairs, about which we are 
currently doing all we can, IMHO.   I'm talking to r12a about more 
general fixes, and would be happy to work with you on that, unrelated to 
this group.

Meanwhile, on the matter at hand, in case you are able to find a little 
time:

As Holger noted, SHACL specifies an RDF-triples-in, RDF-triples-out 
system, so in general all the natural language handling is dictated by 
RDF's natural language handling.     A few details that occur to me (and 
I'm cc'ing the group so they can correct me if I got anything wrong -- 
I'm very new to SHACL) :

1. As in RDF, any text string can easily be given a language tag. So 
this part's good.

2. However, in RDF, as far as I know, there's no standardized way to add 
indications of text direction in the metadata around text. rdf:HTML and 
rdf:XMLLiteral values have their normal ways of doing dir inside the 
data, and of course text strings have their normal (but imperfect) ways 
to do it (eg using the first strong directional character).  I expect if 
a way were standardized for doing this in RDF, it would simply work in 
SHACL.   If you know of a design for doing this, we could confirm this 
expectation.

3.  My understanding is RDF's language tagging conflicts with its 
handling of meaningful multiple values.   For example, in { :myCat 
:label "Cat"@en, "Chat"@fr, "Kitten"@en } it's at best hard to 
disentangle the multiple values in software, figuring out that the first 
two values relate as translations, while the third is a different kind 
of alternative value.   SHACL continues best practice around this design 
challenge by advising people to avoid it, saying "Both |sh:name| and 
|sh:description| may have multiple values 
<https://www.w3.org/TR/shacl/#dfn-value>, but should only have one value 
<https://www.w3.org/TR/shacl/#dfn-value> per language tag." and "A shape 
should not have more than one value for |sh:message| with the same 
language tag."    Beyond this, SHACL provides a mechanism, sh:uniqueLang 
(section 4.4.5), for allowing this best practice to be enforced in 
validated data.

4.  In general, SHACL allows one to validate values for certain 
properties as being text tagged with certain language tags, using 
sh:languageIn (section 4.4.4).    The actual matching algorithm is 
specified to be the same as in SPARQL, which is important, since SHACL 
implementations are often implemented using SPARQL engines. (IE, we're 
not really at liberty to change the algorithm, if it turned out there 
were a reason for doing so.)  This seems like a useful feature in 
support of practical i18n.

That's all I've come up with.   I hope that helps a bit.

      -- Sandro


> Thanks,
> Holger
>
>
> On 2/03/2017 15:50, Phillips, Addison wrote:
>> Hello Holger,
>>
>> Thanks for the note. I have added this request to our review radar.
>>
>> While hopefully there are no I18N issues, I do have to point out that 
>> your moving to CR by the end of March kind of depends on our not 
>> finding any issues. Our process depends on a working group review of 
>> collected comments in our weekly teleconference. I have three 
>> requests ahead of yours in addition to the review of TTML2 that we 
>> are currently finishing up. If we were to find issues, you might not 
>> have time to respond to them and keep your date. Most working groups 
>> have spent significant time building their specifications. It is 
>> unreasonable to expect to get a thorough and valuable review on 
>> demand in only a week or two (leaving time for reaction).
>>
>> Regards (for I18N),
>>
>> Addison
>>
>> Addison Phillips
>> Principal SDE, I18N Architect (Amazon)
>> Chair (W3C I18N WG)
>>
>> Internationalization is not a feature.
>> It is an architecture.
>>
>>
>>
>>> -----Original Message-----
>>> From: Holger Knublauch [mailto:holger@topquadrant.com]
>>> Sent: Thursday, March 02, 2017 6:05 AM
>>> To: www-international@w3.org
>>> Cc: sandro@w3.org
>>> Subject: Request for review of Shapes Constraint Language (SHACL) 
>>> before CR
>>>
>>> Hi,
>>>
>>> the W3C Data Shapes Working Group would like to move its main 
>>> deliverable
>>>
>>>       http://w3c.github.io/data-shapes/shacl/
>>>
>>> to CR status by the end of March. We would appreciate a review of 
>>> its i18n
>>> aspects.
>>>
>>> SHACL is an RDF based language to describe constraints on data models.
>>> The language is built for machines and has almost no user interface 
>>> aspects.
>>> Execution typically happens "server-side" and the output is a list 
>>> of constraint
>>> violations. The handling of strings in multiple languages is 
>>> inherited from RDF.
>>> We use this RDF mechanism in a couple of places, e.g. sh:name and 
>>> sh:message,
>>> to define user output in multiple languages. But SHACL doesn't do 
>>> anything
>>> beyond the RDF standard in this respect. I did the i18n self-test 
>>> and nothing else
>>> raised my attention.
>>>
>>> Thanks
>>> Holger
>>>
>