Deridder, Jody L | 6 Nov 22:14 2007
Picon

MODS-generating software, open source, from UT DLC

(Apologies for cross posting)

  

The University of Tennessee Digital Library Center is proud to announce the release of the DLC-MODS Workbook, version 1.2 under the GNU General Public License version 3. 

 

   The DLC-MODS Workbook provides a series of web pages that enable users to easily generate complex, valid MODS metadata records that meet the 1-4 levels of specification outlined in the Digital Library Federation Implementation Guidelines for Shareable MODS Records, (DLF Aquifer Guidelines November 2006).

 

    Developed by programmer Christine Haygood Deane under the direction of metadata librarian Melanie Feltner-Reichert, this open source client-side software provides control of date formats and other problematic fields at the point of creation, while shielding creators from the need to work in XML.  Metadata records created can be partially created, saved to the desktop, reloaded and completed at a later date.  Final versions can be downloaded or cut-and-pasted into text editors for use elsewhere.  

 

  Developed in support for our state-wide digitization project, Volunteer Voices, we hope this system will assist others in their efforts to create valuable digital libraries also.  The software can be viewed here: http://dlc.lib.utk.edu/~cdeane/UTK_LIB_DLC/WB5/workbook.htm

and downloaded here:   http://dlc.lib.utk.edu/~cdeane/UTK_LIB_DLC/beta_download.htm

 

  Please address comments and questions to Melanie Feltner-Reichert (mfeltner-PW9W3dvnVcw@public.gmane.org) and Cricket Deane (cdeane-PW9W3dvnVcw@public.gmane.org).

 

Jody DeRidder

Digital Library Center

University of Tennessee Libraries

Knoxville, Tennessee

 

 

Neil Godfrey | 12 Nov 03:41 2007
Picon
Picon

where to put a research program and subprogram in MODS?

Hi all,

I'm constructing a template for research data. I want to make MODS entries
for each research program and subprogram. 

The program values look like this:
"Farm - Research and Innovation - Managing Animal Performance"

and the subprogram is:
"Genetics"

So they look like subject entries, but are in fact identifications of the
"program" the research is being done for.

Has anyone done anything with similar types of data with MODS? Where do more
experienced heads suggest I map research program and research subprogram to
in a MODS template?

Many thanks,
Neil Godfrey

Metadata Specialist
RUBRIC Project
University of Southern Queensland

Ph: +61 (0)7 4631 5339
Blog: http://metalogger.wordpress.com 
RUBRIC Website: http://www.rubric.edu.au 
USQ Website: http://www.usq.edu.au

Riley, Jenn | 13 Nov 21:24 2007
Picon

date encoding

Hi all,

I'm doing some mappings from item-level EAD inventories into item-level MODS records, and I've run into a
problem with date encodings. My source EAD conforms to the EAD2002 XML Schema, which means all  <at> normal
attributes on dates are ISO8601. But the MODS date encoding attribute value of iso8601 is described in the
User Guidelines <http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html> as
*only* the YYYYMMDD format, rather than any valid ISO8601 value, such as 1999/2000 for a date range. I know
MODS has other mechanisms for date ranges, but I don't think that in this case implementing parsing of the
EAD  <at> normal attribute on dates to look for slashes and convert those into MODS-style ranges is getting
enough benefit for the effort it would take. Is it really the intention for the MODS date encoding
attribute of the value iso8601 to *only* refer to the YYYYMMDD pattern, and to no other valid ISO8601
encoding? If I've got ISO8601 but I can't guarantee it's YYYYMMDD, am I doomed to leaving the encoding
attribute off the MODS date entirely?

Thanks!

Jenn

========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu

Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

Joe Altimus | 13 Nov 23:45 2007
Picon

Re: date encoding

I see the need to map date ranges too, so it would be useful if the MODS ISO8601 attribute accommodated that.

Joe Altimus
Arizona State University Libraries

On Nov 13, 2007 1:24 PM, Riley, Jenn < jenlrile-GZvvpLG7cYSVc3sceRu5cw@public.gmane.org> wrote:
Hi all,

I'm doing some mappings from item-level EAD inventories into item-level MODS records, and I've run into a problem with date encodings. My source EAD conforms to the EAD2002 XML Schema, which means all <at> normal attributes on dates are ISO8601. But the MODS date encoding attribute value of iso8601 is described in the User Guidelines < http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html> as *only* the YYYYMMDD format, rather than any valid ISO8601 value, such as 1999/2000 for a date range. I know MODS has other mechanisms for date ranges, but I don't think that in this case implementing parsing of the EAD <at> normal attribute on dates to look for slashes and convert those into MODS-style ranges is getting enough benefit for the effort it would take. Is it really the intention for the MODS date encoding attribute of the value iso8601 to *only* refer to the YYYYMMDD pattern, and to no other valid ISO8601 encoding? If I've got ISO8601 but I can't guarantee it's YYYYMMDD, am I doomed to leaving th e encoding attribute off the MODS date entirely?

