W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2006

Re: BioRDF: URI Best Practices

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Mon, 24 Jul 2006 15:55:04 -0400
Message-Id: <A9A00E41-6C6B-4EDE-8975-74CC8E023A88@gmail.com>
Cc: public-semweb-lifesci@w3.org
To: Sean Martin <sjmm@us.ibm.com>


On Jul 24, 2006, at 9:55 AM, Sean Martin wrote:

>
> Hi Alan,
>
> public-semweb-lifesci-request@w3.org wrote on 07/23/2006 11:51:35 PM:
>
> Are you suggesting that programs parse URIs to see if they contain  
> the ASCII string "static"? If so, how would ones program know the  
> difference from any of these links?[1] I can see us heading towards  
> heated discussions about URI opacity ;-)

Don't they already parse URIs to extract the protocol to figure out  
what to do at the network level?  I don't buy the URI opacity  
argument. If there is a contract between user and provider that the   
URI is specified to have some extractable content in its form then so  
be it. What I think is unacceptable is to have to guess what the URL  
string means. But to "know" that it means something, because we have  
agreed that it is so is another story.

1.
> This is true, but in the same way as LSIDs requires new  
> infrastructure (a new protocol) to be deployed in clients and  
> proxies since two different kinds of behavior are required, one for  
> these new "static" URLs and one for everything else. As I posted  
> earlier, the infrastructure of the http system that works today is  
> exactly that part which is already used by the LSID resolution  
> scheme. What does not work today is the parts added by the LSID  
> scheme to compensate.
2.
> If you donít have the "contract" with the name, it is far more  
> complicated to deal with objects separated from their policies.  
> LSIDs only ever have one policy for the data bits they name which  
> makes the rules simple. You also donít have anyone creating LSIDs  
> by accident.

There are two parts of the LSID scheme that I see. The stuff in 1,  
having to do with resolving, and the stuff in 2. that have to do with  
contract. I can't see how the former is inextricably tied with the  
latter. I want to keep the insight of the  latter, and dispense with  
what *might* be unnecessary technical aspects of the former.

> [1] http://www.google.com/search? 
> as_q=static&num=100&hl=en&btnG=Google 
> +Search&as_epq=&as_oq=&as_eq=&lr=&as_ft=i&as_filetype=&as_qdr=all&as_n 
> lo=&as_nhi=&as_occt=url&as_dt=i&as_sitesearch=&as_rights=&safe=images

The query finds anything with static anywhere in the string, not urls  
that *end* in the string ".static".   In any case, what would the  
conseqeuence of some accidental .static uris, if we in the community  
specified what they should be fore. I can mint fake or wrong lsids  
just as easily...

Best,
Alan

(enjoying the back and forth :)
Received on Monday, 24 July 2006 19:55:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT