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

RE: BioRDF: URI Best Practices

From: Miller, Michael D (Rosetta) <Michael_Miller@Rosettabio.com>
Date: Fri, 21 Jul 2006 08:33:34 -0700
To: "Sean Martin" <sjmm@us.ibm.com>, public-semweb-lifesci@w3.org
Message-ID: <E1G3x0e-0003vy-7S@aji.w3.org>
Hi All,
 
(from Sean)
 
"The issues of broken links is a difficult one because once the primary
source at a particular location disappears you have nothing left to go
on to find a copy of the thing named besides what you can find in the
WayBack machine or perhaps a Google cache."
 
A great example of this is the www.i3c.org link where the primary work
on implementing the LSID specification was documented originally.
 
cheers,
Michael
 
Michael Miller 
Lead Software Developer 
Rosetta Biosoftware Business Unit 
www.rosettabio.com 

	-----Original Message-----
	From: public-semweb-lifesci-request@w3.org
[mailto:public-semweb-lifesci-request@w3.org] On Behalf Of Sean Martin
	Sent: Friday, July 21, 2006 8:10 AM
	To: public-semweb-lifesci@w3.org
	Subject: Re: BioRDF: URI Best Practices
	
	

	Hi Alan, 
	
	> So my proposal suggests a class that defines ways of
transforming the  
	> URI you find in a SW document into URLs that get specific
types of  
	> information. The fact that a transform to URL is provided
means you get  
	> the transport (because it is part of the transformed URL).
Different  
	> properties of the class let you retrieve different patterns
for  
	> different sorts of information (1.). The representation 2., is
not  
	> explicitly represented, it should instead be part of the
definitions of  
	> the properties. We typically want to know *before* we
dereference, what  
	> we would get back. 
	
	> There's more to elaborate about such a proposal and details to
work  
	> out, but I think, for instance, that it can handle the LSID
use cases.
	> 
	
	This sounds interesting. Please could you elaborate a little so
that we can think it through to see what exactly it does address and
what it would entail. It seems to me some of it may well work in the
situations where the web is current and you actually have a SW document
(an LSID is also intended as an persistent independent reference which
can be used as the key to a 3rd party annotation for example), but as a
long term naming/dereferencing solution it breaks down as the web
backing it ages and bit rot sets in. 
	
	Perhaps this is one of the key problems with using URLs as names
for things that have a digital existence. The issues of broken links is
a difficult one because once the primary source at a particular location
disappears you have nothing left to go on to find a copy of the thing
named besides what you can find in the WayBack machine or perhaps a
Google cache. As I suggested in my last post, have a look at your emails
from a year or two back and see what percentage of URL links still work.
The fact is that organizations change direction, people move, machines
break or are reorganized and so too does the web that echoes this.  I
have always found that the web reflecting what is current is usually ok,
but the web reflecting the past state of things is much much less so. Of
course sometimes it is even hard to figure out what is actually current
too! Unfortunately repeatable science and of course legal obligations
require us to have decent answers here too, or am I missing something? 
	
	Kindest regards, Sean 
	
	
	-- 
	Sean Martin 
	IBM Corp
Received on Friday, 21 July 2006 15:34:07 GMT

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