Ray, a few comments, here and below --
I notice that madsCollection is commented out. Is it coming back?
In the "otherElements", there is something called "position" that needs
a definition. (I don't think it was in the previous version.) Also, the
documentation shows it as subordinate to affiliation but in the schema
it's in otherElements as well as affiliation.
This isn't new, but I just noticed it in this version, but both the url
element and the identifier element are at a level where they can only
pertain to the authority element -- right? In essence, everything in the
record other than the authority element itself are ABOUT the authority
element. (uh oh, I think I see RDF in our future ;-). It seems that
there might be a need for a url or an identifier for other elements as
well, i.e. related or variant. And I'm just not sure what a URL for the
authority would be, so maybe I need an example of what you were thinking
of for this element.
> We deferred changes related to extensibility of enumerated lists.
> The suggestion was to eliminate lists and change the types of
> elements' or attributes' that have enumerated values to 'anyURI', or
I think that lists can be useful so I wouldn't want to see them
eliminated altogether, although I can imagine specific lists being part
of profiles and not in the main standard. I don't fully understand how
profiles would work, however. Would you need to create a schema that
re-defines the element in order to add your list?
These seem very MARC related, and essential for records derived from
> <related type= earlier/later/parentOrg/broader/narrower/other
> <variant type=acronym/abbreviation/translation/expansion/other
> <name type=personal/corporate/event
> <note type=source/history/notFound/endUser
These seem to be more general, but there are solid standards available:
> <language authority=rfc3066/iso639-2b
This is an area where we really need to agree on some standard, or we'll
never have any kind of equivalencies between names:
> <namePart type=date/family/given/termsOfAddress
This is the only list that looks "iffy" to me, i.e. I'm not sure if it's
necessary, although I think the qualifier itself is very useful:
> Discussion of a type library.
In a sense, there will be more need for standardization at the abstract
level with a type library than with MODS or MADS because you will be
treating the data elements apart from any particular function. The
question is: are we ready to create a purely abstract title or name? As
I said above, having some agreement on the forms of names is terribly
important, and the lack of a standard causes all kinds of problems in
working with varieties of metadata. But hashing out a name form that
might have broad utility is not going to be an easy job. Sure, we could
just grab the name from MODS and declare that "it", but my bet is that
if we do create those types there will be lots more people who want to
use them than are interested in MODS.
> An alternative approach is to "include" rather than "import". Then
> instances are not burdened with prefixes and namespaces. The problem
> with this approach is that the target namespace has to be the same for
> both schemas (includer and includee). So if we develop a utility
> schema as a type library, and refence it from MODS and MADS via
> "include", then both MODS and MADS have to have the same target
> namespace. Would this be a good thing, for MODS and MADS to have the
> same namespace?
I don't think so, for the reasons I give above. I think the type library
would get used beyond MADS and MODS, and in a sense that would be the
real motivation for creating it.
> And of course there are hybrid approaches which could use all three
> techniques (distributing the types, importing, and including) but as
> you can see, this is a complicated problem.
Digital Library Specialist
Ph: 510-540-7596 Fax: 510-848-3913