Re: ISSUE-12 On languages and datatypes

On Wed, Jun 8, 2011 at 10:04 PM, Pat Hayes <phayes@ihmc.us> wrote:
>
> > It is pretty simple in the serialisers and parsers to treat @en or
> > xml:lang="en" as syntactic sugar, a placeholder for datatypes with a
> > well-known prefix.
>
> This sounds harder than several other 'pretty simple' ideas that were
> rejected as way too complicated. I don't like anything that requires going
> inside a URI to extract pieces of it that carry significant meaning. (Didn't
> TIm B-L have a rant about the evils of this somewhere?)
>

+1

URIs, when used as identifiers, should be opaque. I've been guilty of
violating this principle myself by extracting meaning from URIs in my own
projects, and in each case I've cursed myself several months down the road
for being so lazy and short-sighted.

I personally don't care much one way or the other about language tags, but
this part really bothers me about the langtags-as-datatypes proposal. I
expect that people working with languages want the RFC5646 language tag, not
a datatype URI. Right now we accommodate this by making the tag available
directly as part of the abstract syntax, and I don't think we should bury
that inside a datatype URI.

In theory one could model all of the thousands of language tags, mapping
each datatype URI (rdflang:en, rdflang:fr, ...) to its corresponding tag
("en", "fr", ...) but in practice, people will just extract the tag from the
URI instead of having built-in knowledge of all the possible language tags.
 That sounds like an invitation for trouble down the line; I'm immediately
reminded of rdf:_1, rdf:_2, ...

-Alex