Re: X.500 as document repository

Thomas Johannsen <> Wed, 26 February 1992 03:25 UTC

Received: from by NRI.NRI.Reston.VA.US id aa03721; 25 Feb 92 22:25 EST
Received: from by NRI.NRI.Reston.VA.US id aa03717; 25 Feb 92 22:25 EST
Received: from JP-GATE.WIDE.AD.JP by with Internet SMTP id <>; Wed, 26 Feb 1992 02:06:14 +0000
Received: from by (5.65+1.6W/2.8Wb-jp-gate/1.2) with SMTP id AA13235; Wed, 26 Feb 92 11:06:34 JST
Received: from ([]) by (4.1/2.7W) id AA15315; Wed, 26 Feb 92 11:06:30 JST
Received: by (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 <>
Return-Path: <>
Message-Id: <>
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.