Xref: utzoo comp.protocols.tcp-ip:16570 comp.archives.admin:47 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!think.com!yale.edu!ox.com!msen.com!emv From: emv@msen.com (Ed Vielmetti) Newsgroups: comp.protocols.tcp-ip,comp.archives.admin Subject: Re: building an interstate (data) highway with no roadmaps Message-ID: Date: 18 Jun 91 04:03:49 GMT References: <9106171612.AA01441@mazatzal.merit.edu> Sender: usenet@ox.com (Usenet News Administrator) Organization: MSEN, Inc. Ann Arbor MI Lines: 70 In-Reply-To: clw@MERIT.EDU's message of 17 Jun 91 16:12:42 GMT In article <9106171612.AA01441@mazatzal.merit.edu> clw@MERIT.EDU writes: The Directory Group at MERIT, Chris Weider and Mark Knopper, are starting to address some of these issues. I do think that Directory Services are a good medium term answer, and we're starting to put everything which fits the X.500 philosophy into X.500.... All due respects, Chris, but X.500 doesn't address many of these issues at all, and the ones it does sort of fit into can be more easily addressed with other tools. X.500 Directory services assume a neat, structured, hierarchical name space and a clear line of authority running from the root all the way to the leaves. Indeed, most X.500 services in place on the internet today that work well enough to be useful run off of centrally organized, centrally verified, and bureaucractically administered information -- the campus phone book. For what this is, it's great -- i'm happy that I can finger user@host.edu at any number of sites and get something back. But that is of little relevance to the archives problem. X.500 services are hard to run -- the technology is big, bulky, osified. So the people who are most interested in running it are the "computer center" folks. If you look for the innovative, interesting, and desirable applications that you'd want to find on the net, you'll see that many of them are being done out in the field in departmental computing environments or increasingly in small focused private commercial or non-commercial efforts. There's not a terribly good reason for these two groups to communicate, and so most X.500 projects have much more structure than substance. X.500 services are directory oriented. The data in them is relatively small, of known value, and highly structured. Information about archive sources is just about completely counter to these basic principles. The amount of information about any particular service which you'd like to have on hand can be quite considerable; perhaps at minimum access instructions, but more likely some text describing the service, who its intended audience is, sample output, etc. In addition it would be valuable to keep information on user reactions to the system close to the official provided directory notice; these reviews (a la the michelin guide) are often more valuable than the official propaganda put out by the designer. To search this mass of information, you'll want something much more expressive than the relatively pitiful X.500 directory access tools -- full text searching, at the very minimum, with a way to sensibly deal both with structured data and with more fuzzy matches on "similar" items. X.500 is a holy grail, there's a lot of money which seems to be being thrown at it these days in the hope to make it useful. Good luck, I wish you well. But please, don't try to cram all the world's data into it, because it doesn't all fit. It's a shame that equivalent amounts of effort aren't being spent on developing other protocols more suited to the task. I'm thinking in particular of the Z39.50 implementation in WAIS [*] which holds a lot of potential for providing a reasonable structure for searching and sifting through databases which have rich textual information. Perhaps it's just as well that federal subsidy hasn't intruded here and clouded people's judgments on the applicability of a particular technology to a certain task. -- Edward Vielmetti, MSEN Inc. moderator, comp.archives emv@msen.com "often those with the power to appoint will be on one side of a controversial issue and find it convenient to use their opponent's momentary stridency as a pretext to squelch them" [*] think.com:/public/wais/, also quake.think.com:/pub/wais/