On Mon, Apr 14, 2003 at 02:00:08PM -0400, Nick Matsakis wrote: > > On Mon, 14 Apr 2003, Kevin Smathers wrote: > > > I think you are actually describing a search problem, not a naming > > problem. > > I specifically wanted to focus on the distributed naming problem, not the > naming authority search problem; If it requires a search, then it isn't a > distributed naming scheme. > > On this list, David suggested one way that two parties can independently > come up with names for a given resource even though they don't have a > network connection or search capability, and that is the MD5 hash of a > collection of bits. This only applies to static resources that are, in > some sense, entirely bits. Still, there are a lot of interesting > resources that could be viewed this way, including audio CDs, DVDs, > PDF-published works and less formally email messages and digital > photographs. Dynamic content and non-digital resources, like the The > Effiel Tower, cannot be named in this way. The main problem that I have with this approach is that I don't consider two files to be the same just because they happen to have the same content. Likewise two facts. A fact, like a file instance, should be able to obtain any content without being accidentally combined with another instance. Imagine how you would implement default constructors, or access controls. > > The names can be relatively arbitrary if you have a way to search for > > the owner of record ... > > While I was throwing out distributed naming as food for though, I think > that in the SIMILE scenarios, naming authority discovery/search is more > important than distributed naming. It seems to me that naming discovery > is just a special case of schema discovery --- "I have a bunch of things > and I want to find a unique but *shared* name for them". The scenario I > envision here would be that of a photographer who wanted to catalog photos > of downtown Boston and needs to find a robust name for "Boston". Perhaps > this scheme would be suggested/enforced by the schema choosen, or perhaps > not. > This is the problem of vocabularies, listed elsewhere in the use case document. -- ======================================================== Kevin Smathers kevin.smathers@hp.com Hewlett-Packard kevin@ank.com Palo Alto Research Lab 1501 Page Mill Rd. 650-857-4477 work M/S 1135 650-852-8186 fax Palo Alto, CA 94304 510-247-1031 home ======================================================== use "Standard::Disclaimer"; carp("This message was printed on 100% recycled bits.");Received on Monday, 14 April 2003 17:58:51 EDT
This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:35:21 EDT