Re: shapes-ISSUE-198 (rdf:langString): rdf:langString not included in datatypes [SHACL Spec]

On 20/11/2016 3:16, Karen Coyle wrote:
>
>
> On 11/17/16 10:50 PM, Holger Knublauch wrote:
>> Hi Karen,
>>
>> - RDF 1.1 *does* mention rdf:langString (see the NOTE in
>> https://www.w3.org/TR/rdf11-concepts/#section-Datatypes)
>
> Yes, and it says there:
> "Language-tagged strings have the datatype IRI 
> http://www.w3.org/1999/02/22-rdf-syntax-ns#langString. No datatype is 
> formally defined for this IRI because the definition of datatypes does 
> not accommodate language tags in the lexical space. The value space 
> associated with this datatype IRI is the set of all pairs of strings 
> and language tags."
>
> So it treats it as an exception, and says that it is not defined as a 
> datatype.
>
> SKOS also describes language strings as an exception, of sorts:
> "Formally, a lexical label is an RDF plain literal [RDF-CONCEPTS]. An 
> RDF plain literal is composed of a lexical form, which is a string of 
> UNICODE characters, and an optional language tag, which is a string of 
> characters conforming to the syntax defined by [BCP47]."
>
> This says to me that RDF plain literals are NOT included in datatypes. 
> xsd has xsd:string but that is not the same as the rdf literal.
>
> I can't say that this is crystal clear to me, but language strings 
> will be very important so I want it to be clear how they are handled 
> in SHACL. 

I have added a clarification to highlight the sh:datatype rdf:langString 
trick:

https://github.com/w3c/data-shapes/commit/94e68840b9d11e6ce0abdc79e296b607f8c024be

HTH
Holger


> We do have a use case (U21) that requires that SHACL can be used to 
> validate SKOS vocabularies. I will try to find someone from the SKOS 
> community who has more knowledge of this.
>
> kc
>
>
>
>>
>> - I see no need to explicitly enumerate all datatypes, because RDF 1.1
>> itself allows arbitrary IRIs to be used, including user-defined
>> datatypes. I don't see why rdf:langString would be special.
>>
>> - I noticed however that with our recent edit to the semantics of
>> sh:datatype we have lost an important detail, namely that the definition
>> of what is the datatype of a literal must follow the semantics of the
>> datatype operator in SPARQL [1]. I have added this clarification:
>>
>> https://github.com/w3c/data-shapes/commit/eb8eca7d23a91ab884949bc337b5e1a0cee2f747 
>>
>>
>>
>> If you follow the SPARQL 1.1 link below, you will see that this
>> explicitly mentions rdf:langString, so I think we are covered.
>>
>> Please let me know if this addresses your issue.
>>
>> Thanks,
>> Holger
>>
>> [1] https://www.w3.org/TR/sparql11-query/#func-datatype
>>
>>
>> On 18/11/2016 8:34, RDF Data Shapes Working Group Issue Tracker wrote:
>>> shapes-ISSUE-198 (rdf:langString): rdf:langString not included in
>>> datatypes [SHACL Spec]
>>>
>>> http://www.w3.org/2014/data-shapes/track/issues/198
>>>
>>> Raised by: Karen Coyle
>>> On product: SHACL Spec
>>>
>>> >From email of 31 October 2016:[2]
>>>>> *Karen*
>>>>> This checks the ^^xsd:X literals. sh:nodeKind checks for IRI, bnode,
>>>>> or literal. There's one more type in RDF 1.1 [1] which is the
>>>>> "language-tagged string". We have sh:uniqueLang and sh:languageIn, 
>>>>> but
>>>>> is there also a need to check that a literal is language-tagged?
>>>> *Holger*
>>>> Being language-tagged is already checked via sh:datatype 
>>>> rdf:langString.
>>>> So I think that's handled OK.
>>> OK, but the terminology entry for "datatype" cites RDF 1.1 concepts, 
>>> and
>>> rdf:langString doesn't appear in that document. It is defined in RDF
>>> Schema 1.1, though.[1] Does that mean it should be listed specifically
>>> with RDFS as its reference?
>>>
>>> kc
>>> [1] https://www.w3.org/TR/2014/REC-rdf-schema-20140225/#ch_langstring
>>> [2]https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0001.html 
>>>
>>>
>>>
>>> ***Proposal***
>>>
>>> Modify definition of datatypes in SHACL to include rdf:langString from
>>> RDF schema. Also, is rdfs:Literal also needed?
>>>
>>>
>>>
>>
>>
>>
>

Received on Saturday, 19 November 2016 22:58:15 UTC