Re: [CODE4LIB] A metadata tool that scales
Will, We had very similar requirements to those that are in your email and on your blog. And we developed a web-based administrative interface to our fedora repository to meet our own needs. It allows us to directly manage the metadata and content in our repository. It is scalable, in that we can manage all of our different digital object types (image, tei essay, video, ead finding aid, book, and collection) through one interface. Some of the features of our admin interface: * ability to create new digital objects * ability to search existing digital objects * ability to upload/replace/delete content * ability to edit metadata * ability to assign digital objects to collection(s) * ability to feature digital objects in collection(s) * data integrity checking based on digital object type and collection-based metadata rules; digital object candidate statuses * automated creation of derivatives (at least for images - thumbnails and zoomify tilesets) * web-based descriptive metadata editing screens * ability to manipulate structural and relationship metadata of digital objects * controlled vocabulary for metadata entry Some features being worked on: * dynamic lookup during metadata entry for semi-controlled vocabulary lists * online help for metadata editing In our admin interface, we have developed a tool that meets our needs, but is not flexible to meet the needs of the field. It is currently tied to our Fedora implementation, our data model, and our choice of metadata schemes. Dave -- David Kennedy Manager, Digital Collections and Research University of Maryland 3199 McKeldin Library College Park, MD 20742 [EMAIL PROTECTED] (301) 405-9051 (301) 314-9408 FAX Will Sexton wrote: In January of 2007 I sent a post to the Web4lib list titled Metadata tools that scale. At Duke we were seeking opinions about a software platform to capture metadata for digital collections and finding databases. The responses to that inquiry suggested that what we were seeking didn't exist. About a year ago, an OCLC report on a survey of 18 member institutions, RLG Programs Descriptive Metadata Practices Survey Results, supported that basic conclusion. When asked about the tools that they used to create, edit and store metadata descrptions of digital and physical resources, a sizable majority responded customized or homegrown tool. Since my initial inquiry, we launched a new installation of our digital collections at http://library.duke.edu/digitalcollections/. Yet we still lack a full-featured software platform for capturing descriptive metadata. We did our own informal survey of peer institutions building digital collections, which further reinforced that familiar conclusion -- there are lots of Excel spreadsheets, Access and FileMaker databases, etc., out there, but no available enterprise-level solution (and we're still happy to be wrong on this point). We also articulated a detailed series of specifications for a metadata tool. The library has committed to hiring two programmers each to a two-year appointment for producing a tool that meets these specs. I just posted on this list the job description, for which there are two openings. I have a longer version of this post on our digital collections blog (http://library.duke.edu/blogs/digital-collections/2008/10/10/a-metadata-tool-that-scales/), listing our specifications in more detail. But here are some of the basics: * Digitization: integrates with, or provides a module for, management of digitization workflow. * Description: supports a collections-based data model; flexible metadata schema (for us, the Duke Core, derived from qualified Dublin Core); authority lists; cardinality and required-field constraints; metametadata (i.e., flagging, notations and status indicators for individual items); access control; simple and intuitive use. * Publication: exports METS documents as well as other common formats (CSV, etc.). * Asset Management: must be compatible with an asset management policy. While the Duke specifications are particular to our internal needs, I think we captured a lot of what makes the need for a full-featured metadata tool felt around the field. I have some ideas about how to go about implementing this set of specifications, but thought I'd see if the concept might spur discussion on CODE4LIB. How would you approach this project? Any thoughts on architecture, platform, data models, methodologies? Will -- Will Sexton Metadata Analyst / Programmer Duke University Libraries
Re: [CODE4LIB] A metadata tool that scales
I believe that the Rochester XC project involves a component focused on building such a tool, you may want to inquire/coordinate with them. Will Sexton wrote: In January of 2007 I sent a post to the Web4lib list titled Metadata tools that scale. At Duke we were seeking opinions about a software platform to capture metadata for digital collections and finding databases. The responses to that inquiry suggested that what we were seeking didn't exist. About a year ago, an OCLC report on a survey of 18 member institutions, RLG Programs Descriptive Metadata Practices Survey Results, supported that basic conclusion. When asked about the tools that they used to create, edit and store metadata descrptions of digital and physical resources, a sizable majority responded customized or homegrown tool. Since my initial inquiry, we launched a new installation of our digital collections at http://library.duke.edu/digitalcollections/. Yet we still lack a full-featured software platform for capturing descriptive metadata. We did our own informal survey of peer institutions building digital collections, which further reinforced that familiar conclusion -- there are lots of Excel spreadsheets, Access and FileMaker databases, etc., out there, but no available enterprise-level solution (and we're still happy to be wrong on this point). We also articulated a detailed series of specifications for a metadata tool. The library has committed to hiring two programmers each to a two-year appointment for producing a tool that meets these specs. I just posted on this list the job description, for which there are two openings. I have a longer version of this post on our digital collections blog (http://library.duke.edu/blogs/digital-collections/2008/10/10/a-metadata-tool-that-scales/), listing our specifications in more detail. But here are some of the basics: * Digitization: integrates with, or provides a module for, management of digitization workflow. * Description: supports a collections-based data model; flexible metadata schema (for us, the Duke Core, derived from qualified Dublin Core); authority lists; cardinality and required-field constraints; metametadata (i.e., flagging, notations and status indicators for individual items); access control; simple and intuitive use. * Publication: exports METS documents as well as other common formats (CSV, etc.). * Asset Management: must be compatible with an asset management policy. While the Duke specifications are particular to our internal needs, I think we captured a lot of what makes the need for a full-featured metadata tool felt around the field. I have some ideas about how to go about implementing this set of specifications, but thought I'd see if the concept might spur discussion on CODE4LIB. How would you approach this project? Any thoughts on architecture, platform, data models, methodologies? Will -- Will Sexton Metadata Analyst / Programmer Duke University Libraries -- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu --- Jonathan Rochkind Digital Services Software Engineer The Sheridan Libraries Johns Hopkins University 410.516.8886 [EMAIL PROTECTED]
Re: [CODE4LIB] A metadata tool that scales
Have you all looked at enterprise metadata repository tools? Oracle and SAS have nice tools that could be extended to meet some of the requirements listed below. Thanks, Susan -- Susan Teague Rector Web Applications Manager Library Information Systems, VCU Libraries 804.827.3554 | [EMAIL PROTECTED] Will Sexton wrote: In January of 2007 I sent a post to the Web4lib list titled Metadata tools that scale. At Duke we were seeking opinions about a software platform to capture metadata for digital collections and finding databases. The responses to that inquiry suggested that what we were seeking didn't exist. About a year ago, an OCLC report on a survey of 18 member institutions, RLG Programs Descriptive Metadata Practices Survey Results, supported that basic conclusion. When asked about the tools that they used to create, edit and store metadata descrptions of digital and physical resources, a sizable majority responded customized or homegrown tool. Since my initial inquiry, we launched a new installation of our digital collections at http://library.duke.edu/digitalcollections/. Yet we still lack a full-featured software platform for capturing descriptive metadata. We did our own informal survey of peer institutions building digital collections, which further reinforced that familiar conclusion -- there are lots of Excel spreadsheets, Access and FileMaker databases, etc., out there, but no available enterprise-level solution (and we're still happy to be wrong on this point). We also articulated a detailed series of specifications for a metadata tool. The library has committed to hiring two programmers each to a two-year appointment for producing a tool that meets these specs. I just posted on this list the job description, for which there are two openings. I have a longer version of this post on our digital collections blog (http://library.duke.edu/blogs/digital-collections/2008/10/10/a-metadata-tool-that-scales/), listing our specifications in more detail. But here are some of the basics: * Digitization: integrates with, or provides a module for, management of digitization workflow. * Description: supports a collections-based data model; flexible metadata schema (for us, the Duke Core, derived from qualified Dublin Core); authority lists; cardinality and required-field constraints; metametadata (i.e., flagging, notations and status indicators for individual items); access control; simple and intuitive use. * Publication: exports METS documents as well as other common formats (CSV, etc.). * Asset Management: must be compatible with an asset management policy. While the Duke specifications are particular to our internal needs, I think we captured a lot of what makes the need for a full-featured metadata tool felt around the field. I have some ideas about how to go about implementing this set of specifications, but thought I'd see if the concept might spur discussion on CODE4LIB. How would you approach this project? Any thoughts on architecture, platform, data models, methodologies? Will -- Will Sexton Metadata Analyst / Programmer Duke University Libraries
[CODE4LIB] A metadata tool that scales
In January of 2007 I sent a post to the Web4lib list titled Metadata tools that scale. At Duke we were seeking opinions about a software platform to capture metadata for digital collections and finding databases. The responses to that inquiry suggested that what we were seeking didn't exist. About a year ago, an OCLC report on a survey of 18 member institutions, RLG Programs Descriptive Metadata Practices Survey Results, supported that basic conclusion. When asked about the tools that they used to create, edit and store metadata descrptions of digital and physical resources, a sizable majority responded customized or homegrown tool. Since my initial inquiry, we launched a new installation of our digital collections at http://library.duke.edu/digitalcollections/. Yet we still lack a full-featured software platform for capturing descriptive metadata. We did our own informal survey of peer institutions building digital collections, which further reinforced that familiar conclusion -- there are lots of Excel spreadsheets, Access and FileMaker databases, etc., out there, but no available enterprise-level solution (and we're still happy to be wrong on this point). We also articulated a detailed series of specifications for a metadata tool. The library has committed to hiring two programmers each to a two-year appointment for producing a tool that meets these specs. I just posted on this list the job description, for which there are two openings. I have a longer version of this post on our digital collections blog (http://library.duke.edu/blogs/digital-collections/2008/10/10/a-metadata-tool-that-scales/), listing our specifications in more detail. But here are some of the basics: * Digitization: integrates with, or provides a module for, management of digitization workflow. * Description: supports a collections-based data model; flexible metadata schema (for us, the Duke Core, derived from qualified Dublin Core); authority lists; cardinality and required-field constraints; metametadata (i.e., flagging, notations and status indicators for individual items); access control; simple and intuitive use. * Publication: exports METS documents as well as other common formats (CSV, etc.). * Asset Management: must be compatible with an asset management policy. While the Duke specifications are particular to our internal needs, I think we captured a lot of what makes the need for a full-featured metadata tool felt around the field. I have some ideas about how to go about implementing this set of specifications, but thought I'd see if the concept might spur discussion on CODE4LIB. How would you approach this project? Any thoughts on architecture, platform, data models, methodologies? Will -- Will Sexton Metadata Analyst / Programmer Duke University Libraries
Re: [CODE4LIB] A metadata tool that scales
Hi Will, In Issue #1 of the Code4Lib Journal some of my colleagues here at Rutgers published an article on the open sourcing of our homegrown system, which may serve your purposes or at least serve as a starting point. Anyway, here's the article: http://journal.code4lib.org/articles/25 -Shaun Ellis Will Sexton wrote: In January of 2007 I sent a post to the Web4lib list titled Metadata tools that scale. At Duke we were seeking opinions about a software platform to capture metadata for digital collections and finding databases. The responses to that inquiry suggested that what we were seeking didn't exist. About a year ago, an OCLC report on a survey of 18 member institutions, RLG Programs Descriptive Metadata Practices Survey Results, supported that basic conclusion. When asked about the tools that they used to create, edit and store metadata descrptions of digital and physical resources, a sizable majority responded customized or homegrown tool. Since my initial inquiry, we launched a new installation of our digital collections at http://library.duke.edu/digitalcollections/. Yet we still lack a full-featured software platform for capturing descriptive metadata. We did our own informal survey of peer institutions building digital collections, which further reinforced that familiar conclusion -- there are lots of Excel spreadsheets, Access and FileMaker databases, etc., out there, but no available enterprise-level solution (and we're still happy to be wrong on this point). We also articulated a detailed series of specifications for a metadata tool. The library has committed to hiring two programmers each to a two-year appointment for producing a tool that meets these specs. I just posted on this list the job description, for which there are two openings. I have a longer version of this post on our digital collections blog (http://library.duke.edu/blogs/digital-collections/2008/10/10/a-metadata-tool-that-scales/), listing our specifications in more detail. But here are some of the basics: * Digitization: integrates with, or provides a module for, management of digitization workflow. * Description: supports a collections-based data model; flexible metadata schema (for us, the Duke Core, derived from qualified Dublin Core); authority lists; cardinality and required-field constraints; metametadata (i.e., flagging, notations and status indicators for individual items); access control; simple and intuitive use. * Publication: exports METS documents as well as other common formats (CSV, etc.). * Asset Management: must be compatible with an asset management policy. While the Duke specifications are particular to our internal needs, I think we captured a lot of what makes the need for a full-featured metadata tool felt around the field. I have some ideas about how to go about implementing this set of specifications, but thought I'd see if the concept might spur discussion on CODE4LIB. How would you approach this project? Any thoughts on architecture, platform, data models, methodologies? Will -- Will Sexton Metadata Analyst / Programmer Duke University Libraries -- Shaun Ellis Web Applications Programmer Rutgers University Libraries [EMAIL PROTECTED] 732/445-5896
