Interfederation

[Tom Scavo <>]

Ian, this is very helpful. I will take it as an action item to add an
<mdrpi:PublicationInfo> element to InCommon metadata (which is
independent of this group's charge). I'll let others comment and make
recommendations with respect to the other elements you mentioned. If
others agree, perhaps your recommendations could be included in the
final work products for this subgroup.

Tom

On Wed, Feb 27, 2013 at 12:32 PM, Ian Young 
<>
 wrote:
>
> On 27 Feb 2013, at 13:26, Tom Scavo 
> <>
>  wrote:
>
>> I'm guessing that this subcommittee will recommend full support for MDRPI.
>
> I guess that would depend on what you meant by "full" and "support" ;-)
>
> There is an awful lot of expressive power in MDRPI, but there are really 
> only a couple of things in it that carry most of the value.  The good news 
> is that those few things are really very simple to implement.  Let me just 
> document what we've done in the UK federation to give people a general feel 
> for what I mean.
>
> Every aggregate we publish has a top level <Extensions> containing 
> something like this:
>
> <mdrpi:PublicationInfo creationInstant="2013-02-26T18:08:41Z" 
> publisher="http://ukfederation.org.uk"/>
>
> This has some diagnostic value, but I can't think of any mechanical use 
> cases for it.
>
> The important one is that every entity in every aggregate we publish has an 
> entity-level <Extensions> containing something like this:
>
> <mdrpi:RegistrationInfo registrationAuthority="http://ukfederation.org.uk"/>
>
> The registrationAuthority value depends, of course, on where we got the 
> entity from.  Entities sourced from our friends in Ireland, for example, 
> end up with one of these:
>
> <mdrpi:RegistrationInfo registrationAuthority="http://edugate.heanet.ie"/>
>
> Likewise the channel definition I've written for importing InCommon 
> metadata ends up putting this value in, after consultation with Tom:
>
> <mdrpi:RegistrationInfo registrationAuthority="https://incommon.org"/>
>
> The important thing is that any consumer of any of the metadata we publish 
> can tell who registered each entity, which gives them a handle to which 
> they can think about applying policy.  We do the work required to ensure 
> that value is accurate: for example, the process for handling a federation 
> partner is to establish the expected value for registrationAuthority, 
> *default* to that if no <RegistrationInfo> is present, and then *check* 
> that any <RegistrationInfo> now present contains the expected value.  So, 
> for example, if Edugate start putting <RegistrationInfo> into their entity 
> metadata, the defaulting won't take place and we'll pass on any additional 
> details they provide; but that doesn't mean that they can pass through a 
> claim that an entity was actually registered by InCommon (we'd drop that 
> entity entirely from that channel).
>
> As I said at the top, there's a lot more that you *can* say with MDRPI, it 
> just turns out not to be very useful for mechanical.  You can put in a link 
> to your registration practices, but until we can get the ethical concerns 
> around wiring up a lawyer's brain directly to our metadata aggregator 
> resolved (feel free to enter a JIRA ticket) it's pretty unlikely that we'd 
> use that for anything at the federation level.  I'd want to know you 
> performed a decent level of due diligence on entity owners before 
> registering anything I saw, but that's a separate issue; I simply won't do 
> business with anyone who can't pass that test.
>
> At present, the only thing other than registrationAuthority that we 
> actually add to <RegistrationInfo> (and only in cases where we know it) is 
> the optional attribute giving registration date and time:
>
>         <mdrpi:RegistrationInfo 
> registrationAuthority="http://ukfederation.org.uk";
>             registrationInstant="2012-03-27T15:54:52Z"/>
>
> I can't see a real use case for processing that information, though, so we 
> haven't gone to the effort required to backfill it, and it's only available 
> for more recently registered entities.
>
> Bottom line: support for MDRPI at the minimum level described above is 
> extremely valuable for any aggregator, and it turns out to be really easy 
> to do at the registrar level, as it's just a fixed string.  An aggregator 
> can compensate if that's not present, however, so it's not essential that 
> it be done at that level until you're building your own aggregates from 
> multiple sources.  I would strongly recommend that any aggregate which does 
> contain entities registered by multiple registrars always includes basic 
> RegistrationInfo for every entity.
>
>         -- Ian
>