From: "Houghton,Andrew" <[log in to unmask]>
> As a side note, MODS/MADS could use info URI's [1] for these code
> lists.

Ok, I'll describe our current thinking and recent discussions on this

Some background (or analogy) --  feel fee to skip this paragraph:  We've
registered 'srw' as an 'info' namespace, see
And see:  SRW defines a number of
objects whose values are exchanged in the protocol. For example, you specify
a schema name -- dublin core, for example, is identified as:
info:srw/schema/1/dc-v1.1 (and this refers to a specific schema, currently
at The '1' after
'schema' means the URI  is coined by the maintenance agency, and other
values '2', '3', etc. are assigned to other authorities on request, who can
then assign any names they want, but the '1' list is subject to approval by
the SRW implementors. So what you have is a core set of schemas identified
( as well as
extensibility for additional schemas.  This has worked well (so far) for
SRW, and similarly ....

.....we could register an info subspace for "metadata lists", something like

Then, take for example, the list of title types: abbreviated, translated,
alternative, uniform. These could have the following URIs


Or for name type:




All  list names (e.g. "title-type") would be defined by the info:mdl
authority (whoever registers mdl with the info registry, which LC would be
willing to do), who would also assign sub-authorities on request, '2', '3',
etc; and would assign all values subordinate to '1'. This would be
maintained and documented  via web pages.

To be clear, all values of the form 'info:mdl/<list>/1/<value>'  would be
"standard" values for the particular list, and all values of the form
'info:mdl/<list>/<something other than 1>/<value>' would be "extensions".
New "standard" values would be added subject to approval by the  'info:mdl'
community. Extended values would be added, presumably, subject to approval
by the community represented by the subauthority, or in any case according
to procedures defined by (or at the whim of) that authority.  The "list of
lists" would be controlled (no extensibility).

Note also, the means of distinguishing "standard" from "extended" values
might end up different than just assigning "1" for standard. There are some
issues with this that have to be thought out.

In fact there are a number of issues with this scheme but we thought it
would be good to propose it for discussion; if it seems like a good idea we
can take on the associated issues. So we solicit comments.