Thanks!

Jenn

========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu

Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

Joe Altimus | 14 Nov 00:18 2007
Picon

need for projected publication date in MODS

I wonder if others see a need for a MODS element to hold information that a resource is not yet available (similar to the MARC 263 element -- Projected Publication Date)?

The need I see involves citations for faculty publications that appear in our digital repository. Sometimes faculty want a minimal citation in the repository before the actual details of the publication are known. Having a MODS element that indicates the provisional nature of the citation seems useful for tracking and other administrative tasks.

The originInfo/dateOther element can be used, of course, but is there is a general need for an element that merits defining a new type of date ("dateToBeIssued" or similar)?

Joe Altimus
Arizona State University Libraries

Rebecca S. Guenther | 14 Nov 15:40 2007
Picon

Re: need for projected publication date in MODS

There are so many dates that are of importance for particular communities
that we provided dateOther for those cases where MODS didn't supply a
specific one (as you noted). We tried to limit defined date types to the
most used sorts of dates. Of course you can use the type attribute with
dateOther and we could consider providing a list of types used, as we do
with note types (http://www.loc.gov/standards/mods/mods-notes.html), if
this would be useful. Maybe other MODS users can speak to your question
about defining a specific date type for this one.

Rebecca

On Tue, 13 Nov 2007, Joe Altimus wrote:

> I wonder if others see a need for a MODS element to hold information that a
> resource is not yet available (similar to the MARC 263 element -- Projected
> Publication Date)?
> 
> The need I see involves citations for faculty publications that appear in
> our digital repository. Sometimes faculty want a minimal citation in the
> repository before the actual details of the publication are known. Having a
> MODS element that indicates the provisional nature of the citation seems
> useful for tracking and other administrative tasks.
> 
> The originInfo/dateOther element can be used, of course, but is there is a
> general need for an element that merits defining a new type of date
> ("dateToBeIssued" or similar)?
> 
> Joe Altimus
> Arizona State University Libraries
> 

Rebecca S. Guenther | 14 Nov 16:21 2007
Picon

Re: where to put a research program and subprogram in MODS?

This reminds me of what we defined the MARC community information format
for, which uses a lot of the MARC bibliographic fields. You could use the
equivalent in MODS for this sort of data, which would mean for a program
you would use <titleInfo><title> for a program name. The subprogram could
be in <subtitle>.

Alternatively you could make a case for using MADS, since this is like an
authoritative form of a name, and consider this a name type=corporate.
Then you could use <namePart> for the main program and repeat it for the
subprogram, subordinately.

Rebecca

On Sun, 11 Nov 2007, [ISO-8859-1] Neil Godfrey wrote:

> Hi all,
> 
> I'm constructing a template for research data. I want to make MODS entries
> for each research program and subprogram. 
> 
> The program values look like this:
> "Farm - Research and Innovation - Managing Animal Performance"
>  
> and the subprogram is:
> "Genetics"
> 
> So they look like subject entries, but are in fact identifications of the
> "program" the research is being done for.
> 
> Has anyone done anything with similar types of data with MODS? Where do more
> experienced heads suggest I map research program and research subprogram to
> in a MODS template?
> 
> Many thanks,
> Neil Godfrey
> 
> 
> Metadata Specialist
> RUBRIC Project
> University of Southern Queensland
> 
> Ph: +61 (0)7 4631 5339
> Blog: http://metalogger.wordpress.com 
> RUBRIC Website: http://www.rubric.edu.au 
> USQ Website: http://www.usq.edu.au
> 

Rebecca S. Guenther | 14 Nov 17:22 2007
Picon

Re: date encoding

The biggest problem here is the fact that ISO 8601 defines a bunch of
alternatives and representations and it is difficult to specify what
portions of ISO 8601 you are using. In MODS we have enumeration values
"w3cdtf" and "iso8601" and we specifically define what we mean when we say
the encoding is "iso8601" to distinguish it from what "w3cdtf" means
(since the latter also is compliant with and a subset of
8601). The purpose of the guidelines was to say that we are using
what is called the "basic" form in ISO8601 (i.e. the form without
the hyphens, which is YYYYMMDD etc.) rather than the "extended" form,
which is the form with hyphens (YYYY-MM-DD) as specified also in W3CDTF.

Although I am not an EAD expert, it looks like EAD also specifies
particular constructs from ISO 8601 and is using the date range as
specified there. In your case you want to use the date range construct
from 8601, which is specified in EAD. That is represented as a date with a
slash and another date. In MODS we parse the start and end dates into
separate elements (as you noted below). So in EAD it might look like
1999/2000 and in MODS it would be <dateIssued encoding="iso8601"
point="start"> (or whatever date type you have). I can understand why you
don't want to have to parse these. I see no reason why we can't say that
your form is also iso8601 and fix the guidelines to say it is anything
allowed by ISO 8601 using the basic rather than extended form (where this
is applicable). In the case of W3CDTF you would use xs:date as specified
in XML schema that restricts it to the form with the hyphens if you want
it to validate. Using "iso8601" doesn't place such a restriction on the
data, so changing the guideline would not be a big deal and our intention 
was not to restrict it so much. 

Note that we (our office at LC) are trying to work on this problem and
come up with some other profile of ISO 8601 that can be used with various
XML formats, including MODS and PREMIS. That will include being able to
use the basic 8601 format without hyphens, and to deal with questionable,
open date ranges, BCE dates, etc.-- and have a name to call these sorts of
encodings. We know we can't fix the problems with ISO 8601 but if we can
define a different profile and then extend it to accommodate other sorts
of dates, we would all benefit.

Rebecca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^  Rebecca S. Guenther                                   ^^
^^  Senior Networking and Standards Specialist            ^^
^^  Network Development and MARC Standards Office         ^^
^^  1st and Independence Ave. SE                          ^^
^^  Library of Congress                                   ^^
^^  Washington, DC 20540-4402                             ^^
^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
^^  rgue@...                                          ^^
^^                                                        ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On Tue, 13 Nov 2007, Riley, Jenn wrote:

> Hi all,
> 
> I'm doing some mappings from item-level EAD inventories into
> item-level MODS records, and I've run into a problem with date
> encodings. My source EAD conforms to the EAD2002 XML Schema, which
> means all  <at> normal attributes on dates are ISO8601. But the MODS date
> encoding attribute value of iso8601 is described in the User
> Guidelines
> <http://www.loc.gov/standards/mods/v3/mods-userguide-generalapp.html>
> as *only* the YYYYMMDD format, rather than any valid ISO8601 value,
> such as 1999/2000 for a date range. I know MODS has other mechanisms
> for date ranges, but I don't think that in this case implementing
> parsing of the EAD  <at> normal attribute on dates to look for slashes and
> convert those into MODS-style ranges is getting enough benefit for the
> effort it would take. Is it really the intention for the MODS date
> encoding attribute of the value iso8601 to *only* refer to the
> YYYYMMDD pattern, and to no other valid ISO8601 encoding? If I've got
> ISO8601 but I can't guarantee it's YYYYMMDD, am I doomed to leaving
> the encoding attribute off the MODS date entirely?
> 
> Thanks!
> 
> Jenn
> 
> ========================
> Jenn Riley
> Metadata Librarian
> Digital Library Program
> Indiana University - Bloomington
> Wells Library W501
> (812) 856-5759
> www.dlib.indiana.edu
> 
> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
> 

Riley, Jenn | 15 Nov 01:47 2007
Picon

Re: date encoding

> Note that we (our office at LC) are trying to work on this problem and
> come up with some other profile of ISO 8601 that can be used with
> various
> XML formats, including MODS and PREMIS. That will include being able to
> use the basic 8601 format without hyphens, and to deal with
> questionable,
> open date ranges, BCE dates, etc.-- and have a name to call these sorts
> of
> encodings. We know we can't fix the problems with ISO 8601 but if we
> can
> define a different profile and then extend it to accommodate other
> sorts
> of dates, we would all benefit.

That's exactly what I need, as well. Looking forward to it in MODS 4.0. :-)

Jenn

========================
Jenn Riley
Metadata Librarian
Digital Library Program
Indiana University - Bloomington
Wells Library W501
(812) 856-5759
www.dlib.indiana.edu

Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com

Jon Stroop | 15 Nov 14:37 2007
Picon

Re: date encoding

Somewhat related to this thread, has anyone found a way or developed a 
practice to record non-Gregorian dates in MODS?  It seems as though at 
least a way to identify the calendar from which the date is derived 
would be helpful.

mods:dateOther[ <at> type="[calendar]"]  seems like the only solution right 
now, but it's not a very satisfying one for such a discreet problem.

It looks as though this has also come up with regard to MARC: 
http://www.loc.gov/marc/marbi/dp/dp117.html

-Jon

Riley, Jenn wrote:
>> Note that we (our office at LC) are trying to work on this problem and
>> come up with some other profile of ISO 8601 that can be used with
>> various
>> XML formats, including MODS and PREMIS. That will include being able to
>> use the basic 8601 format without hyphens, and to deal with
>> questionable,
>> open date ranges, BCE dates, etc.-- and have a name to call these sorts
>> of
>> encodings. We know we can't fix the problems with ISO 8601 but if we
>> can
>> define a different profile and then extend it to accommodate other
>> sorts
>> of dates, we would all benefit.
>>     
>
> That's exactly what I need, as well. Looking forward to it in MODS 4.0. :-)
>
> Jenn
>
>
> ========================
> Jenn Riley
> Metadata Librarian
> Digital Library Program
> Indiana University - Bloomington
> Wells Library W501
> (812) 856-5759
> www.dlib.indiana.edu
>
> Inquiring Librarian blog: www.inquiringlibrarian.blogspot.com
>   


Gmane