From: Ian Neilson 
Sent: 18 June 2004 13:09
To: 'Tanya Levshina'
Cc: d.p.kelsey@rl.ac.uk; Joni Hahkala; Maria Dimou
Subject: ORGDB API (was RE: Questionnaire_ATLAS_answers)

Tanya,
 
> 
> 1. Do I understand correctly that  CRA will provide the API to query
ORGDB
> database? It will allow to list all the members that are satisfied
certain
> criteria (e.g. have the same last name & email) and return all the
> relevant
> information including orgdbid (Does notion of orgdbid exist for CRA?).

It's not clear to me. Certainly CRA will provide access to query
database (it's ORACLE of LHC) so we might be wise to make sure the
access is wrapped suitably if we want to try to be generic. The critical
technology we don't have (or need from day 1?) and would be complex is a
fuzzy matchMember as below. Whether they do it or we must do it is not
decided but we should have some resources (Karoly) at CERN for this to
coordinate.

> VO admin will perform manual action to match a new user that applied
for
> membership with the ORGDB query result, then if match is found the
user
> becomes VO member and his orgdb id is linked with his DN & CA.

I think Dave felt quite strongly that this approach was best. I still
prefer the user to select but have no religious attachment to such. (but
see just below!)

> BTW, will this be done explicitly by vo admin or user can do it
himself?
> If we
> allow user to do it then we exposed personal information of others. If
> this
> will be done by vo admin it means that we have to pre-staged user
> application
> and notify him later if he has to register with ORGDB first.

This is very good point, it is more complex. I like simplicity and the
data is public already. Maybe we can revisit and persuade Dave to adopt
a user-selection mode. ... Dave?

> 
> 2. I have the following questions:
> 
> 	a. Does existing & valid CERN member register in VO?
> 		I guess he should in order to provide DN & CA and sign
usage
> 
>  rules.

Yes definitely.

> 	b. If a. is true. What should be a minimum information supplied
by
> user?
> 	(The search for the membership will be done based on this
> information)

I would vote for family name and email but the last should be unique?

> 
> 
> 3. This is functionality that is required from CRA based on my
> understanding:
> 
> 	a. matchMember(criteria)
> 		where criteria could include "last name","first name",
> "email",
> 		"institution", ... (see 2.b)
> 	    it returns list of Members that matches this criteria, where
for
> 
>     each member the following information is provided:
> 			personal member's data
> 			member's orgdbid
> 
> 	b. getMember(orgbdid)
> 		returns personal information of the member
> 	c. isValidMember(orgdbid)
> 		returns True/False
> 	d. getInstitutions(VOName)
> 	returns list of institution names relevant to this VO
> 
> I sure that I am missing something

Functionality looks ok. I can't think of anything extra. Implementation
suggestion might be:

orgdbid[]:matchMember(criteria)  # return only list of id's
memberData:getmember(orgdbid)    # or more efficiently for summary work
-
memberData[]:getmember(orgdbid[])

I think there will be some data associated with an institution and query
for such could be useful (but not essential now for registration). But I
guess we could leave if flexible and parallel member query with:

instid[]:matchInstitution(criteria:VOName)  # return list of id's
instData[]:getInstitution(instid[]) 

> 
> 
> Comments are welcome.
> 
> Tanya

Cheers,
Ian