reliable-links.html 3.91 KB
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict Level 1//EN">
 <HTML>
 <HEAD>
   <TITLE>Link Reliability - Why URNs are Not the Answer</TITLE>
 </HEAD>
 
<BODY BGCOLOR="#ffffff" TEXT="#000000">

 <P>
 <A HREF="../"><IMG BORDER="0" SRC="../Icons/WWW/w3c_home" ALT="W3C" WIDTH="72" HEIGHT="48"
     BORDER="0"></A>
 <A HREF="./"><IMG BORDER="0" SRC="../Icons/WWW/propagation_48x48" ALT="Propagation"
     WIDTH="48" HEIGHT="48" BORDER="0"></A>
 <H1>
   Link Reliability - Why URNs are Not the Answer
 </H1>
 <P>
 We all hate broken links. Some folks have said
 "<A HREF="../Addressing/#URL">URL</A>s are broken. We need
 <A HREF="../Addressing/#URN">URN</A>s. URNs will solve the problem of broken
 links." I doubt it.
 <P>
 URNs will play an important role in publishing on the web (along with copyright
 enforcement mechanisms, payment mechanisms, etc. see
 <A href="../Addressing/citations#URN">URLs as catalog numbers</A>) but I
 doubt they will increase <A HREF="../Glossary#reliability">reliability</A>
 (or quality of service) for the vast majority of web links, because URNs
 will impose administrative overhead (e.g. registration, digital signatures),
 or at least work-flow restrictions (e.g. once you've made a document available
 under a URN, you can never change it). (see
 <A HREF="../Addressing/#STANF">[STANF] </A>for an excellent discussion)
 <P>
 I suspect there are propogation techniques that will increase reliability
 without the cost of human intervention. There are ways to distribute replicas
 of <A HREF="../Glossary#resources">resources</A> such that
 <A HREF="../Glossary#availability">availability </A>will be sufficiently
 high and latency sufficiently low.
 
 <p>Another mechanism to increase reliability is <a
 href="../Addressing/auto-update">automated link maintenance</a> for
 referential integrity.
 
 <H2>
   Defining Link Reliability
 </H2>
 <P>
 If we look at link traversal as a case of the
 <A HREF="../Glossary#I-R">information retrieval problem</A>, we can start
 to measure reliability only after we've defined "success."
 <P>
 Successful link traversal generally means finding a resource with perfect
 <A HREF="../Glossary#precision">precision</A> and
 <A HREF="../Glossary#recall">recall</A>, and retrieving an
 <A HREF="../Glossary#authentic">authentic</A> representation of the resource
 in a timely fashion, i.e. with sufficiently low
 <A HREF="../Glossary#latency">latency</A>.
 <P>
 If a resource is <A HREF="../Glossary#replica">replicated </A>to increase
 availability or decrease bandwidth consumption, it is important that the
 various replicas are in sync (or close -- some applications may be willing
 to accept out of date information some small percentage of the time.)
 <P>
 @@Replication mechanisms are complicated by the need to support access control
 and tracking policies.
 <H2>
   More Information
 </H2>
 <DL>
   <DT>
     <A HREF=http://www.w3.org/team/WWW/Addressing/citations.html>Catalog
     Searching</A>
   <DD>
     for info on resource description and discovery, seen as a knowledge
     representation and query problem
   <DT>
     <A HREF="http://www.w3.org/hypertext/WWW/Addressing/Addressing.html">Addressing
     and names</A>
   <DD>
     Tim BL's original design notes
   <DT>
     <A HREF=http://www.w3.org/team/WWW/People/Connolly/drafts/formalism.html>A
     Formalism for Internet Information References</A>
   <DD>
     out-of-date draft
   <DT>
     <A HREF=http://www.w3.org/team/WWW/People/Connolly/drafts/link-rpc.html>Toward
     Reliable, Interoperable Links</A>
   <DD>
     out-of-date draft
   <DT>
     <A HREF="../Addressing/url_test/">URI test suite</A>
   <DD>
     March 16, 1994: The expanded release of a URI test suite (including a fairly
     complete grammar for URI's that includes ways to represent URLs and URIs)
 </DL>
 <P>
   <HR>
 <ADDRESS>
   <A HREF="../People/Connolly/">Connolly</A><BR>
   @(#) $Id: reliable-links.html,v 1.7 1997/08/09 17:55:05 fillault Exp $
 </ADDRESS>
 </BODY></HTML>