- From: Sebastian Hammer <quinn@indexdata.dk>
- Date: Fri, 22 Feb 2002 15:55:38 +0100
- To: www-zig@w3.org
Ok, >I would be interested in yhearing your reservations - my own thoughts on >this service is that its not a bad idea but also not terribly useful To recap for those who weren't there, the discussion began like this... It's too bad that there's no easy way to find useful servers, and information about them, other than the couple of semi-manually maintained lists offered by different companies. Explain (classic/lite/cherry/whatever) will theoretically provide useful metadata about a server, including its search fields, content description, etc.. but how do we *find* the servers? Why can't we go to Google and find the right server to answer our query, for instance. The answer was: Google and virtually any other automatic web-harvester works by crawling around from focument to document, following the hyperlinks to dicsover new resources. Why can't we do that for Z39.50 servers? Because they don't point at eachother. And then the big question: Well, why don't we *make* them point at eachother. Thus was born the "Friends & Neighbours service", which would allow any Z39.50 server, on request, to return a list of other targets relevant to it, sympathetic to it, or just plain known to it. Theoretically, at least, it would not be necessary to provide anything other than host/port coordinates for your friends and neighbours, because they would be able to provide their own, up-to-date metadata about themselves using Explain (or whatever). A lot of us actually got really enthusiastic about this, and there was an almost giddy atmosphere in the room at the time (although that may also have been due to oxygen deprivation on the last day of the meeting). But after I came home from the meeting, my main misgiving popped up again... the web-like simplicity of the F&N model was deceptively appealing, but let's not forget that the hyperlinks connecting web-documents are an intrinsic part of the web itself. It wouldn't be the web without them, and it is in every document author's natural interest to provide interesting, up-to-date links in his documents (well, kind of). There is a natural business case for people to maintain the hyperlinks that are the fodder of web-crawlers like Google. Take the proposed F&N service, now. What is the business case for a server owner to implement F&N, much less keep an up-to-date list of other servers? Exactly zero. By definition, he already knows his friends and neighbours. It may be that national agencies (like the LOC) might see a point in offering a F&N service as part of their Z server... but surely the average library or public office could care less. The result would very easily be a few sparsely populated islands of servers grouped by project, consortium, or software base which point to eachother -- sometimes. There'd quikly be a whole host of dead links and worse, links to irrelevant servers or test systems. So... I agree with your analysis... it's not a bad idea, but not very useful... and, I would contest, not worth our time to design, much less implement. So what COULD work? Well, I see at least two different sources of reliable target databases with varying levels of quality. One, national bodies interested in library interoperability (something for which there *is* a business case) have an interest in maintaining up-to-date lists of important Z39.50 servers. Second, companies like ourselves and BookWhere have an interest in maintaining lists to serve our own needs, or those of our clients. Three ("I see at least *three* different sources!"), consortia and development projects, maybe even LIS vendors have an interest in providing these lists. So there are in fact a large number of lists to draw on. What I'd like to consider is whether it would be feasible to build a structure in which these lists could be merged or cross-searched... one of the key elements, surely, would be a good schema for describing targets, second would be some mechanism for organising a virtual union catalogue (Z39.50, LDAP, OAI are readily available technologies that come to mind). --Sebastian At 08:20 22-02-2002 -0600, Mark Needleman - DRA wrote: >Sebastian > >I would be interested in yhearing your reservations - my own thoughts on >this service is that its not a bad idea but also not terribly useful >unless there is some mechanism to include enough information about the >neighbor servers so that the client can make some intelligent decisions >about whether its useful to go to them - and then the question becomes >what is enough inforation before we just encode all of explain in those >returned records > >mark > > >On Fri, 22 Feb 2002, Sebastian Hammer wrote: > > > At 12:43 22-02-2002 +0000, Robert Sanderson wrote: > > > > >To go back to the original idea, what is needed is actually an explain > > >harvester/cross searcher so there's one server to go to that can find > > >others based on their explain information. > > > > Mark Hinnebusch asked me this in response to my original mail, so I'll > pass > > it on... > > > > Would this be the "friends and neighbours" service that was discussed with > > some enthusiasm at a meeting a year or so ago? The idea was that a server > > would be able to return a list of "friends and neighbours", for instance, > > other members of its consortium, other national servers, etc. At that > time, > > Explain was unpopular, so the idea was to do it in an XML structure > > returned on the Init, as I recall. > > > > As popular as the idea seemed at the time, I have developed my own > > reservations about this, but what do others think? > > > > --Sebastian > > -- > > Sebastian Hammer, Index Data <http://www.indexdata.dk/> > > Ph: +45 3341 0100, Fax: +45 3341 0101 > > > > -- Sebastian Hammer, Index Data <http://www.indexdata.dk/> Ph: +45 3341 0100, Fax: +45 3341 0101
Received on Friday, 22 February 2002 09:55:21 UTC