AffiliationDescriptor

[Cantor, Scott]

> So what happens when we combine an AffiliationDescriptor with a metadata-
> driven configuration element? For example:

I don't think it works, we don't chase down the affiliations to find their tags as part of existing EntityAttributes logic. It's possible we could do that, but the main purpose was to support the "group" semantic that's already in the API to extend it to affiliation membership.

It would be a fair amount of work, probably involving some refactoring to make tags "appear" virtually on all an affiliation's members.

What would be nice is to be able to attach a tag with a filter based on a condition/predicate that depended on affiliation, which accomplishes the same end result with less or no code changes, but I don't think that works because of the race condition. The metadata's not in place as a service to be able to use it to feed rules for filtering metadata.

My brain isn't really on this side of the project right now so I don't know what all the implications would be.

The main purpose for this was to allow third party signed metadata statements as an alternative to tagging entities. In other words, instead of InCommon tagging the entities that are part of some certification program, that program just issues a signed AffiliationDescriptor entity listing the entities it certifies.

So it's kind of an alternative to tags, not a way of attaching them virtually. The name of the affiliation is the tag in a sense.

-- Scott