I2: Background

Posted by Michael Giarlo on May 19, 2009

[Series]

This is the first in a series of posts about institutional identifiers[1].

In my last post, I alluded to some documentation that I've written. That was somewhat misleading, which will soon be apparent, but I liked the parallel construction I had going, and I am but a slave to orderliness.

For about the past six months, I have been working with a NISO group looking into how institutions are identified within information systems:

The I2 (Institutional Identifiers — pronounced "I 2") working group will build on work from the Journal Supply Chain Efficiency Improvement Pilot (http://www.journalsupplychain.com/), which demonstrated the improved efficiencies of using an institutional identifier in the journal supply chain. The NISO working group will develop a standard for an institutional identifier that can be implemented in all library and publishing environments. The standard will include definition of the metadata required to be collected with the identifier and what uses can be made of that metadata. …

The I2 group is split into a few subgroups which have been charged with looking into how institutional identifiers are used in particular scenarios. These scenarios are e-resources, repositories and e-learning systems, and library resource workflows. The scenario names pain me a bit, but so be it; this is our industry, and there are bigger windmills to tilt at.

I am currently co-chairing the subgroup looking at repositories and e-learning, and apparently I am its "tech lead." I don't want to get caught up on names and roles and titles, though; this series isn't about those at all. I'm just setting the scene and explaining why my head's in this space and laying bare my stake in the issue.

The remainder of this series will provide a bit more detail on the issues around institutional identifiers, share how the repository subgroup is grappling with identifier issues and engaging the repository community to assess needs, propose an approach for an identifier system that may meet said needs, and explore what seems to be the thorniest issue[2].

Notes
  1. I offer that very tentatively, knowing what a spectacular failure my last attempt at a series was. []
  2. Hint: management. I know, "duh," right? []


Trackbacks

Use this link to trackback from your own site.

Comments

Leave a response

  1. Jonathan Rochkind Tue, 19 May 2009 18:08:29 UTC

    Now, I know that when a simple solution seems to present itself in the identifier world, it usually means the thinker just doesn't know enough about the problem, but…

    Is there any reason a registered DNS hostname won't do as an institutional identifier? I think jhu.edu serves as a pretty good institutional identifier for my place of work. Well, except right after I write that, I think of all the things that make this more complicated at my own particularly complexly organized institution. (For starters, how do you decide the boundaries of an institution vs. a sub-part or super-part?).

    But are you thinking of something based off of DNS?

  2. Michael Giarlo Tue, 19 May 2009 19:41:23 UTC

    @Jonathan

    Reasonable question. And I too am a fan of simple solutions. I have two answers for you.

    1. The group has not yet begun looking at or thinking about the identifier standard itself. Work has been moving slowly, so we're just now getting to community outreach and needs assessment. Once we've got a good sense of needs, we'll start looking at particular solutions, several of which I imagine will be based off of DNS. That's more or less the official answer, to the extent that I may speak officially (which is very little).

    2. As far as what -I- have been thinking of, and hoping will match needs, well, yes, that is based off of DNS.

    The issues you raise w/ DNS are the ones I'd worry about too, especially if there are use cases for, say, identifying departments and units, etc., where DNS does not necessarily model organizational hierarchy very well (though it certainly may).

    Thanks for the comment, Jonathan.

Comments