The UCLDC metadata scheme comprises a draft, initial blueprint for digital object information (as well as repository and collection information) that will be managed in the UCLDC framework. The metadata scheme is documented in the form of a spreadsheet; the wiki page provides context for the metadata scheme.
Before we fully implement the metadata scheme within the UCLDC framework – and in particular, within the Nuxeo DAMS platform -- we'd like your input and feedback on the digital object metadata model. In particular, we'd like to confirm the following:
1) Scope of digital object metadata scheme: Please review the "Scope" statement on the UCLDC metadata scheme wiki page, and see also the spreadsheet (1st tab, "Digital Objects"). Does the scheme generally accommodate the range and kinds of metadata that you need to describe your resources?
2) Required digital object metadata: Please review the spreadsheet (1st tab, "Digital Objects"; see "Obligations" column). The specification includes -- for each metadata element -- an indication if the data element is required or not. We would like to confirm that the proposed requirements are acceptable. As we get further into defining the requirements for the UCLDC discovery/delivery interface, the requirements may need adjustments.
Just a question for Adrian: Places is currently missing a DC property. Should it be dc:coverage?
I think Places should be mapped to dc:coverage and dcterms:spatial (sub-property); on the other hand, Physical Location should be mapped to dc:description or dc:source?
Hi Chrissy, Shu – oops, that's a mistake in the spreadsheet regarding the lack of a DC mapping for "Places." It should indeed map to dc:coverage for the DC property (and dcterms:spatial for the DC sub-property). I'll update the spreadsheet to reflect this.
"Physical Location" could be mapped to an alternative DC property, although there's no nice, clear candidate for handling of this type of information. dc:coverage is a stretch, but details about the physical location of the item could potentially fall under this purview (http://www.dublincore.org/documents/usageguide/elements.shtml#coverage).
I thought coverage normally describes the intellectual content/scope of a resource - this is indeed a tough one!
Here are my initial thoughts on the draft UCLDC metadata model.
1) The scheme does generally seem to accommodate the range and kinds of metadata needed to describe our digital resources. A few comments:
2) Yes, the proposed required fields are acceptable. Requirements can be tricky, especially when dealing with legacy digital objects from multiple campuses, but I think you have struck a nice balance.
In terms of dates (which I am recalling Adrian mentioned briefly on our call), I would strongly (if at all possible) encourage requiring a machinable date when the date field is used.
Thank you for your comments and feedback! Responses to your questions, below.
1A) We were initially envisioning that the Publisher data field would hold the formal name of the publisher (personal name, organization name) -- derived according to a content standard or local guidelines, or taken from an authority file. I.e., MARC 260 $b or MODS "publisher". The date of publication could be indicated in the Date data field (which will have a type indicator for creation vs. publication dates). We don't have a good analog in place yet for place of publication.
That said, we could just configure the Publisher data field so that it could accommodate more descriptive, narrative publication info. -- basically, a free-text field -- if that's preferred by everyone.
1B) Thanks for raising this. We haven't started to fully map out the descriptive data fields for Collection information, that would be primarily managed in the Collection Registry -- and this is something that we'd definitely like to start building out, and getting your collective feedback on in upcoming releases. One thing that we'll need to balance is the degree to which we'd replicate information about collections in the Collection Registry, where the information is already in the form of EAD finding aids and MARC records (or on HTML web pages, etc.).
1C) We also haven't mapped out non-descriptive or rights metadata that will be tracked in Nuxeo -- such as administrative metadata about files that are imported, etc. (creation date, modification, user that imported the file, version history, etc.). That said, there are a number of default fields that we can enable and configure, which will automatically record and track this type of information. For this upcoming Aggie release, you'll be able to see some examples of this in sample objects that we've loaded. This is something we can also start to flesh out, in upcoming releases.
3) The Date data fields will be modeled in Nuxeo to include both a descriptive form of date information (e.g., "Circa 1920"), as well as normalized form of dates.
Here are my specific suggestions:
Here are my general questions:
Echo Shu's question about "List" for data entry. Not sure how this impacts elements like contributor or creator.
Sue Chesley Perry
I think generally we should be able to fit our metadata into this schema with some minor re-mapping of our Dublin Core fields. Here are the fields we are using differently:
Feel free to follow up with me or our metadata specialist, Belinda Egan if you need more details or examples!
And my answer to both of your questions above Adrian is yes - the scope and the required fields both seem reasonable to me.
(1) I reviewed the scheme with our Metadata Librarian. We feel the scheme will work for our needs.
Regarding the date field, we are glad to hear that there will be descriptive and normalized forms of the date. We'd advocate for defining what standard (ISO?) will be used for normalized dates and providing clear instructions and examples for the normalized dates.
Regarding the publishers field discussion, will UCLDC maintain the authority list that participants would use?
(2) The required fields as proposed are acceptable to us. We think that copyright should be required for the discovery and delivery systems, but not for DAMS.
ok, just figured that the DAMS widget "List" is a fairly static list vs. a dynamic one - see "Vocabulary schema" under "Nomenclatures used in the specification" on the "Metadata scheme" page.
Here are UCLA's suggestions, which repeat some of the above!
Suggest that Alternative Titles, Descriptions, and Related Resources be repeatable fields. In each case the contents can be of different types and it's nice to distinguish between them, even if only through visual separation in the display.
Also suggest that Date be a required field, even if only to the century. It will help users browse and find relevant resources, and also help them make sense of things they find.
1) In terms of the scope of digital object metadata scheme, one of the needs we have for a DAMS is management and re-use of assets (internal), so the more discovery-focused scope fits only part of our use case. Looking at more narrowly at discovery and access, however, as well as sharing, the scheme seems sufficient for those applications.
As for the specific data field definitions and mappings, I agree with much of what has already been noted, so will leave further discussion of the elements for when we dive into those more specifically.
2) On the review of the Obligations/required digital object metadata fields, it seems the following should be required in the two instances (obligation for valid object and obligation for publication):
- Date (oblig-valid/oblig-pub)
- Language (oblig-pub)
- Title (oblig-valid/oblig-pub)
- Type (oblig-valid/oblig-pub)
Thank you for reviewing the draft UCLDC metadata scheme, and for your feedback and input -- and sorry for the late follow-up. I'm compiling everyone's comments into a summary, and will post this along with responses to specific questions and proposed changes to the scheme.