Re: my laziness with literals

Dan Brickley wrote:
>
>> * If you're going to store a language, use something like 
>> info:lang/en/US.
>> * If you're going to store a Java class, use something like 
>> info:lang/com/example/package#Class.
>
> There is a java: URI scheme. This is used for example in ARQ for 
> dynamic  code loading. I don't see a case for using info: instead.

OK, I'm on Dan's side, now.

As I pointed out in my earlier, email, there actually is *no* official 
java: URI scheme, even though some people are using it as if it were. 
That's why I proposed to the OCLC the info namespaces info:java/, 
info:lang/, and info:media/ . But I just received a message from the 
OCLC stating that it doesn't want to approve the "java" identifier 
because it's a service mark; that I'll have to talk to the Library of 
Congress to find out how they want to identify languages in URIs; and 
that I'll have to talk to IANA if I want to represent a MIME type in a 
URI. That's all about as much trouble as simply proposing top-level URI 
schemes to begin with. And everyone here knows how long this will take. 
(Maybe before XHTML 2.0 becomes a recommendation? I'm not holding my 
breath.)

So I'm switching sides. "Official" standards be damned. I'm going to use 
URI schemes of java:, lang: and media:. That gives me:

java:/com/example/package#Class
lang:/en/US
media:/text/plain


>
> It's good to agree on ways of doing these things, but your choices 
> seem a little arbitrary,

Do they seem a little less arbitrary now? ;)

> and not yet widely used.

Looks like I'll be the first. :)

Garret