gmane.comp.text.mods

MODS to MARCXML XSLT transformations

Caitlin Nelson — 2013-05-17T20:05:06

Hello MODS folks,

We are adapting several of the MODS transformation stylesheets for use in a
new Islandora instance in Florida, namely DC-to-MODS / MODS-to-DC and
MARCXML-to-MODS / MODS-to-MARCXML (v 3.4).  For the most part things are
going well, but I have a question about the MARCXML transformations.

The MARCXML to MODS 3.4 stylesheet has very recently been updated and looks
great.  We are having problems, however, with the MODS to MARCXML
stylesheet, which hasn't been updated to reflect the new changes (not
updated at all in about a year, it looks like).  We have little
expectations for a perfect roundtrip, but we're still trying our best.

So, two questions: one, will the MODS to MARCXML stylesheet be updated
anytime soon?  And two, does anyone have stylesheets they'd be willing to
share that do a decent job of round-tripping?  While we can update the
stylesheets here, it would be nice to use work that's already done (or wait
for work in process).  (Conversely, we are happy to share our stylesheets
to anyone who wants them as well.)

Thanks so much,

Caitlin

MODS RDF expressed as xml

Jennifer Eustis — 2013-05-17T17:47:25

Hello collective MODS wisdom,

I just began reading and working through the MODS RDF Ontology primer. I was curious to know if anyone was using MODS RDF expressed in xml. Also, would anyone know where the stylesheet to transform a MODS XML to MODS RDF with xml serialization is? The link provided (http://www.loc.gov/mods/modsrdf/modsrdf.xsl ) didn't work.

Thanks,
Jennifer

MODSRDF joining resource type parts

Saašha Metsärantala — 2013-05-13T18:23:24

Hello!

In the modsrdf.xsl XSLT file, I noticed that the variable declaration

xsl:variable name="resourceTypeClass"

line 1829 (or nearby) probably could be removed for clarity. Instead, two 
lines further down, one could replace

xsl:value-of select="concat($resourceTypeURI,$resourceTypeClass)"

with the content of the declaration of $resourceTypeParts because the 
for-each used to create

xsl:variable name="resourceTypeParts"

on lines 1824 to 1828 populates the $resourceTypeParts variable with an 
already concatenated string (not with a sequence). Furthermore, (at least) 
one of the vertical bars in the RegEx on line 1825 could be remove. I do 
not know either in which cases we need any vertical bar. In other words, 
removing the resourceTypeClass and resourceTypeParts variable 
declarations, we could write the rdf:type element similarly to:

xsl:element name="rdf:type"

xsl:attribute name="rdf:resource"

xsl:value-of select="$resourceTypeURI" /

xsl:for-each select="tokenize(.,'[\s|,\-]')"

xsl:value-of select="concat(upper-case(substring(.,1,1)),substring(.,2))" /

/xsl:for-each

/xsl:attribute

/xsl:element

In the code above, I intentionally removed the greater-than and less-than 
characters for the sake of readability in "older" e-mail user agents.

I also consider that the two following tests

xsl:if test="< at >collection"

and

xsl:if test="< at >manuscript"

could be rewritten for readability and expansibility with a for-each.

xsl:for-each select="< at >manuscript|< at >collection"

The value-of could then be rewritten similarly to:

xsl:value-of select="concat($resourceTypeURI,concat(upper-case(substring(name(.),1,1)),substring(name(.),2)))"

Regards!

Saašha,

Draft MODS version 3.5 available for review

Guenther, Rebecca — 2013-05-09T19:18:12

The MODS Editorial Committee would like to announce the availability of a draft schema for MODS 3.5. Version 3.5 will be backwards compatible to 3.4 and therefore only includes changes that do not result in invalidating existing MODS records.  Changes listed below include the change, its purpose, examples, and the date approved by the MODS Editorial Committee  (this information is also available at: http://www.loc.gov/standards/mods/changes-3-5.html
The draft schema is at:
http://www.loc.gov/standards/mods/v3/mods-3-5-DRAFT.xsd
Please send comments by June 7, 2013, after which we will finalize version 3.5.

Changes in this version:

 1.  Add attribute < at >unit in mods:extent (Approved 2012-03-12)

This change makes the extent element more granular by separating units from extent.

Example:

<physicalDescription>
     <extent unit=”pages”>12</extent>
</physicalDescription>
 2.  Add rfc5656 to languageAuthorityAttributeDefinition (Approved 2012-03-12)

Enumerated values reflect earlier standards; RFC5656 has superceded RFC4646
 3.  Add < at >altFormat and < at >contentType attributes to <titleInfo>, <abstract>, <tableOfContents> and <accessCondition> (Approved 2012-09-17)

This change allows for embedding HTML in MODS, linking with < at >altRepGrp, and indicating the format of the alternative encoding. It applies to those elements that are most likely to have values that need HTML or other formatting that cannot be expressed inside a MODS XML record. Use the altFormat attribute to link out of the record to the same content, formatted or marked up in a different way. Optionally, include the contentType attribute with a media-type as its value (e.g. text/html) to indicate the content type of the target. Where there are multiple alternatives, use the already defined altRepGroup attribute to bind the related instances of each element.

Examples:

<abstract altRepGroup="A" altFormat="http://foo.edu/alternate-markup.html" contentType="application/xhtml+xml"/>

<abstract altRepGroup="A">l'histoire d'un cheval et un garçon qui aimait</abstract>
 4.  Add < at >eventType under <originInfo> to indicate production, publication, distribution, manufacture (Approved 2012-04-23, Revised 2013-01-23

This attribute allows for indicating what type of event the statement of originInfo relates to, e.g. production, publication, distribution, manufacture, or some other event.
Example:

<originInfo eventType="publication">
     <place>
           <placeTerm>Menlo Park, CA</placeTerm>
     </place>
     <publisher>Center for Computer Assisted Research in the Humanities</publisher>
     <dateIssued encoding="marc" point="start">1985</dateIssued>
     <dateIssued encoding="marc" point="end">1988</dateIssued>
     <issuance>continuing</issuance>
     <frequency authority="marcfrequency">Annual</frequency>
</originInfo>

 1.  Add < at >typeURI on <identifier>, <note>, and <physicalDescripton>/<note> (Approved 2012-09-17)

This change allows for indicating that a type is in the form of a URI.

Example:

<identifier typeURI="http://id.loc.gov/vocabulary/identifiers/isbn">9780385333511</identifier>
 2.  Add < at >generator on <classification> (Approved 2013-01-09)

The value of this attribute indicates that the classification number was automatically generated and, if appropriate, how.
Example:

<classification authority="ddc" edition="22" generator="http://www.lcc2ddc.org/version/1.2/"<http://www.lcc2ddc.org/version/1.2/%22> >813.54</classification>

 3.  Add <etal> element, a subelement of <name> (Approved 2013-01-23)

The <etal> subelement is added to the list of <name> subelements to indicate that there are one or more names that, for whatever reason, cannot be explicitily included in another name element.

Example:

<name>
            <namePart type="family">Fox</namePart>
            <namePart type="given">Nellie</namePart>
</name>
<name>
            <namePart type="family">Phillips</namePart>
            <namePart type="given">Bubba</namePart>
</name>
<name>
            <etal/>
</name>

Would mean "Nellie Fox, Bubba Phillips, and others"

8.       Add < at >otherType on <titleInfo> (Approved 2013-02-20)

This allows for specification of other title types that are not explicitly enumerated in the MODS <titleInfo> attribute < at >type.

Example:
<titleInfo lang="chi" script="Hant">

<title>會計學</title>

</titleInfo>

<titleInfo otherType="transliterated" transliteration="chinese/ala-lc">

<title>Kuaijixue</title>

</titleInfo>

<titleInfo type="translated" lang="eng">

<title>Accounting</title>

</titleInfo>


Rebecca S. Guenther
Network Development & MARC Standards Office
Library of Congress
Washington, DC 20540
rgue< at >loc.gov

MODS implementation

Angela Di Iorio — 2013-05-03T09:55:33

Dear MODS community,
I gathered and labelled some warnings and considerations from our MODS
implementation


AUTHORITHY and AUTHORITYURI

I got the following validation errors on my MODS documents.
Theoretically, if I include an authority I should have always the
opportunity to include the authority's URI information.
Here are listed the elements where we got warnings:
Warning: DOMDocument::schemaValidate() [domdocument.schemavalidate]:
Element '{http://www.loc.gov/mods/v3}physicalLocation', attribute
'authorithyURI': The attribute 'authorithyURI' is not allowed.

Warning: DOMDocument::schemaValidate() [domdocument.schemavalidate]:
Element '{http://www.loc.gov/mods/v3}recordContentSource', attribute
'authorithyURI': The attribute 'authorithyURI' is not allowed.

Warning: DOMDocument::schemaValidate() [domdocument.schemavalidate]:
Element '{http://www.loc.gov/mods/v3}recordContentSource', attribute
'authorithyURI': The attribute 'authorithyURI' is not allowed.

For example in mods:phisicalLocation and in mods:recordContentSource
the  authorithyURI attribute is not validated by schema
even though in the MODS documentation website it is declared
================================================================

RELATEDITEM

I have internally mods:relatedItem
a titleInfo/partNumber

it seems that the schema doesn't validate this, even though in
documentation is declared that "All MODS elements can appear as
subelements", maybe sub-subelements are not allowed?

================================================================

TYPE OF RESOURCE
The typeOfResource element doesn't allow the attribute "lang" useful for
multilingualism, considering the large adoption of this element because is
a mandatory element from DLF guidelines, maybe can be useful to add this
attribute.
Ex.
<mods:typeOfResource lang="eng">still image</mods:typeOfResource>
<mods:typeOfResource lang="ita">immagine fissa</mods:typeOfResource>

mods:note[type="ownership"] with authority data numbers on people

Gerrit Kuhle — 2013-05-02T08:49:55

Dear MODS mailing list subscribers, 

I have a problem how to add authority data IDs (especially valueURIs) in
copy specific provenance information according to MODS SCHEMA. The following
example produces a MODS SCHEMA validation report:

    <mods:note
               type="ownership"
               displayLabel="Provenienz"
               valueURI="http://d-nb.info/gnd/118677446"
               authorityURI="http://d-nb.info/gnd/"
               authority="gnd">Crusius,Martin
    </mods:note>

MODS SCHEMA validation report:
- Attribute 'authority' is not allowed to appear in element 'mods:note'.
- Attribute 'authorityURI' is not allowed to appear in element 'mods:note'.
- Attribute 'valueURI' is not allowed to appear in element 'mods:note'.

I would love to know if there is already any solution in MODS format or
whether there are plans to correctly provide authority data IDs in
provenance information.
 
Kind regards
Gerrit Kuhle

Metadata and Data Conversion 
Göttingen State and University Library 
37070 Göttingen 
Germany 

http://www.sub.uni-goettingen.de/
http://www.zvdd.de/
http://www.cerl.org/

Job posting: Metadata Librarian (University of Alabama Libraries)

Mary Alexander — 2013-04-24T14:09:16

(please excuse duplicate postings)

THE UNIVERSITY OF ALABAMA LIBRARIES

METADATA LIBRARIAN

RESPONSIBILITIES: The University of Alabama Libraries is seeking a dynamic, 
highly motivated individual for the position of Metadata Librarian.  
Reporting to the Head of Cataloging & Metadata Services (CMS) and working 
collaboratively with the 2 current metadata librarians and appropriate units 
in the Libraries, this position supports the discovery of and access to UA 
Libraries resources through metadata creation, analysis and enrichment. 
Specific duties include, but are not limited to: assisting in metadata 
production work for digital collections (70%); performing original and copy 
cataloging of non-book materials such as sound recordings and video 
recordings (15%); participating in the Alabama Digital Humanities Center 
projects and E-Science initiative (5%); evaluation of the effectiveness of 
catalog data and metadata for resource discovery (10%); and keeping abreast 
of current issues and trends in cataloging and metadata.

REQUIRED QUALIFICATIONS:  MLS/MLIS from an ALA-accredited program or 
equivalent; knowledge of cataloging and metadata standards and schema such 
as AACR2, RDA, LCSH, MARC21, MODS, Dublin Core; demonstrated understanding 
of all aspects of  metadata; familiarity with the OAI-PMH protocol; 
demonstrated ability to work independently, as well as collaboratively with 
diverse constituencies; and effective oral, written and interpersonal 
communication skills.

PREFERRED QUALIFICATIONS: 1-2 years' experience in cataloging or metadata 
production work; experience using OCLC Connexion, integrated library systems 
(Voyager preferred) and/or digital content management system(s); experience 
in analyzing and manipulating XML and other data formats; familiarity with 
scripting languages.

ENVIRONMENT:  The University Libraries maintains membership in NACO, the 
Association of Research Libraries, SPARC, the Center for Research Libraries, 
the Coalition for Networked Information, LYRASIS, and the Network of Alabama 
Academic Libraries. The Libraries use Ex Libris' Voyager Integrated Library 
System. The Libraries' homepage may be accessed at http://www.lib.ua.edu.

SALARY/BENEFITS:  This will be a  non-tenure earning, renewable faculty 
position with renewal based on performance, funding and the needs of the 
Libraries.  Competitive salary.  Excellent benefits.  Moving allowance may 
be available.

TO APPLY:  Please apply online at https://facultyjobs.ua.edu.  A letter of 
application, resume, and names, address, phone numbers, and e-mail addresses 
of three references should be included.

Open until filled. Applications received by May 31, 2013 are assured of 
receiving full consideration.

THE UNIVERSITY OF ALABAMA IS AN EQUAL OPPORTUNITY/AFFIRMATIVE ACTION 
EMPLOYER

XSLT 1.0 and 2.0

Vicky Phillips — 2013-04-12T13:10:54

Hello,

I notice that you are now releasing MODS 3.4 under XSLT 1.0 and 2.0. 
Although outputs are almost identical there are a few differences, with 2.0
being more precise.  Are you maintaining both versions or are you moving to
maintaining just the XSLT 2.0 version?
Many thanks,

Vicky

Digital Standards Manager
National Library of Wales

$0 in MODS

Ashley Sanders — 2013-03-21T15:40:52

Hello,

I'm wondering how to represent $0 (zero) in MODS, e.g.:

  100 1# $aTrollope, Anthony,$d1815-1882.$0(isni)1234567899999799

The LoC MARC to MODS3.4 XSLT seems to mostly ignore the $0, apart
for the 648, whence it does the following (this is a very contrived example
just created to see what the stylesheet would do with a $0):

  648 #7 $a1800-1899$2fast$0(isni)1234567899999799

  <subject xmlns:xlink="http://www.w3.org/1999/xlink" authority="fast" xlink:href="(isni)1234567899999799">
    <temporal>1800-1899</temporal>
  </subject>

I.e. it's just dumping the $0 into an xlink:href.

The MARC to MODS conversion guidelines on the MODS website say of the 100 $0:

  add xlink="contents of $0" (as URI)

Which seems to be what the MARC to MODS stylesheet is literally doing. But I don't
know what the "(as URI)" comment means. Does it mean the $0 should be converted to
a URI -- this would seem sensible if we are putting it in an xlink:href attribute.

Would converting the 100 $0 to something like the following be a
better overall solution:

  <name authorityURI="http://isni.org"
        valueURI="http://isni-url.oclc.nl/isni/1234567899999799">

Would a general solution to "what should I do with the $0" be: where possible convert
them to urls and add authorityURI and valueURI attributes to the MODS element?

Thanks,

Ashley.
--
Ashley Sanders a.sanders-m7QheJJv02N4oUbgFh0ZNQ< at >public.gmane.org
http://copac.ac.uk -- A Mimas service funded by JISC at the University of Manchester

Job Posting from the University of New Mexico

Rebecca Lubas — 2013-03-13T21:24:01

University of New Mexico Libraries
Metadata and Discovery Services Librarian

The University of New Mexico Libraries (UL) has an opening for a Metadata and Discovery Services Librarian. Reporting to the Director of Discovery, Acquisitions, and Consortial Services, this position is a full-time, 12 month, probationary appointment leading to a tenure decision. The faculty rank and tenure status are negotiable based on qualifications. The anticipated start date is June 1, 2013. The minimum annual salary is $50,000 and is negotiable based on qualifications. This position includes full benefits.

Position Description

Working in a team-oriented and highly electronic environment, the Metadata and Discovery Services Librarian will play an important role in an organization that is committed to making content in all formats more accessible and discoverable for educational and research purposes. The Metadata and Discovery Services Librarian will take full advantage of and contribute to the evolution of multiple metadata languages and new discovery tools and platforms, especially as the UL is in the process of selecting a new ILS and compatible discovery tools.

The Metadata and Discovery Services Librarian will keep current with developments in widely used metadata languages such as but not limited to: RDA, Dublin Core, VRA Core, and EAD.  This librarian will be responsible for leading projects to improve the UL's metadata, and for ongoing training of staff to keep skills in the UL current with needs.  The librarian will work within the UL's integrated library system, DSpace, and CONTENTdm.

This position will work closely with Cataloging and Discovery Services, the LIBROS Library Consortium of New Mexico academic libraries, and all other departments of the UL.  The Metadata and Discovery Services Librarian will play an active role in the UL's Web Committee and the SearchUNM team, providing expertise on good web and search design.

The UL integrates into all we do the UNM values of Excellence, Access with Support to Succeed, Integrity, Diversity, Respectful Relationships, Freedom, and Sustainability. The UL adds to UNM's values: Service, Trust, Collaboration, and Accountability.
Education and Experience

Minimum Qualifications


  *   Earned Master's degree from an ALA-accredited Library/Information Science program or  an international equivalent; and
  *   Three years of experience (36 months) managing or coordinating metadata workflow in an academic setting within the last five years.

Preferred/Desired Qualifications

*         Experience with XML, XSLT, and Dublin Core;
*         Experience with additional metadata schema;
*         Demonstrated knowledge of AACR2, MARC, and RDA;
*         Experience with web development;
*         Demonstrated understanding of developments in linked data;
*         Experience working on teams across the library and outside the library;
*         Demonstrated knowledge of discovery systems in academic libraries;
*         Demonstrated knowledge of Library Integrated Systems in academic libraries;
*         Experience planning and facilitating training for library staff;
*         Experience implementing search tools such as the Google Search Appliance or similar;
*         Experience teaching graduate level metadata courses;
*         Excellent oral, written and interpersonal communication skills; and
*         Demonstrated ability to work effectively with culturally diverse populations.

Primary Duties

The Metadata and Discovery Services Librarian will be responsible for: quality control of metadata created and used by the UL in all its platforms, whether individually created or batchloaded; making recommendations to the Library for metadata workflow; implementing new discovery tools and maintenance of those tools; Search Engine Optimization for UL web pages; being an active member of the LIBROS Coordination Team and providing expertise for that team in public interface design and systems; collaborate with Data Librarians for metadata components of data management plans; ongoing training of Cataloging and Discovery Services Staff in metadata practice;  teaching for-credit Metadata Course for the UL. The Metadata and Discovery Services Librarian will raise awareness among library staff and the entire campus community about emerging trends in content discovery methods.  The Metadata and Discovery Services Librarian will contribute to local, regional, and national metadata initiatives. The Metadata and Discovery Services Librarian will participate in faculty governance meetings and in library management meetings as required. The Metadata and Discovery Services Librarian will contribute to Library initiatives that further UNM's commitment to diversity and inclusion.

To apply: Please visit UNMJobs at http://unmjobs.unm.edu/

Deadline The search will remain open until the position is filled.  For best consideration, complete applications must be received through the UNMJobs website no later than April 1, 2013.

UNM's confidentiality policy ("Disclosure of Information about Candidates for Employment," UNM Board of Regents' Policy Manual 6.7), which includes information about public disclosure of documents submitted by applicants, is located at http;//www.unm.edu/~brpm/r67.htm
The University of New Mexico is an Equal Employment Opportunity/Affirmative Action Employer and Educator.


Rebecca L. Lubas
Director of Discovery, Acquisitions & Consortial Services
University of New Mexico Libraries
rlubas-iJIHYJSk46c< at >public.gmane.org<mailto:rlubas-iJIHYJSk46c< at >public.gmane.org>
505-277-5176

MODS workshop in New York

Rebecca Guenther — 2013-03-12T18:31:28

Members of this list may be interested in the workshop "Using MODS for Cultural Heritage Objects" being held at the Metropolitan New York Library Council on Apr. 26, 2013. This day-long workshop gives an overview of MODS and MADS: their purpose, design principles, data elements, and how they are being implemented particularly in digital library projects. For further information see:
http://metro.org/events/304/

Rebecca

Rebecca Squire Guenther
rguenther52-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

MARCXML to MODS 3.4 XSLT (Revision 1.85) Announcement

Meehleib, Tracy — 2013-03-07T22:03:28

MARCXML to MODS 3.4 XSLT  (Revision 1.85) Announcement

The Library of Congress' MARCXML to MODS 3.4 XSLT stylesheet (Revision 1.85)  <http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-4.xsl> is now available--it incorporates edits made in response to comments received since the release of Revision 1.84.

The MODS 3.4 XSLT is based on the MARC to MODS 3.4 mapping made available by the Library of Congress in July of 2010 and updated in October 2012 <http://www.loc.gov/standards/mods/mods-mapping.html>. The mapping and the XSLT are also available via the Library of Congress' MODS Web site<http://www.loc.gov/standards/mods/>. They will be revised periodically as users' comments are received and as subsequent MODS Editorial Committee analysis and decisions evolve.

Please note that content standards and practices using MARC vary among institutions, and sometimes within an institution over time or between types of collections or materials. No one stylesheet can deal appropriately with all variations in the use of MARC. The mapping decisions underlying the changes we have made, as well as the decisions underlying the LC stylesheet should be tested on sample records to determine whether the results are as desired or whether the institution needs to modify the stylesheet for a particular collection of records.

General questions about the mapping may be directed to the MODS Editorial Committee members via ndmso-+hwoy1Po9Oc< at >public.gmane.org<mailto:ndmso-+hwoy1Po9Oc< at >public.gmane.org>. Specific questions about the stylesheet may be addressed to Tracy Meehleib at tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org> .

Thank you,
Tracy Meehleib
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540-4402
+1 202 707 0121 (voice)
+1 202 707 0115 (fax)
tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org>

MODSRDF duck-typing dates

Saašha Metsärantala — 2013-02-26T17:28:44

Hello!

Thanks again for your work with MODSRDF!

To avoid a lengthy e-mail, I will try to modularize my suggestions, which 
will also help cooperation to discuss different features of the XSLT in 
different threads.

To mitigate confusions when refering to line numbers, this first e-mail 
focuses on a question concerning a feature at the end of the XSLT file.

To begin with, to be able to compile the XSLT, I temporarily modified it 
slightly:

I discarded the xsl:otherwise immediately below the XML comment with the 
text on line 1234


Furthermore, on line 1634, primaryTitleIdentifier is used but not defined 
and I temporarily discarded the xsl:if immediately surrounding it, too.

After these two temporary removals, which I won't discuss in any detail 
within this e-mail, let's now focus on the duck-type design pattern I 
suggest to use within this XSLT.

Near the line 1894 at the end of the modsrdf.xsl XSLT, the value of the 
rdf:datatype is choosen according to attribute values in the input file. 
This does not only assumes that the attribute values in the input file are 
appropriately chosen. As it is formulated today, xsd:date is choosen as 
the value of the rdf:datatype when the input file states that its datatype 
is iso8601, which may give erroneous results because iso8601 is neither 
equal to nor a subset of xsd:date.

My suggestion is to use a RegEx to test the value given in the input MODS 
file and use it to choose an appropriate value for the rdf:datatype 
attribute accordingly.

Based on the RegExes at
http://www.w3.org/TR/xmlschema11-2/#con-date-day and
http://www.w3.org/TR/xmlschema11-2/#con-dateTime-day

I suggest to define the following variables:

xsl:variable name="dateRegex" select="'-?([1-9][0-9]{3}[0-9]*|0[0-9]{3})-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])'"

xsl:variable name="timeRegex" select="'T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))'"

xsl:variable name="zoneRegex" select="'(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))'"

Thereafter, the value of the rdf:datatype on line 1894 can be established 
within xsl:when statements similar to

xsl:when test="matches($value, concat('^', $dateRegex, $zoneRegex, '?$'))"

xsl:value-of select="'xsd:date'"/

/xsl:when

xsl:when test="matches($value, concat('^', $dateRegex, $timeRegex, $zoneRegex, '?$'))"

xsl:value-of select="'xsd:dateTime'"/

/xsl:when

etc. In this e-mail, I removed angle brackets to avoid possible 
misrenderings in some e-mail user agents. Also, I did not give any 
complete solution: maybe, we would want several xsl:when and also an 
xsl:otherwise as a catch-up at the end of the xsl:choose but I assume that 
you will understand the description of the design suggestion I give here.

An other (somewhat more complex) suggestion would be to use a parameter to 
let the user choose which design pattern to use at run-time.

Comments are welcome! I hope this helps!

Regards!

Saašha,

Classification alternatives

Hend Eleraky — 2013-02-18T10:28:12

Dear All,
I need to ask about something. I need to show the dewey decimal
classification in mods as categories.
 For example  : <Classification type "ddc ">History & geography  
<Classification>
in mods schema it's stated that we put the call number for classification
element
[<classification authority="ddc" edition="21">911.62</classification>]
So i thought i may use "altRepGroup" for this issue .
For example :
<classification authority="ddc" edition="21"
altRepGroup=1>911.62</classification>
<classification authority="ddc" edition="21" altRepGroup=1 >History &
geography</classification>

Is it acceptable ??? Also , if i need to make sub-categories could i do the
same scenario ?

MODS/RDF draft ontology available

Rebecca Guenther — 2013-02-14T18:48:41

As a result of requests from the MODS community and for its own explorations into Linked Data, the Library of Congress has developed MODS/RDF, an ontology for MODS. This work has been informed by the previous work of developing a MADS/RDF ontology, which is in use now in id.loc.gov, LC's Linked Data Service, and by discussions in the MODS Editorial Committee. MODS/RDF may be used to create born-RDF MODS, or it may be used to create an RDF description corresponding to an existing MODS XML record.  (An XSLT is available to help create MODS/RDF from MODS XML.) 


Although it is still a draft and work in progress, LC would like to share its work on the ontology to encourage experimentation with MODS modeled as RDF.  As the Bibliographic Framework Transition Initiative and its BIBFRAME data model is emerging, it is clear that much work is going into expressing bibliographic data as RDF. We will be working on a mapping of MODS to BIBFRAME as the BIBFRAME model stabilizes, and this initial work on MODS/RDF may inform that task.   


The ontology may be found at: http://www.loc.gov/standards/mods/modsrdf/

Rebecca

Rebecca Squire Guenther
Library of Congress
Network Development & MARC Standards Office
rguenther52-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 
rgue-+hwoy1Po9Oc< at >public.gmane.org

MARCXML to MODS 3.4 XSLT 2.0 (Revision 2.16) Announcement

Meehleib, Tracy — 2013-02-08T20:07:06

MARCXML to MODS 3.4 XSLT 2.0  (Revision 2.16) Announcement

The Library of Congress' MARCXML to MODS 3.4 XSLT 2.0 stylesheet (Revision 2.16)  <http://www.loc.gov/standards/mods/v3/MARC21slim_MODS3-4_XSLT2-0.xsl> is now available--it incorporates edits made in response to comments received since the release of Revision 2.14.

The MODS 3.4 XSLT is based on the MARC to MODS 3.4 mapping made available by the Library of Congress in July of 2010 and updated in October 2012 <http://www.loc.gov/standards/mods/mods-mapping.html>. The mapping and the XSLT are also available via the Library of Congress' MODS Web site<http://www.loc.gov/standards/mods/>. They will be revised periodically as users' comments are received and as subsequent MODS Editorial Committee analysis and decisions evolve.

Please note that content standards and practices using MARC vary among institutions, and sometimes within an institution over time or between types of collections or materials. No one stylesheet can deal appropriately with all variations in the use of MARC. The mapping decisions underlying the changes we have made, as well as the decisions underlying the LC stylesheet should be tested on sample records to determine whether the results are as desired or whether the institution needs to modify the stylesheet for a particular collection of records.

General questions about the mapping may be directed to the MODS Editorial Committee members via ndmso-+hwoy1Po9Oc< at >public.gmane.org<mailto:ndmso-+hwoy1Po9Oc< at >public.gmane.org>. Specific questions about the stylesheet may be addressed to Tracy Meehleib at tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org> .

Thank you,

Tracy

Tracy Meehleib
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540-4402
+1 202 707 0121 (voice)
+1 202 707 0115 (fax)
tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org>

date types

Jens Østergaard Petersen — 2013-02-08T08:06:28

Hello,

In MODS, < at >type is used to subcategorize. We don't have <personalName> and <corporateName> and so on - and lucky for that.

Dates are the only exception. In <originInfo> we have the long list of <dateIssued>,  <dateCreated>,  <dateCaptured>,  <dateValid>,  <dateModified>,  <copyrightDate>, and <dateOther>.

If the design principles used elsewhere in MODS were followed, we would instead have one <date> element with a < at >type attribute that took the values "issued",  "created,  "captured,  "valid,  "modified",  "copyright, and "other". 

While this does not create major problems, I am curious to know why this decision was taken and if changes are being considered.

I have another question relating to typing dates:

In <part>, there is a <date> element. It is used for instance to record that a certain volume of a periodical belongs to a certain year, as for example in "Vol. 44, No. 3 (1999), pp. 13-17." Periodicals are not seldom behind schedule and it happens that this date is not the actual date of issue (the real date of issue may occasionally be recorded on the title page as well).

The <date> element is untyped, so there is no way to record this. I do not know which concrete value a librarian would use if it were possible, but I assume that one can be formulated. 

Needless to say, my suggestion is that a coming version of MODS uses a typed <date> element throughout.

Best,

Jens

MARCXML to MODS 3.4 XSLT (Revision 1.84) Announcement

Meehleib, Tracy — 2013-02-07T20:15:29

MARCXML to MODS 3.4 XSLT  (Revision 1.84) Announcement

The Library of Congress' MARCXML to MODS 3.4 XSLT stylesheet (Revision 1.84)  <http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-4.xsl> is now available--it incorporates edits made in response to comments received since the release of Revision 1.83.

The MODS 3.4 XSLT is based on the MARC to MODS 3.4 mapping made available by the Library of Congress in July of 2010 and updated in October 2012 <http://www.loc.gov/standards/mods/mods-mapping.html>. The mapping and the XSLT are also available via the Library of Congress' MODS Web site<http://www.loc.gov/standards/mods/>. They will be revised periodically as users' comments are received and as subsequent MODS Editorial Committee analysis and decisions evolve.

Please note that content standards and practices using MARC vary among institutions, and sometimes within an institution over time or between types of collections or materials. No one stylesheet can deal appropriately with all variations in the use of MARC. The mapping decisions underlying the changes we have made, as well as the decisions underlying the LC stylesheet should be tested on sample records to determine whether the results are as desired or whether the institution needs to modify the stylesheet for a particular collection of records.

General questions about the mapping may be directed to the MODS Editorial Committee members via ndmso-+hwoy1Po9Oc< at >public.gmane.org<mailto:ndmso-+hwoy1Po9Oc< at >public.gmane.org>. Specific questions about the stylesheet may be addressed to Tracy Meehleib at tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org> .

Thank you,

Tracy

Tracy Meehleib
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540-4402
+1 202 707 0121 (voice)
+1 202 707 0115 (fax)
tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org>

transliterations

Rebecca Guenther — 2013-01-29T19:50:55

We had a discussion some time ago about how to mark transliterations. The suggestion was to add another title type < at >transliteration. However, the MODS Editorial Committee didn't believe this was the appropriate solution, since the other title types can also be transliterations, and you can't repeat the attribute.
See:
http://listserv.loc.gov/cgi-bin/wa?A2=ind1209&L=mods&T=0&X=6BB0FD4079D87771FC&P=302

The MODS Editorial Committee decided that the suggested way of handling these situations is to use the transliteration attribute with a value "unspecified" (if a specified value is not known, but it is desirable to mark it as a transliteration). If a user wishes to give fuller information then this can be done locally. In addition, the MODS Editorial Committee will be discussing fuller support of extensions, but this is a broader discussion. This solution will be documented in the MODS User Guidelines and does not require a schema change.

Rebecca

Rebecca Guenther
Library of Congress
Network Development & MARC Standards Office
rguenther52-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

Submissions for MODS & MADS Implementation Registries

Meehleib, Tracy — 2013-01-25T18:16:21

Hi MODS & MADS Users,

We are in the process of updating the MODS & MADS Implementation Registries and the Tools for MODS pages and would like to add any new projects/tools that are currently available to the community.

If you would like your projects/tools to be included, please supply information for each category in the MODS Implementation Registry http://www.loc.gov/standards/mods/registry.php and/or Tools for MODS page http://www.loc.gov/standards/mods/tools_for_mods.php , and we will add your projects/tools to the registry. For MADS projects, please supply information for each category in the MADS Implementation registry http://www.loc.gov/standards/mads/mads-registry.php.

Please submit registry information directly to me at tmee-v1C6lQAhcs0< at >public.gmane.org

Thank you, Tracy


Tracy Meehleib
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540-4402
+1 202 707 0121 (voice)
+1 202 707 0115 (fax)
tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org>

MARCXML to MODS 3.4 XSLT (Revision 1.83) Announcement

Meehleib, Tracy — 2013-01-18T23:32:53

MARCXML to MODS 3.4 XSLT  (Revision 1.83) Announcement

The Library of Congress' MARCXML to MODS 3.4 XSLT stylesheet (Revision 1.83)  <http://www.loc.gov/standards/mods/v3/MARC21slim2MODS3-4.xsl> is now available--it incorporates edits made in response to comments received since the release of Revision 1.82.

The MODS 3.4 XSLT is based on the MARC to MODS 3.4 mapping made available by the Library of Congress in July of 2010 and updated in October 2012 <http://www.loc.gov/standards/mods/mods-mapping.html>. The mapping and the XSLT are also available via the Library of Congress' MODS Web site<http://www.loc.gov/standards/mods/>. They will be revised periodically as users' comments are received and as subsequent MODS Editorial Committee analysis and decisions evolve.

Please note that content standards and practices using MARC vary among institutions, and sometimes within an institution over time or between types of collections or materials. No one stylesheet can deal appropriately with all variations in the use of MARC. The mapping decisions underlying the changes we have made, as well as the decisions underlying the LC stylesheet should be tested on sample records to determine whether the results are as desired or whether the institution needs to modify the stylesheet for a particular collection of records.

General questions about the mapping may be directed to the MODS Editorial Committee members via ndmso-+hwoy1Po9Oc< at >public.gmane.org<mailto:ndmso-+hwoy1Po9Oc< at >public.gmane.org>. Specific questions about the stylesheet may be addressed to Tracy Meehleib at tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org> .

Thank you,

Tracy
Tracy Meehleib
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave SE
Washington, DC 20540-4402
+1 202 707 0121 (voice)
+1 202 707 0115 (fax)
tmee-+hwoy1Po9Oc< at >public.gmane.org<mailto:tmee-+hwoy1Po9Oc< at >public.gmane.org>