yak
[Top] [All Lists]

[yak@collab] Re: structural addressing inventor and Purple analogy

To: yak@xxxxxxxxxxxxxxxxxxx
From: John Sechrest <sechrest@xxxxxxxx>
Date: Sun, 07 Dec 2003 10:22:11 -0800
Message-id: <200312071822.hB7IMBq14177@jas.peak.org>

Sam Hunting <shunting@etopicality.com> writes:    (01)

 <snip>
 % Another question: Doesn't this addressing scheme need a protocal on the
 % front of it, so we know what it means (I would find this preferable to,
 % for example, an email protocal (see patent discussion)).    (02)

 No. 
 Emphatically no.    (03)

 It should not be the case that the means of accessing the name
 is bound to the name.     (04)

 It is truely a problem that we have references in documents which
 can not abstract out the method of access.    (05)

 Do I really care if I get the named object via ftp, ssh, http, email,
 disk file access?    (06)

 Do I even care if I get the file from the original spot?    (07)

 In fact, for more cases, I don't care. All I want is psalm 23:4    (08)

 I don't care which bible I get it from. Just the one that is 
 most handy.     (09)

 If I have it on disk, use that one. If I have it in my 
 proxy cache, use that one.     (010)

 Let the software figure it out..    (011)

 That is not to say that I don't want the option to say that
 I want a very specific one, with a very specific protocol to get it.
 However, we want the NameOfAnObject to be universal without 
 method of access denoted. Let the software have a configuration 
 file that outlines the possible paths to get something. And then 
 let the software do it.     (012)

 In this way, as we change our methods of access, our documents
 do not need to be regroomed for the new methods.     (013)








--- tail of message ----
Sam Hunting <shunting@etopicality.com> writes:
 % > >
 % > >
 % > >   We need to have a way to say: Blueoxen:yak:34:1
 % > >   And get to it rapidly, in a way that is human parsable.
 % > >
 % > >
 % > That strikes me as brilliant!
 % 
 % Simplicity is hard....
 % 
 % Let me riff on this just a little and hopefully not break the beauty of
 % it.
 % 
 % I like this "Bible Style" addressing (34:1 == "Chapter 34, verse 1"). I'm
 % an old-timer from the markup ((SG|HT|X)ML) community, and one of the core
 % values is: "Do what has worked for thousands of years." (This applies to
 % markup itself, since the "<"s are really just glorified punctuation).
 % 
 % So, since "chapter and verse" addressing (maybe less controversial as a
 % name than "Bible" style) has worked for thousands of years to help humans
 % find subjects in text that are of interest to them, it makes sense to
 % adopt it!
 % 
 % [Maybe "chapter and verse" is a good name for the style, too, since there
 % is a subliminal suggestion of "give chapter and verse, a cliche that
 % means, essentially, "prove it from the text!", a core value for many,
 % whether on religious or secular subjects.]
 % 
 % [See Knuth's book on John 3:16 for a discussion of stratified sampling in
 % relation to "chapter and verse" addressing.]
 % 
 % However, "chapter and verse"-style addressing really works (I argue) for
 % humans because it can incorporate names -- the style is
 % book/chapter/verse: So "Luke 34:1", which makes it a lot easier to find. I
 % think (still using the Bible analogy) that Blueoxen:yak is the root, the
 % Bible as a whole, and that another human-readable discriminator (the
 % "book", like "Luke") would make the address easier to remember and use.
 % 
 % So Blueoxen:yak:addressing:34:1
 % 
 % Having introduced the notion of names, though, the notion of synonyms
 % immediately crops up.
 % 
 % Suppose I have "refactored" my text so that the material at :34:1 can be
 % arrived at along several paths. (The Bible here -- which I introduce only
 % as a text that has been the object of thousands of years of usage and
 % study AND NOT FOR ANY OTHER PURPOSE -- has what is known as the "synoptic
 % gospels," which implement, essentially, transclusion.
 % 
 % Is it important that the addressing scheme (a tree) reflect the
 % (potential) complete structure of the text (a graph), whereby
 % 
 %    Blueoxen:yak:addressing:34:1
 % 
 % and
 % 
 %    Blueoxen:yak:purplenumbers:48:9
 % 
 % address the same chunk of text?
 % 
 % Another question: Doesn't this addressing scheme need a protocal on the
 % front of it, so we know what it means (I would find this preferable to,
 % for example, an email protocal (see patent discussion)).
 % 
 % So:
 % 
 %    cvpn://Blueoxen:yak:addressing:34.1
 % 
 % where:
 % 
 %    cvpn == Chapter Verse (to) Purple Number ...
 % 
 % Serious? Maybe... Maybe some protocol and addresing experts can speak
 % up....
 % 
 % 
 % Sam Hunting
 % eTopicality, Inc.
 % 
 % ---------------------------------------------------------------------------
 % Co-editor:  ISO Reference Model for Topic Maps
 %   Topic map consulting and training: www.etopicality.com
 % Free open source topic map tools:  www.gooseworks.org
 %   XML Topic Maps: Creating and Using Topic Maps for the Web.
 % Addison-Wesley, ISBN 0-201-74960-2.
 % ---------------------------------------------------------------------------
 % 
 % -- 
 % This message is archived at:
 % 
 % 
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=Pine.LNX.4.58.0312071154440.11864@www1.martnet.com    (014)

-----
John Sechrest          .         Helping people use
                        .           computers and the Internet
                          .            more effectively
                             .                      
                                 .       Internet: sechrest@peak.org
                                      .   
                                              . http://www.peak.org/~sechrest    (015)

-- 
This message is archived at:    (016)

http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=200312071822.hB7IMBq14177@jas.peak.org    (017)
<Prev in Thread] Current Thread [Next in Thread>