W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2007

Re: identifier to use

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Thu, 23 Aug 2007 15:58:41 +0100
Message-Id: <CFDFA128-37AC-443D-B18A-D0AFA8CD3113@cs.man.ac.uk>
Cc: Eric Jain <Eric.Jain@isb-sib.ch>, Hilmar Lapp <hlapp@duke.edu>, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
To: Phillip Lord <phillip.lord@newcastle.ac.uk>

On 23 Aug 2007, at 14:12, Phillip Lord wrote:

>>>>>> "EJ" == Eric Jain <Eric.Jain@isb-sib.ch> writes:
>   EJ> Note that any other name-based registration system could run  
> into
>   EJ> trouble, too: Let's say UniProt lost a trademark suite and  
> was forced to
>   EJ> change its name to something else, I assume that wouldn't be  
> good for
>   EJ> "location independent" identifiers such as  
> urn:bm:uniprot:P12345...
> If you loose a trademark

Trademark *suit*. I.e., you are infringing on someone else's trademark.

> and have to stop using identifiers with a "uniprot"
> in them, then any system which uses a alphabetical ID is stuffed.  
> Numbers
> would be okay, cause you can't trademark numbers. The law is an ass.

If the use is widespread for any length of time it's highly unlikely  
(at least under US law, but I think this is fairly general) that  
someone could enforce a trademark against you. The other solution, of  
course, is to use fairly generic terms.

Isn't there a pretty strong disanalogy here? With normal HTTP uris,  
when the domain name gets poached, the poacher can screw everyone up  
with a flick of a switch (if everyone is relying on normal http  
resolution). With these other problems, the turning of the screw is  
slower and more indirect and just generally harder. (Of course, you  
can recover some of that by layering over http in the ways described,  
but c'mon, if it breaks when you pop it into a normal browser then  
all we are arguing about is whether "http" at the beginning is cool.)

Received on Thursday, 23 August 2007 14:57:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:29 UTC