--On Friday, March 10, 2006 4:26 PM -0500 Michael Smith <[EMAIL PROTECTED]>
wrote:
On Friday 10 March 2006 15:50, Quanah Gibson-Mount wrote:
As noted, eduPerson may help you.
You may want to browse the Stanford Tree structure for some ideas as
well:
<http://www.stanford.edu/services/directory/trees/>
The City University of New York, which pays my salary,
is an umbrella for seventeen separate campuses (Hunter
College, CCNY, Queens College...). Each of these campuses has
a fair amount of autonomy, but all agree we need a university-wide
directory. EduPerson doesn't seem quite adequate for this problem.
Not only can a person have multiple "affiliations", but we need
to capture what his/her relationship is with each campus: a student
at the graduate center, adjunct faculty at Lehman College, etc.
The Stanford tree contains mutliple "gateway" related attributes, and
I wondered whether these might not be intended to address a similar
problem, though it isn't clear just what they are used for. Is there any
more documentation anywhere on the usage of these attributes? Or
has anyone else on the list confronted a similar problem to ours --
namely the multiple affiliation/multiple institution matrix?
Stanford does not have multiple campuses, particularly (there are a few
remote site, but not really campuses. ;) ). But we do have plenty of
people with multiple affiliations. The Gateway attributes were designed to
store that information in a way that could be parsed by a process for the
data on a persons affiliation, with the affiliation weight determining
which gateway attribute it was stored in. For example, a person's primary
affiliation goes into suGwAffil<whatever>1. Stanford has well defined
rules about affiliation precedence/ordering, so we always know how the
affiliations are ranked.
However, this attribute is currently not particularly useful for
consumption because of the way it was designed (pipe-separated values,
ugh). Our long term goal is to replace the use of gateway affiliation
attributes with the "valsort" attribute in OpenLDAP, which allows us to
weight attributes for sorting purposes (where the weights are hidden to a
normal search, just return order is fixed) and it allows us to use a
control to query the weights for attributes, which can be used to build the
data currently contained in suGwAffil*.
In any case, I think that it would be entirely possible to come up with a
set of attributes and rules to determine affiliation ordering for an
individual, but the more variables thrown in, the more complex it certainly
gets.
You'll notice that what some things contain in Stanford's directory are
currently left blank (like the suLocal* bits). This is because what they
contain depends on the persons primary affiliation. If you are staff, I
think it is your home phone. If you are a student, it is the "home" phone
of your primary non-school residence (i.e., generally the parent's phone),
etc. One of my to-do's is to get the exact rules for the blankly defined
attributes so I can finally put in how they behave.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
