[e2e] a means to an end

David P. Reed dpreed at reed.com
Mon Dec 1 07:55:46 PST 2008


Your presumption that information is a matter of copies, and that "sole 
copy" is a well-defined term, suggests a fundamental difference in our 
understanding of the word "information".

Had you used the word "datum" or "message" (two human constructed 
concepts), I might agree.  But "information" is not a synonym for either 
term.  Both are *representations* or *instantiations* of information.

A piece of paper with a number printed on it may be the "sole instance" 
of a printed piece of paper with that particular representation of 
information.   But if that number represents (say) "the total net value 
of my bank account on Dec. 1 2008", it is not at all the only "copy" of 

Information typically exists independent of form or representation.   It 
is a constructed, calculated, computed thing.  It doesn't exist 
independently, nor does it exist in sole form.

Yes, I could agree with you that if information were forced to exist in 
"single copy" form, it would require some complex and amazing procedure 
to copy that piece of information into another place.  But, once copied, 
it would be smeared across half the universe.  (or alternatively you 
could decide, since "place" is really not a very easy-to-define term, 
that the information is still in one place, but the universe has now 
collapsed significantly, because all the places "containing" (whatever 
that means) the information would be "the same place").

But independent of that: why is any information system designed to have 
data in a "sole copy"?   Van asks this question, and he is wise to ask 
this question.  Most computer systems work by having vast numbers of 
copies of data. We constantly see most information representations used 
in computation in the form of cached data.

It seems to me that it is a pure fetish, perhaps conditioned by 
training, to posit that most information is represented by single 
copies.  That way lies "brittle" failure-prone engineering.

Let a thousand representations bloom.  Many of them will be copies of a 
datum.  Others will be computable recovery algorithms - some of which 
invent an abstraction called "location".   But even that abstraction 
called location is not a "place" in the sense of a 4 dimensional spatial 
metric based coordinate system.   I address a piece of paper by its 
title, not its current location in the file folder on someone's desk.

Craig Partridge wrote:
>> Our dear friend, Van Jacobsen, has decided that layering "where" under 
>> "what" with regard to data is neither necessary, nor a good idea.
>> I agree: confusing the container with the information it happens to hold 
>> is a layer violation.  Information is not bound to place, nor is there a 
>> primary instance.  Information is place-free, and perhaps the idea that 
>> there must be a "place" where it "is" is an idea whose time should pass, 
>> and the purveyors of that idea as a holy writ (the OSI layering) retired 
>> to play golf.
> Hi Dave:
> Much as I'd like to believe this particular theory (as it is nice, clean
> and pretty), practical considerations suggest we're not there.
> I've talked with some of the folks working on information and seeking
> to make information place-free, and the answer, so far, that I've gotten
> is that you get part-way there.  If the information is popular or
> "nearby" then there are mechanisms that can be viewed as place-free (and
> a good thing -- it means that the more popular a piece of information is,
> the easier to get easily and perhaps from somewhere locally).
> But if you ask about retrieving an uncommon piece of information then
> you discover "location" crawls out from under the covers.  That is,
> if you ask the question "where do I find the sole copy of item X", you
> learn that somewhere hidden in the name of X is a location -- perhaps
> of X or perhaps of a rendezvous server that knows where X is -- but
> there's the location of something buried in there.
> Thanks!
> Craig

More information about the end2end-interest mailing list