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

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
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 14:18:15 UTC