Re: ISSUE-12: xs:string VS plain literals: proposed resolution

On 06/05/11 13:32, Alex Hall wrote:
> On Friday, May 6, 2011, Andy Seaborne<>  wrote:
>> On 04/05/11 20:13, Pat Hayes wrote:
>> I am confused. There seems to now be a consensus view that plain,
>> untyped literals are a Good Thing, to be preferred to clunky typed
>> literals.  But the last time I encountered this whole issue of plain
>> literals in RDF, there was a very strong consensus that plainness was
>> a problem, and everything would be better if - in fact, for some,
>> life would be possible only if - all literals had a type. Which is
>> why the rdf:PlainLiteral type was invented, to be the type of these
>> anomalous entities that had no type, in order that every literal
>> would have a type.
>> So, can anyone enlighten me? Are typed literals good or bad? Is
>> plainness beautiful, or a dire problem? And are there any actual
>> arguments either way, or is this all based on intuition and
>> aesthetics?
>> Pat
>> I can take a partial explanation of this ... hopefully we can build a complete picture.  This is only my post hoc rationalisation.
>> People writing data like to write "foo".  They don't really see the need to write "foo"^^xsd:string.  Just like writing 123 for "123"^^xsd:integer. This is the syntax and appearance side of the issue.  What is serialized by "foo"?
> If that's the only reason to have untyped literals then I'd prefer to
> see all literals as typed in the abstract syntax and "a" used as a
> shortcut for "a"^^xsd:string in the concrete syntax. It would simplify
> implementation logic (no longer have to check for no datatype as a
> special case) and align better with RIF and OWL. It does leave open
> the question of how to treat language tags.
> I hesitate to formally propose that, however, because it would mean
> reworking a lot of legacy code, and because making such a major change
> to the RDF Concepts the week SPARQL goes to last call could jeopardize
> their work.
> -Alex


Does using rdf:PlainLiteral internally (i.e. convert on input and output 
only) achieve the simplification of the implementation logic?


Received on Friday, 6 May 2011 14:03:03 UTC