Seconded with some reservations.  Most controlled lists are identified
with a non-enumerated authority attribute.  These attributes are not
controlled by an enumerated type, so they could be opened up as the
other Andy suggests simply by changing the schema documentation, and not
the substantive parts of the schema.  E.g. "value is a URI or a keyword
from the list at ..."

Excluding code/text attributes and flags that can only take the value
"yes," these appear to be all the elements and attributes with
hard-coded controlled lists:

* typeOfResource
* originInfo/issuance
* relatedItem/@type
    There should be some absolutely controlled lists, with items very
broad in scope like these, just for interoperability.

* originInfo/place/placeTerm/@authority
* subject/geographicCode/@authority
* language/languageTerm/@authority
    I don't know enough to comment on these.  Are there many
alternatives?

* physicalDescription/reformattingQuality
* physicalDescription/digitalOrigin
    These ones are definitely too MARC-centric and could use an
authority attribute.

* encoding, point, and qualifier attributes on date types
    The point and qualifier attributes seem to cover all bases.  Can't
comment on encoding.  There are certainly numerous ways to code temperal
information (Mayan calendar, anyone?) but is the most part of them
identifiable with a URI?

--Andy

 -----Original Message-----
From: [log in to unmask]
Sent: Friday, December 05, 2003 12:03
To: <[log in to unmask]>
Subject: Re: [MODS] genres and governments records



        > From: Bruce D'Arcus [mailto:[log in to unmask]]
> Subject: Re: [MODS] genres and governments records
>
> On Friday, December 5, 2003, at 10:27 AM, Karen Coyle wrote:
>
> If we want the genre element in MODS to include any genre from any
> metadata, then it should be a text field, not a controlled list. A
> controlled list only makes sense if you have some reason to keep
> control, i.e. there's some particular meaning to the list that you
don't
> want to see violated.

        This was one of my complaints about MODS, over a year ago, and
indicated
on this list in several messages.  MODS takes too much from MARC 21 with

the idea that only its controlled lists can be used and they are hard
coded into the Schema without anyway to use alternate controlled lists,
without directly modifying the XML Schema.  Many metadata communities
will
just not use MARC 21 code lists since they have their own and thus will
create their own metadata formats rather than reusing MODS.

        So I will reiterate the direction that I would like to see MODS
move
towards: controlled lists in MODS should be URI based or use a URI for
the "controlling authority" along with the term from the controlled
list, so that other metadata communities can plug in their own
controlled
lists.  Doing that would still be in alignment with CORES work that LC
has
already undertaken.


        Andy.