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
approach.

Some background (or analogy) -- feel fee to skip this paragraph: We've
registered 'srw' as an 'info' namespace, see http://info-uri.info/registry.
And see: http://www.loc.gov/srw/infoURI.html. 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 http://www.loc.gov/z3950/agency/zing/srw/dc-schema.xsd). 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
(http://www.loc.gov/z3950/agency/zing/srw/record-schemas.html) 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
'mdl'.

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

info:mdl/title-type/1/abbreviated
info:mdl/title-type/1/translated
info:mdl/title-type/1/alternative
info:mdl/title-type/1/uniform

Or for name type:
info:mdl/name-type/1/personal
info:mdl/name-type/1/corporate
info:mdl/name-type/1/conference

Or:
info:mdl/resource-type/1/text
info:mdl/resource-type/1/cartographic
etc.

 Or:
info:mdl/reformattingQuality/1/access
info:mdl/reformattingQuality/1/preservation
info:mdl/reformattingQuality/1/replacement

etc.

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.

--Ray