A companion schema for MODS, called MADS. The idea one could, for
example, have a name element in MODS which is just an xlink pointer to
a MADS record, which contains detailed information on that person,
included name variations (such as in different languages/scripts),
contact details, etc.
At some point, it might be nice to get these stylesheets able to work
with this data.
Begin forwarded message:
> From: "Ray Denenberg, Library of Congress" <[hidden email]>
> Date: November 23, 2004 2:59:56 PM EST
> To: [hidden email]
> Subject: [MODS] preparation for a new MADS draft
> Reply-To: Metadata Object Description Schema List <[hidden email]>
> In preparation for a new MADS draft, we have developed a "preview"
> draft, at
> For reference see Rebecca's message of August 27 (subject: MADS
> review) accessible from the archive:
> There are three changes from the previous version:
> 1. Descriptors now allow empty elements, so you can use an xlink
> attribute (URI) in lieu of a value.
> 2.<ref> is replaced with two elements:
> <related type="earlier | later |parentorg | broader | narrower
> <variant type="acronym |abbreviation | translation | expansion |
> The high level structure now is:
> One <authority>
> Zero or more <related>
> Zero or more <variant>
> Zero or one <otherElements> which is a wrapper for one or more "other
> 3. All of the MODS elements in the previous MADS draft (e.g.
> modsNamePart -- namePart from MODS was copied verbatim into MADS and
> renamed modsNamePart) have been removed, and instead there are
> references to MODS (e.g. mods:namePart). This requires some changes
> to MODS, and a draft is available at
> http://www.loc.gov/standards/mads/mods-for-mads.xsd. This is not a
> proposal for a new MODS version, just an illustration of what needs to
> be done to MODS to support these MADS references, and this MODS draft
> is fully compatible with the current version, it simply restructures
> some of the definitions. Please see below for more discussion on this.
> An outline according to the new version is a
> 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
> 'string'. However, some of the enumerated lists in MADS are schema
> specific, not general code lists, and clearly not subject to
> For example, the following clearly would not be candidates:
> <Identifier invalid=yes
> <date point=start/end
> <date keyDate=yes
> The following might or might not:
> <related type= earlier/later/parentOrg/broader/narrower/other
> <variant type=acronym/abbreviation/translation/expansion/other
> <date encoding=w3cdtf/iso8601/marc
> <date qualifier=approximate/inferred/questionable
> <name type=personal/corporate/event
> <note type=source/history/notFound/endUser
> <language authority=rfc3066/iso639-2b
> <namePart type=date/family/given/termsOfAddress
> So it isn't clear which would and which would not be subject to
> extensibility, and this needs more study.
> Discussion of a type library.
> Change (3) above is a preliminary step, at this stage possibly
> for illustration purposes only, in what may ultimately be a type
> library for MODS and MADS and other schemas in this family. Thus the
> common structures could be removed also from MODS, put in a common
> type library which MODS and MADS both would reference. However, there
> are a number of considerations, this doesn't seem to be an easy
> problem, and I don't think that any "best practices" documents are
> particularly helpful because each community has it's own peculiar
> In this initial approach where MADS references structures defined in
> MODS, MADS instances are burdened with MODS prefixes, but MODS
> instances are not affected. But this doesn't seem like a good
> long-term approach, to single out one (real) schema to hold the common
> structures. There may eventually be structures defined for MADS that
> MODS may want to reference (in a future MODS version). Then, MODS
> would reference MADS and vice versa; that isn't in itself a problem,
> but there may be additional such schemas, and eventually we'd have a
> number of schemas all referencing one another, with each instance
> having to declare a bunch of namespaces; moreover, the purpose of
> doing it this way would be defeated since they would all be burdened
> with prefixing anyway. So it seems that a common import schema would
> be better; however, it would be necessary, and might not be easy, to
> determine the scope of commonality.
> 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? If the sole purpose of a common library was to
> support MODS and MADS definitions, that might work. If a third schema
> comes along in this family, it would need to have the same namespace
> (in order to "include" from the common library), and so on.
> 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.
|Free forum by Nabble||Edit this page|