W3C home > Mailing lists > Public > public-rdf-wg@w3.org > July 2011

Re: Proposal for ISSUE-12 language-tagged literals

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 21 Jul 2011 13:53:15 +0100
Message-ID: <4E28213B.5050502@epimorphics.com>
To: public-rdf-wg@w3.org


On 21/07/11 13:24, Richard Cyganiak wrote:
> On 20 Jul 2011, at 23:07, Andy Seaborne wrote:
>>> What you propose is that datatypes should also be used for certain
>>> *non-typed* literals, and *without* mapping lexical forms to values.

>>>> What breaks if it is a datatype?
>>
>> So far, nothing has been shown to break.
>
> *You* pointed out what breaks:
> http://lists.w3.org/Archives/Public/public-rdf-wg/2011May/0343.html
>
> To paraphrase your own words:
>
> if (this.datatype() != null) {
>    // typed
> } else if (this.languageTag() != null) {
>    // plain literal w/ language tag
> } else {
>    // plain literal w/o language tag
> }
>
> I found this objection quite compelling and gave up on the idea at that point.

That's out of context: the point was that there is code that is testing 
in one order and code testing in another - Steve's fragment contrasted 
with mine.

Because we have already decided to use xsd:string in the abstract 
synatx, but use the unadorned form in serialization, all such code is 
already vulnerable.

>
>> 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).





I have no idea what happens on output when we have:

ex:foo owl:sameAs xsd:String .

#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 12:53:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:44 GMT