Advanced Campus Services
Information Systems & Technology
Georgia State University
P. O. Box 3968
Atlanta, Georgia 30302-3968
Phone +1 404 463 9685
Email: avandenberg@gsu.edu
Directory Services Project
November 5, 2002
1:00 pm - 2:30pm
Classroom South 514
1. Status research paper (15 minutes)
(see next page)
2. Experiments?
LSA/LSI
Interfaces
SOM
Experts
3. Research opportunities (15 minutes)
4. Semantic Facilitator (TM) (SM) - Status (20 minutes)
interface
LDAP
Data store
clustering
5. Other discussion
Next meeting: Friday November 15, 2002- 1:30-3:00pm??
A typical scenario of our SOM application will be like this:
An LDAP administrator wants to add person related information to the directory.
Using an interactive interface, a query is specified, such as:
objectclass_name like 'collegePerson'
with attributes like 'name,' 'email,' 'phone,' 'college,' 'major,' 'class_level'
This information is used to build a temporary object class definition and our SOM application does clustering work for this temporary object class and all existing object classes.
The results are displayed graphically with a cluster of object classes in the middle of computer screen that contains "Person," "organizationalPerson," "inetOrgPerson" and "collegePerson."
Moving the cursor over the object classes, will display their schema definitions, including each attribute.
Seeing that indeed the other object classes are an appropriate hierarchy of person object classes, but none contain "college," "major" or "class_level," the LDAP administrator clicks the "Add" button.
The "collegePerson" is added to the directory, inheriting attributes from "inetOrgPerson" and its superior object classes, and adding the new attributes "college," "major" and "class_level."
This scenario implies our SOM application should have good generalization capability. That is, when a limited amount of new object class information is added, our SOM map should still be able to cluster these new object classes as well as human experts.