|
Annual reports Directory Presentations Production statistics |
NCSU Libraries Core 1.0 metadata element set best practicesIntroductionDescription and digitization projects at the NCSU Libraries have adopted a number of specialized metadata schemas, tailored both to the resource being described and to the needs of the user population the particular repository serves. Granularity of the resulting metadata varies considerably between general schemas, such as Dublin Core, which was designed for both assignment and retrieval by generalists, and schemas that demand a more specialized level of knowledge and/or that are tailored to particular types of data (geospatial, image, archival materials). While specialists mining large repositories such as the Libraries' geospatial data or SCRC's archives and manuscripts collection will continue to demand the granularity afforded by FGDC's Content Standard for Digital Geospatial Metadata (CSDGM) or Encoded Archival Description (EAD), there is also a need to promote general discovery of these resources through a more interoperable schema. The NCSU Libraries Core element set, modeled after Dublin Core, was defined by the Libraries' Digital Collections Technical Oversight Committee through discussions held over the course of 2006. The impetus for creation of this schema was to provide a compact standard which could be populated automatically using appropriate crosswalks to other, more specialized, schemas. Thus, we do not expect that content providers or catalogers will typically code directly into NCSU Core. Yet, this simple element set should be able to identify resources across all repositories, with the potential to lead users to a more appropriate tool for fine tuning their search when needed. The purpose of the NCSU Libraries Core element site is:
DefinitionsA schema is a set of rules or standards defining the structure, content, and semantics to which a document must conform to be considered valid. Examples of schema in use at the NCSU Libraries include: CSDGM, Dublin Core, EAD, METS, MODS, TEI Header, VRA Core, and of course, MARC21. A resource is the expression of a work being described. This could be an oral history, a letter, a painting, a flying buttress from a cathedral, or a photograph of a basketball coach. An element is a descriptive category of information about the resource, equivalent to a field in a database or a column header in a spreadsheet. Examples of elements include titles, creators, dates, and so on. NCSU Core consists of a set of ten elements. Elements may have attributes and/or qualifiers, defined below. All of the elements used to describe a resource together make up a record, equivalent to the same concept within a database. An element can be repeatable if allowed within the framework of the schema. This means that more than one value can be assigned to an element, as when an expression represents the work of several writers, architects, or verbal informants. In database parlance, this is expressed as a many to one relationship between elements and records. Required means that a value must be assigned to that element before the whole record can be considered as valid. In some cases, this is conditional on availability/applicability or on the association of a digital object to the record. Attributes may be assigned to elements, describing particular qualities or characteristics of that element that are useful to separate out, either for action by the application displaying the metadata, or to format element data for display. For example, "url" is a particular type of location that allows one to link out of the record to the described resource. "Role" defines a creator's relationship to the expression being described. Metadata elementsAdministrative metadata<collection>Use for: Collection identifies a group of materials with some unifying characteristic or the holdings of a repository, either digital or analog. Best practice: Use a controlled vocabulary for the collection name, for consistency sake. An authoritative listing of NCSU Libraries repository names resides at: http://www.lib.ncsu.edu/cataloging/metadata/NCSUcoreVocab.html#collection. Institutional context for the collection is provided by the location element, described below. Repeatable: yesRequired: yes Attributes: none Dublin Core element: publisher MARC equivalents: 710, 856$u Values source: Examples:
<identifier>Use for: The identifier element is used to provide access to any numeric or alpha-numeric string that may be associated with a given resource. This may be a local number, such as a manuscript or accession number, or it may be a standardized number, such as an International Standard number (ISBN, ISSN), a Digital Objects Identifier (DOI), or Universal Resource Identifier (URI). Best practice: With the exception of local numbers, the identifier should be unique within its type. Where no other identifier is available, the field will contain the URI. Repeatable: yes; element is repeatable; type attribute is not
Examples:
<location>Use for: Location can refer either to the physical location of the repository, generally "North Carolina State University. Libraries" for most resources described by this schema, or to the address on a server where the object resides (its URL). Best practice: We will use the Library of Congress name authority file (http://authorities.loc.gov) to determine form of name. Names not in the NAF should be established according to the Anglo-American Cataloging Rules, 2nd ed. rev. An authoritative listing of NCSU Libraries physical location names resides at: http://www.lib.ncsu.edu/cataloging/metadata/NCSUcoreVocab.html#location. Repeatable: yes Examples:
<rights>Use for: Rights defines the legal status and ownership of the resource being described in a textual statement which can be presented with the description to let potential users know of any restrictions that might apply to the material. Best practice: These statements should be given in the form: Rights status. Reproduction/use restrictions. Further information. An authoritative listing of NCSU Libraries rights statements resides at: http://www.lib.ncsu.edu/cataloging/metadata/NCSUcoreVocab.html#rights Repeatable: no Examples: Default: Rights status not known. Reproduction and use of this material may be restricted. For general information see [location/URL]
Descriptive metadata<creator>Use for: The creator should be the person or corporate body responsible for the intellectual effort of creating the original work or expression, rather than the effort in creating the manifestation or surrogate of that expression. In the case of artistic photography, however, the photographer may be considered the creator of the work, even where the image may be of an object that might itself be considered a work or expression of yet another creator. Best practice: Use a controlled vocabulary appropriate to the subject matter, such as the Library of Congress name authority file or the Getty Research Institute's Union list of artist names, to standardize form of name. In the absence of a match in one of these sources, use the Libraries' public catalog to try to establish names. When establishing new names, use Anglo-American cataloging rules, 2nd ed., rev. as the basis for formulation. This element should be applied somewhat liberally to provide access to persons or agencies heavily associated with the resource described. Repeatable: yes Values source (roles): Examples:
<date>Use for: Dates associated with the creation of the content. Best practice: Since many schemas that are mapping to this element will include both a start (earliest) and end (latest) date, use a slash to separate these dates. For approximate or uncertain dates, set attribute to "Y" to enable "ca." to appear before date when displayed. If date or dates are exact, then no attribute is required. Use dates formulated according to ISO 8601, e.g. YYYY-MM-DD, dropping unneeded time segments from the right end as appropriate. Repeatable: yes Examples:
<description>Use for: Use description for textual information which would be helpful to users attempting to discern the usefulness of a resource to their research needs. This might include abstracts, summaries, table of contents, description of style, materials, and/or techniques used, aspect data, and brief points concerning the significance of the resource. Best practice: Best practice would be to provide a brief synopsis or abstract of the document, image, or object. An authoritative listing of NCSU Libraries description types resides at: http://www.lib.ncsu.edu/cataloging/metadata/NCSUcoreVocab.html#desctype Repeatable: yes Examples:
<itemtype>Use for: Itemtype defines the genre or resource type of the object to enable search filtering. Best practice: This element should be populated from the DCMI type vocabulary, a controlled listing of genre types. It may be automatically populated, based on characteristics of the repository. Repeatable: no Examples:
<subject>Use for: Use subject to include keywords or phrases which describe the subject content of the resource and that would be most useful to searchers seeking resources by topic. Best practice: Wherever possible, use a controlled vocabulary, such as LCSH, AAT, TGM, etc. to ensure collocation of similar resources within a single, or multiple, repositories. Repeatable: yes
Examples:
<title>Use for: The title consists of a word or phrase that constitutes the name by which the described resource or object is usually known. Use type attribute for other titles that might be associated with the resource, such as series title, translated title, or parallel title. Best practice: Choice and format of the title should be governed by a content standard appropriate to the collection within which the resource dwells. The default will be Anglo-American cataloging rules, 2nd ed., rev., but other guidelines, such as Describing archives: A content standard (DACS) or Cataloging cultural objects (CCO) should be used to describe resources within their scope. Works lacking title should have a suitable descriptive statement supplied, based on these content standards. Repeatable: yes Examples:
Revision date: 12 August 2011. |
