An open discussion list for topics related to the eduGAIN interfederation service.

[Peter Schober <peter.schober AT univie.ac.at>]

* Martin Matthiesen <martin.matthiesen AT csc.fi> [2014-12-01 12:49]:
> > That's precicely what you cannot do, give "employee" a new meaning to
> > mean you want it to.
> 
> I meant employee = staff + faculty. And this is the meaning Swamid
> is using, Leif may correct me here.

You'll also find lecturers/teaching staff/scientists who may not be
employees. Basically you can assume every possible permutation will
exist somewhere, though of course not all of them may make sense to
us.

> > (And "academic staff" sounds like a contradiction in terms to me.)
> 
> Sorry for the sloppy use of "staff", being a controlled word. So I
> could see it working that (according to Swamid [1]) professors,
> lecturers and researchers (="faculty") as well as other personnel of
> the educational institution (="staff") would be eligible to access a
> "Clarin ACA" resource.

Sure. SPs enforcing access control rules for CLARIN ACA ites should
then list any and all acceptable affiliation values (e.g. faculty,
staff, employee), instead of relying on assumed relationships between
those sets (i.e., one "containing" the other).

Note that you've now changed from adding 'academic IDP' as a
requirement to adding 'educational institution', again confirming
Ian's point that you'll likely need both: a classification of
institutions /and/ of subjects.
In contrast to 'academic institutions' or what 'research institiutions'
are the classification of educational institutions is actually a
solved problem, though: http://en.wikipedia.org/wiki/ISCED
Educational institutions could be classified by the ISCED 2011 level
they're offering. This was one proposal for schacHomeOrgType values,
which never got anywhere because people also [or sometimes primarily]
wanted classification of other types of institutions, which I think
you'll find to be the case here as well.

> And of course I (by myself) cannot give any attribute a new meaning,
> but since a lot of organisations have already done so, I'd rather
> clarify the meaning of existing attributes (even risking that some
> organisation needs to do a search and replace) than putting new
> attributes into the mix that might or might not be in use in 5 years
> from now by 30% of IdPs. Here I assume that we all benefit from
> lesser complexity.

Personally I think both approaches are equally doomed (trying yo
change the defintion of widely deployed values, even one little bit
vs. inventing something new which is universally pre-unsupported), but
adding/changing any of the existing controlled vocabulary definitions
is usually not considered possible or desirable by MACE-Dir (if we're
talking about eduPerson specifically), due to those values being
deployed widely, and have been for many years.

I do agree with the sentiment, I just don't think that's a realistic
way forward. Either you accept the fuzziness that comes with the
existing defintions, or you'll have to create a new one and try to get
that deployed. Or something else (there's always a third way :)
-peter