Re: Comments on this afternoon session on Turtle (ISSUE-12)

I would like to understand the role of the datatype rdf:PlainLiteral[1] in this puzzle, we seem to have forgotten it... My understanding is that rdf:plainLiteral is a Datatype (ie, it can be used as part of datatype reasoning in RDF, OWL, or RIF) which is not the case of plain literals, and its value space[2] are pairs of the form <string,language-tag>, which is the problem with xsd:string. So what is the issue (and I am sure Andy will say that, because I remember he had major discussions with the editors of the rdf:PlainLiteral editors at the time) as using rdf:PlainLiteral as THE common denominator here? Ie, datatype("chat"@en) would return rdf:PlainLiteral.

Just asking to add to the confusion...

Ivan

[1] http://www.w3.org/TR/rdf-plain-literal/
[2] http://www.w3.org/TR/rdf-plain-literal/#Definition_of_the_rdf:PlainLiteral_Datatype



On Apr 16, 2011, at 19:56 , Richard Cyganiak wrote:

> On 16 Apr 2011, at 18:32, Lee Feigenbaum wrote:
>>> Personally I don't mind xsd:string being used in range declarations
>>> to indicate that the value has to be a plain literal without language
>>> tag.
>> 
>> What do you think should be the return of datatype("foo")? I'd like it to be xs:string.
> 
> I don't have a strong preference. With programmer goggles on, xsd:string would certainly make sense, but legacy is a concern.
> 
> What do you think should be returned for datatype("chat"@en)?
> 
>>> The problem with xsd:string typed literals is that for authors, the
>>> choice between "foo" and "foo"^^xsd:string is arbitrary, but those
>>> who want to query the data or access it in an API need to know what
>>> choice the author made. This is a constant source of usability
>>> issues. Hence the desire to normalize both forms internally.
>> 
>> Agreed. Note that either approach (normalizing to plain literals or to xs:string literals) would accomplish this.
> 
> Yes.
> 
>>> I think it's important that the canonical form is "foo" rather than
>>> "foo"^^xsd:string because writing the latter is awkward in all
>>> syntaxes.
>> 
>> I agree, but I don't think the syntax issue is a big deal. What I would propose is something like:
>> 
>> + Eliminate (or make archaic or what not) plain literals from RDF abstract syntax.
>> 
>> + Note that all plain literals ought to be interpreted as xs:string literals, in all syntaxes. In Turtle, this would mean that "foo" is a syntactic shortcut for "foo"^^xs:string, the same way that 14 is a shortcut for "14"^^xsd:integer.
> 
> This would push the issue to the syntax level. Essentially, what should be a data model issue now becomes mandatory syntactic sugar in every syntax.
> 
> Would you forbid "foo" in N-Triples, or make that syntactic sugar for the typed form?
> 
>> Basically, I'm motivated by:
>> 
>> * datatype("foo") = xs:string
>> * ...retaining the ability to have properties with rdfs:range xs:string
>> * ...retaining the ability to write "foo" in Turtle and Turtle-like syntaxes
>> * ...having "foo" match "foo"^^xs:string in SPARQL basic graph pattern matching
> 
> You can have all of these with either proposal. The question is where to put all the special casing.
> 
> Best,
> Richard
> 
> 
> 
>> 
>> Lee
>> 
>>> Best, Richard
>>> 
>> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf