*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Chicago
Brendan Bellina -- Notre Dame
Steve Olshansky -- Internet2
Ann West -- EDUCAUSE/Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

Higher Ed Data Taxonomy

Keith solicited input on whether MACE-Dir has any role in supplementing or supporting institutional metadata for the purposes of InCommon and other production-level Shibboleth federations. This was initially discussed in the context of adding attributes to eduOrg, but Tom observed from a MACE-wide perspective that if someone were interested in looking up a set of schemas utilized by MACE-sponsored working groups, there is no common registry. Is there any value in tracking the whole data model in some sort of single registry? "Even if you leave this stuff in different working groups, can we -- should we -- agree on a way of describing it at a top level?" Tom continued on to suggest that at least registration of data structures using UML models or other structures may be useful. He reasoned that even something like a table would be more valuable than nothing.

Keith wondered whether this is a problem worth thinking about; is it worthwhile to help others understand the spectrum of what MACE has developed for data? As an example, the three projects Shibboleth, Grouper, and Signet are all producing large amounts of schema. Generally, Grouper has a large amount of underlying relational schema, some of which may be difficult to express in a context-independent sense. Signet and Shibboleth are each defining their own sorts of data, including the originally mentioned federation-supporting trust.xml and sites.xml.
In a sense, the attribute-defs namespace that has been reserved under urn:mace:dir is a microcosm of this idea by providing a space under which attributes of multiple sorts, including those that are not LDAP-based, can be enumerated. Addition of a couple of columns providing more information such as a brief description and a link to supporting documentation could help.

Nate saw a different value; by centrally documenting the set of information that is used by various applications, certain similar data may be observed which are sufficiently common to merit inclusion in a higher-level data structure such as eduOrg. Tom agreed, noting that "recognizing that we've done the same thing similarly in two contexts after the fact is too late." Nate didn't believe there would be much use in providing centralized schema to the community, since much of it is application-specific and not of general interest, e.g. .xsd files, but there was no agreement on this.

He was also worried about expressing extremely different types of information in a common way; XML has a certain type of structure, while UML and relational databases have extremely different flows. None of these data types is readily committed to a table or other common expression.

It was also clear that at the present time it doesn't take too long for word to get across MACE. Keith will try to organize a group of people to discuss any immediate implications of the slew of new data definitions for eduOrg in particular, and then generalize lessons learned there to an eventual permanent process.

Globally Unique Group Identifiers

The University of Arizona had use cases at one point for Grouper defining groups that were usable in some sense across organizations. To host tools at Arizona which may be used by people at other institutions could possibly be done by pooling individuals from multiple institutions into a single global group which is then given access.

Perfectly happy saying, "no, there's no need to do anything special in Grouper" to provide for globally unique group names, Tom thought that the current methods that are used to make attributes and information globally unique in interrealm exchanges would be just as useful for Grouper. Keith agreed: "Aha, those look like substrings of URN's, which are universal."

There are other tools for that sort of information transport about a principal, such as Shibboleth, and Tom wants to avoid the need to handle this sort of scenario internally in Grouper. Data may be elevated, shipped around, and dropped into other applications, but the elevation process seemed to be a natural boundary of responsibilities.
Grouper may also support provisioning connectors that perform this transformation in a specialized way for certain content providers or
resources if necessary.