Re: Language tags as values - document consequences (Concepts and MT)

On 12/05/13 15:17, Andy Seaborne wrote:
>
>
> On 11/05/13 18:36, Pat Hayes wrote:
>>
>> On May 11, 2013, at 6:20 AM, Andy Seaborne wrote:
> ...
>
>>> , with them being handled by D-entailment like any other datatype,
>>> they don't generate basic RDF inconsistency do they?  Only if the
>>> particular D-entailments are supported?
>>
>> Yes, *if* we do that, then my problems go away. But currently that
>> is not a WG decision, I believe.
>
> For me, the most important objective is to finish.  We have an extension
> and it is very rigid.
>
> When I read concepts, it struck me that putting all the datatypes needed
> to be discussed together (Concepts, sec 5) was natural and could remove
> complexity from semantics.
>
> At this point, the shortest path to publication has got to be a major
> deciding factor.
>
> So if the editors (semantics and concepts) thing this is the way

So if the editors (semantics and concepts) *think* this is the way

> forward, let's get the WG decision made.
>
>>> rdf:langString is in the abstract syntax, so we do need to say
>>> something somewhere even if it is not an absolute requirement to
>>> support the datatype.  That can go in concepts.
>>>
>>> I would be happy either with a requirement that the langtag MUST
>>> match by BCP47 (or the weaker RFC3066) and so @500 is simply not
>>> RDF (like <foo>@en). Also, I'd be happy to say that at the
>>> abstract syntax level a language tag is a string.  It's ill-typed
>>> by section 8 like any other datatype with a non-mapping to the
>>> value space.
>>>
>>> Neither of these give RDF-inconsistency do they?
>>
>> The second does if rdf:langString is built into RDF entailment
>> (which, to repeat, it currently is.)
>>
>>>
>>> Andy
>>>
>>> PS There are xs:string can be ill-typed (e.g. "\u0000").
>>
>> Really? I guess I was under the impression that this was a syntax
>> error. Sigh. I wish we could get this clear. Just using MUST (NOT)
>> language or just saying "literals are" something does not make it
>> clear enough.
>
> Possible to make it a syntax error if it's a built-in datatype -
> otherwise it's a ill-datatyped literal.
>
>>
>>> Hence the suggestion to make it not required to be handled in RDF,
>>> only at the D-entailment level.  Also avoids the minor issue that
>>> xs:string (XML 1.0) and xs:string (XML 1.1) are different.
>>
>> In semantics, there are no minor issues :-)
>
> Having this week had to deal with XML (1.0) that tried to contain a ^Z
> in content, I can say that such details do come up in practice.
>
> (yes - the root cause was a data error; displayable strings don't
> usually need to contain ^Z but it is ASCII; yes - everything worked ...
> except XML related output)
>
>      Andy
>

Received on Sunday, 12 May 2013 16:58:39 UTC