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