Re: X.500 as document repository
Thomas Johannsen <thomas@aic.co.jp> Wed, 26 February 1992 03:25 UTC
Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa03721; 25 Feb 92 22:25 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa03717; 25 Feb 92 22:25 EST
Received: from JP-GATE.WIDE.AD.JP by bells.cs.ucl.ac.uk with Internet SMTP id <g.01890-0@bells.cs.ucl.ac.uk>; Wed, 26 Feb 1992 02:06:14 +0000
Received: from aic-wide.aic.co.jp by jp-gate.wide.ad.jp (5.65+1.6W/2.8Wb-jp-gate/1.2) with SMTP id AA13235; Wed, 26 Feb 92 11:06:34 JST
Received: from cosmos.aic.co.jp ([150.80.4.1]) by aic-wide.aic.co.jp (4.1/2.7W) id AA15315; Wed, 26 Feb 92 11:06:30 JST
Received: by cosmos.aic.co.jp (4.0/6.4J.6-92/2) id AA10490; Wed, 26 Feb 92 11:06:23 JST
Date: Wed, 26 Feb 1992 11:06:23 -0000
From: Thomas Johannsen <thomas@aic.co.jp>
Return-Path: <thomas@aic.co.jp>
Message-Id: <9202260206.AA10490@cosmos.aic.co.jp>
To: osi-ds@cs.ucl.ac.uk
Subject: Re: X.500 as document repository
>> Using the X.500 technology to store "pointers" to >> documents is fine, using it as a "file transfer tool" is totally >> inadequate. >> The technology should provide "hints" to another application suited to >> this kind of job (e.g. FTP or FTAM or Z39.50). > >I mostly agree with this. So do I. >In my view, the problem of retrieving information can be divided >into three stages: > > 1. identifying candidate repositories for the > information (documents) > > 2. searching repositories to identify individual > items of information (documents) that would > be of interest > > 3. delivering the information (documents) to the > end user. > >I believe X.500 is the perfect technology for 1., and has some >limited use for 2. It is completely inadequate for 3. Unfortunately, the first point is not so important for the user if he is given access to "global" search operations for attributes of interest. So coming to your second point, I learnt from your paper what you are aiming at. I would describe the problem as follows: Once you know *what* you are looking for, it (X.500) works fine. Let's say we are looking for a certain book entitled "Some Title" and written by "A.B. Cde" we should get a result (entry) from the Directory containing more attributes (like publisher, keywords, provider <access>). We certainly get a problem with browsing information using inadequate attribute patterns (list limits, network load...). But perhaps there is a possibility to return some kind of pointer to the user indicating to a "better" repository (where we meet at your point 1). Actually, X.500 hierarchy makes it difficult to use the DIB as general information retrieval system. But I think using descriptive names (+ developing a clever naming strategy) could help. So, what's the meat? Let's have as few as possible restrictions for X.500 applications! Some work should be done to develop a unique information retrieval system which does not have a priori to be based on X.500. Coming back to the discussion's starting point: Provide users with information about documents and how he can get access to them. Thomas
- X.500 as document repository lazear
- Re: X.500 as document repository Sylvain Langlois
- Re: X.500 as document repository yeongw
- Re: X.500 as document repository Sylvain Langlois
- Re: X.500 as document repository Thomas Johannsen
- Re: X.500 as document repository Steve Hardcastle-Kille