Re: root knowledge

pays@faugeres.inria.fr Fri, 08 May 1992 16:50 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa04937; 8 May 92 12:50 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa26914; 8 May 92 12:56 EDT
Received: from bells.cs.ucl.ac.uk by NRI.Reston.VA.US id aa26896; 8 May 92 12:56 EDT
Via: mhs-relay.ac.uk; Fri, 8 May 1992 10:03:14 +0100
X400-Received: by mta mhs-relay.ac.uk in /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Fri, 8 May 1992 10:02:52 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; Relayed; Fri, 8 May 1992 10:02:41 +0100
Date: Fri, 08 May 1992 11:02:41 +0200
X400-Originator: pays@faugeres.inria.fr
X400-MTS-Identifier: [/PRMD=inria/ADMD=atlas/C=FR/; 705315761@faugeres.inria.fr]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: root know...
From: pays@faugeres.inria.fr
Message-ID: <705315761.9276.0@faugeres.inria.fr>
To: c.robbins@xtel.co.uk
Cc: Paul-Andre.Pays@faugeres.inria.fr, S.Kille@cs.ucl.ac.uk, osi-ds@cs.ucl.ac.uk
Subject: Re: root knowledge

>
>
> This may be a simplistic response, and I may have missed some of the
> points you are making.  However, why can't the X.500 protocols
> themselves and some caching be used to obtain the knowledge required?

Sorry but I have diffculties understanding your point.
It comes probably from the different backgrounds, probably
of my limited knowledge but I somehow got the feeling that we are
not speaking about the same thins or same issues.

My message was not preventing to use the X.500 protocols and even the
second level was advocating for this, just by promoting a
representation of knowledge "unviversaly accepted" and being in the
DIT.
I don't quite understand what caching is doing there, and I would
certainly like not to mix things that are of different nature
knowledge representation is one thing corresponding to the X.500 model
and concepts whereas caching is a local mechanism.


>
> Taking c=GB for example, from the DIT (or local knowledge if you
> like), you can establish the controlling DSA is one called "Inca Dove"

Please tell me how I can establish that, it is not at all obvious to
me.
Such an assumption seems to me tied to the choice to have for
each non-leaf-object attributes about "controlling" DSA.
To my knowledge this is a QUIPU choice, probably a good one, but by no
way a standard

Similarly are you Colin able to get equivalent information from
a Pizarro DSA? Maybe I am wrong, but I suspect you rely on EDBInfo
which is not part of the standard, which I have no tool to deal
with...
Moreover my point was that EDB is mixing two separate things
   . knowledge representation
   . a QUIPU specific performance mechanism
it is the reason why it seems not to be the right choice for
universal knowledge representation.

> Why not bind to this DSA (DAP or DSP), and issue a request of the form:
>
> subtree search baseobject:			 c=GB
> 	       filter:				 objectclass=organization
> 	       service control options:		 chainingProhibited
>

Once again I think you are jst mixing a method to reach a certain
goal (ie. algorithms) with what I am trying to reach: a standardized
knowledge representation that you probably take too much for granted
as a QUIPU developper.
Additionaly your model is relying on a given schema or type of use.
Why search for Organisation if what I want to use the directory for
are not organizations or org dependant objects?
How do you know that org will appear under C=GB or say C=US
rather than uder a region? I am not convinced at all for
general use by your approach. But the point in my mind
is still that we are not dealing with the same issue.
>
>
I would really the discussion be centered (even eventualy to prove me
I am wrong) around my original question: is it wise, is it useful,
is it feasible to have a "common logical knowledge representation"
which can be presented by every DSA? and if so, what should be the
best representation?
[[Other aspects are secondary: once a logical representation is aggreed
upon, it will be easy to have a common textual representation
of it. And this textual representation might be used as a
interim solution to exchange information betwee heterogeneous
implementations. You have to be conscious that today
the only solution is "hand-made" transfer, and that because of
different implementation model this is extremely awkward.]]

Regards,

-- PAP