Re: Namespace names: a modification of a semi-serious proposal

On Sat, 27 May 2000, Simon St.Laurent wrote:
> >Use a 256 bit hash value; almost always gaurenteed to 
> >be unique and taking very little storage.
> 
> Retrieving resources to calculate those hash could still be a barrier.

Yes, in those cases where there is limited bandwith
or no bandwith, then a local-registry would be
required for "http:" namespaces.  For this local-registry 
case I can think of three scenerios:

1.  The processor is a hand-held limited scope
    device.  In this case, the device will only
    be able to accept a finite and pre-determined
    set of namespaces anyway; so a fixed registry
    isn't out of the question at all.

2.  Case #1; only that the device is "updateable".
    In this case, the update would contain changes
    to the local registry.

3.  The local-registry is on a full fledged computer.
    In this case, knoweldge of the namespace can
    be filled in by a human, perhaps defaulting
    to the value of the URL target, or it could
    be configured by loading the required text 
    onto a hard drive.
    
Admittedly, this could be somewhat irritating
for some use cases.  However, in general, the
method solves the problems presented and does
so in a way which is consistent with the behavior
of the "semantic-web". 

Afterall, can you tell me if "http://clarkevans.com/"
and "http://www.clarkevans.com" are returing the
same resource without being connected to the 
internet or having a cache?

> >If it does not exist; then, throw a warning error
> >and fall back to a byte-by-byte comparison of the URI.
> 
> It'd be a lot easier to just stick with the byte-by-byte.

Yes, I agree.  However, this violates our "semantic-web".

> > Let them use "data:" ... nothing is forcing 
> > them to use "http:" for their namespace names.
> 
> Except for the practices of everyone else with more bandwidth than
> kindness.  This is about reading, not just writing.

First, this "read" pain is short term, it may have 
a legacy, but it won't last that long.  Also, the
http:// response could return the same information
as found following "data:" ... making for a nice 
transition.  

Second, for those without bandwith, a local-registry
or similar solution will work.  Not that it is ideal;
but is this really a show stopper?

Best,

Clark

Received on Saturday, 27 May 2000 23:54:55 UTC