Re: Proposal for ISSUE-12 language-tagged literals

On 21 Jul 2011, at 13:53, Andy Seaborne wrote:
>>> The datatype concept as it exists seems to mix mapping and value.
>> 
>> RDF Concepts is sloppy in that regard. RDF Semantics says that literals *denote*. Plain literals denote themselves. Typed literals denote the result of applying L2V to the lexical form.
> 
> I'm not sure what your point is here: the text in semantics has to change anyway (e.g. rule xsd 1b).

You said: “The datatype concept as it exists seems to mix mapping and value.”

I said: It does to some extent in RDF Concepts because parts of it are written in informal language. But if you go back to RDF Semantics then I can't see anywhere that mixes mapping and value.

> I have no idea what happens on output when we have:
> 
> ex:foo owl:sameAs xsd:String .

Nothing happens. RDF parsers and RDF serializers don't perform OWL reasoning. OWL reasoners perform OWL reasoning, and their behaviour is well-defined with respect to the abstract syntax, and isn't affected by this change.

Best,
Richard



> 
> #Abstract syntax
> "bar"^^ex:foo.
> 
> or, worse,
> 
> #Abstract syntax
> "bar"^^ex:foo.
> and later in the output find
>  ex:foo owl:sameAs xsd:String .
> 
> (whole graph analysis before output is not practcial)
> 
> 	Andy
> 
>> 
>> Richard
>> 
>> 
>> 
>> 
>>>> I'm not saying that this makes it a no-go. But if the hack exists
>>>> only to make DATATYPE("foo"@en) behave more consistently in SPARQL,
>>>> then I'd rather see the hack in SPARQL.
>>> 
>>> If it were only SPARQL , I'd agree but this seems to make RDF more regular (note - not perfectly regular).
>>> 
>>>> 
>>>>> It then works for RIF and anything else built to work with RDF.
>>>> 
>>>> No, unfortunately it doesn't, at least as far as I can tell. They
>>>> actually want to have lexical forms for language-tagged literals, so
>>>> that they can stuff the<string,langtag>   pairs into legacy systems
>>>> that don't support language tags. (Or, perhaps closer to the truth,
>>>> so that they can be compatible with RDF's data model in their specs
>>>> without actually supporting language tags in their literal design.)
>>> 
>>> Actually they can do that because if the lexical form of rdf:PlainLiterals is a superset of the lexical forms rdf:LangString, it can be defined so that rdf:LangString is a derived type (the inverse term to "derived" does not seem to be defined in /TR/xpath-datamodel/).
>>> 
>>> It's making rdf:PlainLiteral a super-datatype of xsd:string that does not work.
>>> 
>>>> Thought experiment: If DATATYPE in SPARQL was called something else
>>>> instead, say, “TYPE” (and it would return some magic constant for
>>>> IRIs and blank nodes), would you still advocate making rdf:LangString
>>>> a datatype instead of a class? If yes, then why?
>>> 
>>> Yes, if it can be made to work.  DATATYPE is an accessor to that part of the literal triple.  All literals would have a datatype in the abstract graph.
>>> 
>>>> 
>>>> Best, Richard
>>> 
>>> 	Andy
>>> 
>> 
>> 
>

Received on Thursday, 21 July 2011 13:13:29 UTC