Fwd: [MODS] preparation for a new MADS draft

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fwd: [MODS] preparation for a new MADS draft

Bruce D'Arcus
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 
> http://www.loc.gov/standards/mads/mads-preliminary-draft--nov-23.xsd
> For reference see Rebecca's message of August 27 (subject: MADS
> review) accessible from the archive:
> http://listserv.loc.gov/listarch/mods.html
> 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
> |other"> 
>  and
>  <variant type="acronym |abbreviation | translation | expansion |
> other">.
> 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
> elements".
> 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
> http://www.loc.gov/standards/mads/mads-outline-newdraft.html
>  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
> extensibility.
> For example, the following clearly would not be candidates:
> <Identifier invalid=yes
> <date point=start/end
> <date keyDate=yes
> <codeOrText=code/text
> 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
> needs.
> 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.
> --Ray