Ray,

I'm a bit unclear on the structure of this info URI. I had understood
that the "namespace" component of the info URI determined the namespace
and the registration responsibility. The current info URI's have the
application at the namespace level:

info:lccn/
info:netref/
info:sici/
info:srw/
etc.

The info:xv/1/mods/ seems to exist at a further level of abstraction
than the other info URIs. Is the namespace level is one-to-one with who
is responsible for that space? (The IETF draft doesn't say this
explicitly, or I can't find where it does.) Is it your intention that
LoC would administer the "xv" namespace?

The example that you give is of an authoritative list of value for a
MODS data element. If the list is truly a MODS list, then it makes sense
to have:

info:mods/resourceType/text

If the lists could be used for items other than MODS, (i.e. the
organizational codes that LoC maintains), where would they belong in the
info registry? Are you envisioning info:xv/1/marc21 (as an example)?

If OCLC wishes to have a different list of resource types then they
would need to have their own namespace for that list. (info:lc_res and
info:oclc_res?) I can't imagine that we can have an authoritative list
that is a mixture of items from two authorities.

kc

On Tue, 2004-10-19 at 09:57, Ray Denenberg, Library of Congress wrote:
> 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.
>
> As background,
> see http://info-uri.info/registry about the 'info' URI,
> http://www.loc.gov/z3950/agency/zing/srw/infoURI.html, about how SRW uses
> them, and
> http://www.loc.gov/z3950/agency/zing/srw/infoURI.html, about how NetRef uses
> them.
>
>
> We propose to introduce the 'info:xv' namespace, where 'xv' is "XML value"
>
> info:xv syntax:
> info:xv/<registrationAuthority>/<schema-name>/<part-name>[/<value>]
>
> part-name is an element or attribute name.
>
> Example:
> info:xv/1/mods/titleType/ -- identifies the element
> info:xv/1/mods/titleType/abbreviated -- identifies a value
> info:xv/1/mods/titleType/translated
> info:xv/1/mods/titleType/alternative
> info:xv/1/mods/titleType/uniform
>
> 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
> info:xv/1/mods/resourceType/cartographic
> info:xv/1/mods/resourceType/notated music
> (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
> syntax:
>
> info:xv/<registrationAuthority>/<schema-name>/<part-name>/[<subRegistrationA
> uthority>][/<value>]
> (Compare with:
> info:xv/<registrationAuthority>/<schema-name>/<part-name>[/<value>]
> 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
> info:xv/1/mods/resourceType/1/cartographic
> the first '1' is LC who registers MODS, and the second '1' is also LC who
> registers the core values. However, in
> info:xv/1/mods/resourceType/2/cartoon
> the '1' is still LC, but the '2' is OCLC who has registered an additional
> resource type.
>
> 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.
--
-------------------------------------
Karen Coyle
Digital Library Specialist
http://www.kcoyle.net
Ph: 510-540-7596 Fax: 510-848-3913
--------------------------------------