Re: Datayped tagged literals: a case for option 4 vs option 2d


On 26 Sep 2011, at 14:22, Antoine Zimmermann wrote:
>> No programming language knows that "foo@en" is supposedly a string
>> tagged as English.
> Right but RDF and other specs can---and do---introduce types of their
> own (e.g., rdf:XMLLiteral, rdf:PlainLiteral, owl:decimal, owl:real for
> instance). The datatype mechanism of RDF is extensible so that we can do this kind of things.

The nice things about extensibility points is that the misdesigned and bizarre extensions just get ignored.

I consider i18n support an important part of RDF. I don't want to see it converted into a misdesigned and bizarre extension that subsequently will be ignored.

(Aside: As an extension mechanism, datatypes in RDF are a miserable failure. Outside of the core RDF and OWL specs, *not a single* new datatype has been defined that has actually caught on and become popular.)

> However, I'd like to know what you say about implementations that use Literal.getDatatype() or Literal.getDatatypeURI() to do some specific tasks for tagged literals?
> They'll have to change their tests from if(dt==null) {...} to if(dt.equals(RDF.LangString)) {...}.

No. The check if(dt==null) doesn't test for language-tagged strings in RDF 2004. It tests for plain literals. The check for language-tagged strings in RDF 2004 is if(lang!=null) and that still works with the new proposal.

> Can you justify that this is not significant, while code using getLexicalForm() is?

In my proposal, many applications won't require any changes.

Some will require changes.

In the worst-case scenario, if no change is made, "foo"@en would be treated like "foo"^^rdf:langString would have been treated in RDF 2004 (with rdf:langString being an unknown datatype URI). That's still sort of reasonable. It's breakage, but not horrible breakage.

In your proposal, the *default* case (not worst case) would be displaying your name as "Antoine@fr Zimmermann@fr". Every single string with a language tag, in every application, would be broken. That's horrible breakage.


Received on Wednesday, 28 September 2011 07:49:23 UTC