We had an inconclusive discussion several months ago about extensibility of
enumerated values of elements and attributes. I sketched a proposed approach
using 'info' URIs. There was no response.
We now have a more well-developed proposal and in order to move along with
MADS, as well as the next version of MODS, this time we need some feedback.
see http://info-uri.info/registry about the 'info' URI,
http://www.loc.gov/z3950/agency/zing/srw/infoURI.html, about how SRW uses
http://www.loc.gov/z3950/agency/zing/srw/infoURI.html, about how NetRef uses
We propose to introduce the 'info:xv' namespace, where 'xv' is "XML value"
part-name is an element or attribute name.
info:xv/1/mods/titleType/ -- identifies the element
info:xv/1/mods/titleType/abbreviated -- identifies a value
1= Library of Congress, LC registers the string "mods" to mean the MODS
schema. It also registers
info:xv/1/mods/titleType/ as the URI for the attribute titleType, and the
latter four URIs to represent the four values.
If another organization wants to register one or more schemas for purposes
of assigning 'info:xv' URIs, then the 'info:xv' registration authority
would assign a string to that organization, e.g. '2'. So, conceivably, some
organization (for example the Museum of Discovery and Science) might define
a MODS schema, which would be distinguished from the first MODS schema by
the registrationAuthority string.
The MODS schema would be changed so that these values are not explicitly
enumerated, and the datatype instead is URI. This way, we can add a value
without changing the schema.
Another example, this time an element rather than attribute:
info:xv/1/mods/resourceType/ -- identifies the element
info:xv/1/mods/resourceType/text -- identifies a value of the element
(Note we will need to deal with spaces. Either %encode, or change the
values to get rid of spaces.)
Note that the primary purpose of info:xv is to register these enumerated
values for elements and attributes, but that elements and attributes
themselves are also identified, as a side benefit.
Now, there is an outstanding issue that we've kicked around here. We
originally wanted to allow organizations to define their own (additional)
values for a given element or attribute. We had drafted the following
the difference is an additional registration authority.)
Thus an organization, say LC, would register the MODS schema, and a core set
of values for each given part, but another organization, say OCLC, could
register additional values.
For example, in
the first '1' is LC who registers MODS, and the second '1' is also LC who
registers the core values. However, in
the '1' is still LC, but the '2' is OCLC who has registered an additional
Some of us here feel that two registration authorities is much too
cumbersome. (Some think one is; but there doesn't seem to be a way around
it.) The alternative would be to register all values in a single list. Thus
if your organization had a value to add for a part, it would need to get the
authority for that schema to add it to the list.