Your solution looks quite workable to me. However, an even simpler
solution would be to remove the restriction on MODS, making it
minOccurs=0. As you found, the requirement of a field, any field, means
that even an empty note field creates a valid MODS record, and I think
we can all agree that isn't a much more useful record than one that is
truly empty.
[Aside on library practices: Library cataloging has a concept of "main
entry" which is the minimum necessary to identify an item -- generally
author + title + some edition information. If there were to be some
minimum requirement in MODS it seems that it should be aimed at
enforcing this concept of a minimum bibliographic identifier. If that
isn't enforced, then the record contents might as well be completely
optional.]
You could modify your practice and place the link in the <titleInfo>
field. As a matter of fact, it might be useful to create <titleInfo +
<title> for purposes of quick display, and use the link for "further
info". But I'm fishing here because I don't know what your application
actually will do with the link -- whether it's a "click" or an onLoad
actuate, whether it has an xlink title, etc.
Another solution would be to create an actual "related record" set of
fields from the fields available in MODS and make the choice minOccurs=0
to facilitate linking. I can see how it was an easy short-cut to
"recurse" the entire MODS record inside relatedItem, but in fact there
are things in MODS that you would never really code in relatedItem,
starting with the record level fields (date of creation, etc.), but also
things like subject headings. It's more appropriate to do as you are
doing and create a separate, complete MODS record and point to it from
the relatedItem. In MARC, the related item field contains something that
looks like a bibliographic citation: author, title, edition, date. It
has much less information than a full MARC record.
I'm glad you stumbled onto this and posted it. I hadn't really thought
about the effect of xlink on schema design, and now I see I have a lot
to think about.
kc
On Thu, 2004-01-08 at 09:58, Andrew E Switala wrote:
> Hi MODS folks,
>
> A related entry may have its own record in a MODS infoset, so that the
> <relatedItem> element referring to it needs no content, or at most
> <part> elements. For example, a record for a journal article might have
> the subelement...
>
> <relatedItem type="host" xlink:href="#issn0000-0000">
> <part>
> <detail type="volume">5</detail>
> <extent unit="pages">
> <start>5</start>
> <end>50</end>
> </extent>
> </part>
> </relatedItem>
>
> ...where the journal title, publication information, etc would be
> understood to come from the <mods> record in the same file with
> attribute ID="issn0000-0000".
>
> Since <relatedItem> is derived from <mods>, however, the example is not
> schema valid (because <mods> has to have at least one top-level
> subelement). I've been using an empty <note/> element as filler, but
> perhaps the content model of <relatedItem> could be changed. One way is
> to put the content of <mods> in a group and define both <mods> and
> <relatedItem> in terms of this group (example below), but then the
> "is-a" relationship of <relatedItem> to <mods> is lost. I'm not enough
> of a schema hacker to know if there's a better approach.
>
> --Andy
>
> <xsd:group name="modsContent">
> <xsd:choice>
> <xsd:element ref="titleInfo"/>
> <xsd:element ref="name"/>
> <xsd:element ref="typeOfResource"/>
> <xsd:element ref="genre"/>
> <xsd:element ref="originInfo"/>
> <xsd:element ref="language"/>
> <xsd:element ref="physicalDescription"/>
> <xsd:element ref="abstract">
> <xsd:annotation>
> <xsd:documentation>520</xsd:documentation>
> </xsd:annotation>
> </xsd:element>
> <xsd:element ref="tableOfContents">
> <xsd:annotation>
> <xsd:documentation>505</xsd:documentation>
> </xsd:annotation>
> </xsd:element>
> <xsd:element ref="targetAudience"/>
> <xsd:element ref="note"/>
> <xsd:element ref="subject"/>
> <xsd:element ref="classification"/>
> <xsd:element ref="relatedItem"/>
> <xsd:element ref="identifier"/>
> <xsd:element ref="location">
> <xsd:annotation>
> <xsd:documentation>852 $a $b $j
> $e</xsd:documentation>
> </xsd:annotation>
> </xsd:element>
> <xsd:element ref="accessCondition">
> <xsd:annotation>
> <xsd:documentation>506,
> 540</xsd:documentation>
> </xsd:annotation>
> </xsd:element>
> <xsd:element name="extension"
> type="extensionType"/>
> <xsd:element ref="recordInfo"/>
> </xsd:choice>
> </xsd:group>
>
> <xsd:complexType name="modsType">
> <xsd:group ref="modsContent" maxOccurs="unbounded"/>
> <xsd:attribute name="ID" type="xsd:ID" use="optional"/>
> <xsd:attribute name="version">
> <xsd:simpleType>
> <xsd:restriction base="xsd:string">
> <xsd:enumeration value="3.0"/>
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:attribute>
> </xsd:complexType>
>
> <xsd:complexType name="relatedItemType">
> <xsd:sequence>
> <xsd:group ref="modsContent" minOccurs="0"
> maxOccurs="unbounded"/>
> <xsd:element name="part" type="partType"
> minOccurs="0" maxOccurs="unbounded"/>
> </xsd:sequence>
> <!-- Attributes omitted for clarity -->
> </xsd:complexType>
--
-------------------------------------
Karen Coyle
Digital Library Specialist
http://www.kcoyle.net
Ph: 510-540-7596 Fax: 510-848-3913
--------------------------------------
|