Section B: Creating Metadata Records

Who needs this information?

Managers, metadata managers and metadata authors

Purpose of this section

Here we introduce the NZGLS metadata scheme elements, and rules and principles that apply to NZGLS as a whole.

B.1. The NZGLS Metadata Elements

An element is the basic unit of metadata information.

The first part of the element is its "name" which specifies the property being described, such as 'title' or 'creator'.

The second part of the element - only used when needed - is the name of a vocabulary or scheme, such as an encoding scheme that provides rules for formatting the information.

Also if needed, an attribute tag can be included - for example, to specify the language of a resource.

The last part of the element is "value", the actual information.

B.1.1. Derivation of NZGLS elements

The 19 NZGLS elements are defined in the NZGLS Metadata Element Set. NZGLS is based on:

• the Dublin Core Metadata Element Set (DCMES) of 15 descriptors documented on the Dublin Core Metadata Initiative (DCMI) website at http://dublincore.org/documents/dces/ and issued by the International Organisation for Standardisation as ISO 15836 : 2003; and
• the Australian Government Locator Service (AGLS) Metadata Element Set, formalised as AS 5044 : 2002.

NZGLS extends the Dublin Core Metadata Element Set. It contains 4 additional elements (Audience, Availability, Function and Mandate) and a number of different qualifiers that enable it to describe more categories of resources and allow richer description of resources. Nonetheless, it is entirely compatible and interoperable with the Dublin Core Metadata Element Set.

The elements are intended to describe three aspects of resources:

Aspect	Elements
Intellectual property	Contributor, Creator, Mandate, Publisher, Rights
Content	Audience, Coverage, Description, Function, Relation, Source, Subject, Title, Type
Characteristics of this instance of the resource ("instantiation")	Availability, Date, Format, Identifier, Language

B.1.2. NZGLS Rules on which elements must be included (obligation)

Five elements must be in any NZGLS record for any type of resource:

• Creator
• Function
• Subject
• Title
• Type - with the refinement "category".

Three other elements are conditional, i.e. mandatory for some types of resources:

• Availability - mandatory element when describing an agency, service, or offline document; optional when describing an online document
• Identifier mandatory for online resources, otherwise recommended - where available. Not used for services.
• Publisher - mandatory for all documents, but not applicable for services or agency resources.

Five further elements are recommended and should be included where possible:

• Audience
• Date
• Description
• Language
• Mandate

The other six elements are optional and should be included when they will be useful for finding the resource, but for some types of resources they will not be appropriate.

B.1.3. Element definitions

Full and authoritative specification of the elements is given in the NZGLS Metadata Element Set; this table provides a summary of the definitions.

Element	Element definition
Audience	A class of entity for whom the resource is intended or useful.
Availability	How the resource can be obtained or contact information for obtaining the resource.
Contributor	An entity responsible for making contributions to the content of the resource.
Coverage	The extent or scope of the content of the resource.
Creator	An entity primarily responsible for making the content of the resource.
Date	A date associated with an event in the life cycle of the resource.
Description	An account of the content of the resource.
Format	The physical or digital manifestation of the resource.
Function	The business function of the organisation to which the resource relates.
Identifier	An unambiguous reference to the resource within a given context.
Language	A language of the intellectual content of the resource.
Mandate	A specific warrant which requires the resource to be created or provided.
Publisher	An entity responsible for making the resource available.
Relation	A reference to a related resource.
Rights	Information about rights held in and over the resource.
Source	A reference to a resource from which the present resource is derived.
Subject	The topic of the content of the resource.
Title	A name given to the resource.
Type	The nature or genre of the content of the resource.

B.2. Qualifiers for Each Element

B.2.1. What are qualifiers?

Qualifiers give metadata authors the ability to refine the semantics of an element and to add precision. There are two types of NZGLS qualifiers:

• Element refinements. These give information about how the semantics (meaning) of an element has been narrowed.
• Encoding schemes. These indicate how the value (specific content) of an element should be interpreted.

B.2.2. What are element refinements?

Element refinements specify the relationship of the element value to the resource itself, but with a more restricted scope than of the unqualified element. For example, the element Coverage can refer to legal or administrative scope (jurisdiction), to the geographical scope (spatial), or to the period of time covered by the resource (temporal). So, element refinements enhance the meaning of the element.

The NZGLS element refinements are described, in this guide, under each element for which they may be used. Element refinements will continue to be added as required. Please check the current version of the NZGLS Metadata Element Set on the NZGLS website (http://www.nzgls.govt.nz/) for updates.

It is possible to add refinements required by your agency. Do this in accordance with the Dublin Core design principles [refer to Section B.10], and the NZGLS maintenance agency should be advised.

B.2.3. What are encoding schemes?

Encoding schemes show how a given value is to be interpreted by referring to either:

• controlled vocabularies or thesauri, e.g. Functions of New Zealand (FONZ), or
• rules for constructing or encoding values, e.g. ISO 8601: 2000 for dates.

Encoding schemes identified as best practice are listed in the detailed instructions for each element. In some cases specific encoding schemes may be mandatory, e.g. use of the Functions of New Zealand (FONZ) and the Subjects of New Zealand (SONZ) thesauri are mandatory for metadata prepared for use by the Government Web Portal.

Even when a scheme or thesaurus is compulsory, other encoding schemes may also be used, and a particular agency or sector might need to create or adapt other schemes. Metadata based on this standard will specify the encoding scheme used for any element where this is appropriate. The NZGLS maintenance agency should be advised of different encoding schemes people are using in order that each scheme can be given a consistent reference.

B.2.4. Controlled language and thesaurus terms

A thesaurus is a type of controlled vocabulary that is used to help ensure that things are described consistently. This makes it easy to create metadata records, and it makes high quality, efficient information retrieval simpler.

A Thesaurus Advisory Group (TAG) manages the use of thesauri in NZGLS. This advisory group is responsible for:

• An all-of-government subject thesaurus: Subjects of New Zealand (SONZ)
• An all-of-government functions thesaurus: Functions of New Zealand (FONZ)
• An Audience controlled vocabulary
• The process for registering and assessing terms that agencies request be added to the thesauri.

Other thesauri may also be used if they are registered with the NZGLS maintenance agency. This will generally only be necessary for specialist areas, such as scientific terms.

B.3. Using Elements and Qualifiers

• Use optional elements where the inclusion of that information will help the user find or evaluate the likely usefulness of the resource.
• Use encoding schemes or terms from controlled vocabularies to express element values, where these are available.
• Use qualifiers where they help provide better description of the resources, or to make online searching more precise than would be possible without them.

B.4. Extending NZGLS

The following need to be observed by those wishing to extend NZGLS:

1. Any extension of the element set must not alter the basic semantics of any of the 19 NZGLS elements.

2. Additional qualifiers should not conflict with the semantics of the NZGLS parent element, although they may enrich or enhance it.

3. Mandatory elements in NZGLS must remain mandatory in the new set.

4. The 'Dumb-Down Principle'. A client (e.g. a person or software) should be able to ignore any qualifier and use the description (element content) as if it were unqualified. The remaining element value without the qualifier should continue to be generally correct and useful for discovery and other management purposes.

5. Notify the NZGLS maintenance agency.

B.5. One Metadata Record for Multiple Resources

Dublin Core (the standard that NZGLS is based upon) requires each manifestation (or version) of a resource to be described by a separate metadata record.

However, the New Zealand Government uses NZGLS is to describe resources in the way most useful to the public. This may mean creating a single record for a group of resources - even though each could be described individually - if the single record would be better for discovery purposes. As general guidance, the wider is the difference between varieties/versions of a resource, the more appropriate it is to have individual metadata records. [Refer also to Section A.6.3.] Guidance on specific circumstances is:

For a service, create one record and list the different channels/availabilities (e.g. online, over-the-counter) under Availability.

For online versions of the same document:

• When, different versions (say HTML and PDF) are accessible from one web page, you may opt to create just one metadata record and include the different values in Format.
• Where an online resource is available from one web page in more than one language, create one metadata record and include as many alternative titles as there are versions, as well as include multiple values under Language, and, if appropriate, Audience.

In either case of multiple versions of an online document, available for a single web page, use Availability to direct users to that web page, rather than trying to use Identifier for each version.

Where there are physical and digital versions of one document ideally create separate metadata records for the physical and the digital. You can also use the Relation element to link them. Alternatively, provide the URI of the digital version in Identifier, and access information for the physical copy in Availability.

B.6. Updating Metadata

This situation is mostly likely to arise with web pages whose content or metadata gets get updated. Metadata creators are responsible for deciding when a change is just a modification (use, say, Date.modified), and when changes to a resource are more significant so they actually create a new resource. This will usually require its' own metadata.

For example, adding an additional Subject term might reflect a minor extension of the item (just a modification) or simply be better description. Replacing the Subject terms with others is because the content has been rewritten, or "refocused" would be a major change and a new metadata record might be more appropriate.

So, where a document is revised and there is significantly new content/metadata to that of a former version, the best way is to create a new metadata record and have the metadata record archived for the former version.

Other elements that would potentially flag major changes are Audience, Creator, Description, Function, Title, and Mandate.

B.7. Distinguishing Between Elements

B.7.1. The Difference Between Function and Subject

Although both Function and Subject are mandatory it is important to understand the difference between the two concepts.

A Function classification describes why a resource exists, or the government business or provider function that caused the resource to be created. It describes the context.

Subject classification describes what the resource is about. It describes the content.

The Functions of New Zealand (FONZ) provides a high level description of all government functions. These high-level terms provide a good context for finding resources - because they describe business functions. For discovery purposes, services or resources will be related to a business function at the second or third level of the thesaurus. FONZ includes non-preferred terms with pointers to the preferred synonym.

The Subjects of New Zealand government thesaurus (SONZ) provides a set of terms to cover the subjects addressed by Government, at an easy-to-find level. SONZ also includes non-preferred terms with pointers to the preferred synonym.

B.7.2. When to Use Audience, Coverage and Subject

Take care to distinguish between:

• people for whom a resource has been especially presented (use Audience); and
• what is or who is described in a resource (use Subject).

For example, a report or dataset may be about "Occupational Health" (Subject), but intended for use by the Rural community (Audience).

Coverage is like a secondary dimension of Subject adding further limits. It relates to the content of a resource where the scope is limited to part of a range (e.g. of place and/or time aspects).

Coverage is not used to describe the intended users of the resource. Use Audience for this.

For services, use:

• Coverage for the area over which the service applies (e.g. the geographical area where a licence is needed or is valid), and
• Availability for the point(s) at which the service is delivered (e.g. the physical or virtual addresses where a licence can be obtained).

B.8. Analysing and Describing Resources

B.8.1. Examining the resource

Do not read everything in or about a resource. Concentrate on what is likely to be the most informative, or scan it. Try not to spend more than five minutes analysing the content of a resource.

B.8.2. How many elements and terms should be used?

Use the mandatory elements. Only use other terms if they add to the "discoverability" of the resource or tell the searcher something useful.

B.8.3. Use the most specific term available

When a controlled vocabulary of terms is available, use the most specific of the terms in the vocabulary. Select the term that most accurately reflects the aspect of the resource being described. This applies when selecting terms from hierarchically constructed thesauri. For example, a resource on "paid holidays" should not have the Subjects of New Zealand (SONZ) broad subject term: "Employment Relations" unless the resource also has a significant discussion on more general aspects of employment relations. It is better to use a narrower SONZ term, such as Leave (Employment).

When describing New Zealand Government resources, use the Subjects of New Zealand (SONZ) and Functions of New Zealand (FONZ) thesauri made available. These are mandatory for metadata for Government Web Portals.

A resource that is created in response to two business functions should be given two Function terms. A resource in which two subjects are covered should be given two Subject terms. Identify the major subject(s) of the resource and put the most important concept first. [See the relevant Element sections for guidance on how many terms to give.]

If no terms exist for the concept, choose the term that most closely represents the concept. It might be useful to look up a similar resource and check its metadata.

B.8.4. Facilitate efficient searching

Searchers want the search results to be relevant. So, do not use values that represent only very minor content points. They will not be useful to the searcher. Do not create subject metadata for concepts that are mentioned rather than discussed.

For example, do not use the term "history" for a resource that only includes a small amount of introductory background history to the main subject under discussion.

B.8.5. Do not editorialize

Metadata describes resource content; it does not evaluate or comment on that content.

B.8.6. Individuals and organisations

If the subject of the item is a person or an organisation, use the same form of the name that you would use if they were the creator. Note that this subject may not be the creator themselves, so do not just automatically repeat the name from the Creator element.

B.8.7. Groups of people

Use a combination of Subject terms whenever describing a specific group of people rather than just using a single broad term. For example, "Women" and "Self employment" is more specific than "Women".

If the resource is intended for one of these groups as a target audience, this should go into the Audience element instead.

B.9. Role in Government Web Portals

For information on how metadata is used in particular web portals, contact the portal operators or the E-government Unit of the State Services Commission.

B.10. Dublin Core Principles and Goals

As explained in Section A.2.3, NZGLS is based on Dublin Core. Because of this, the key principles of Dublin Core have also guided development of NZGLS and have implications for its implementation. These principles and goals are described in Dublin Core documents such as the usage guide but are summarised here for your convenience.

B.10.1. Dublin Core principles

The One-to-One Principle.

In general Dublin Core metadata describes one manifestation or version of a resource, rather than assuming that manifestations stand in for one another.

For instance, a jpeg image of the Mona Lisa has much in common with the original painting, but it is not the same as the painting! As such, describe the digital image as itself, most likely with the creator of the digital image as Creator or Contributor - rather than the painter of the original Mona Lisa. The relationship between the metadata for the original and the reproduction is part of the metadata description. It assists the user in determining whether they need to go to the Louvre for the original, or whether his/her need can be met by a reproduction.

The Dumb-down Principle.

The qualification of Dublin Core properties is guided by a rule known colloquially as the Dumb-Down Principle. According to this rule, a client should be able to ignore any element qualifier and use the value as if it were unqualified.

While this may result in some loss of specificity, the remaining element value (minus the qualifier) must continue to be generally correct and useful for discovery. Qualification is therefore supposed only to refine, not extend the semantic scope of a property.

Appropriate values.

Best practice for a particular element or qualifier may vary by context, but in general an implementer cannot always predict that the interpreter of the metadata will always be a machine. This may impose certain constraints on how metadata is constructed, but the requirement of usefulness for discovery should be kept in mind.

B.10.2. Dublin Core has as its goals:

Simplicity of creation and maintenance

The Dublin Core element set has been kept as small and simple as possible. This allows a non-specialist to create simple, descriptive records for information resources easily and inexpensively. It also ensures effective retrieval of those resources in the networked environment.

Commonly-understood semantics

Discovery of information across the vast commons of the Internet is hindered by differences in terminology and descriptive practices from one field of knowledge to the next. The Dublin Core can help the "digital tourist" -- a non-specialist searcher -- find his or her way by supporting a common set of elements, the semantics of which are universally understood and supported.

International scope

The involvement of representatives from virtually every continent in The Dublin Core Element Set has ensured that the development of the standard considers the multilingual and multicultural nature of the electronic information universe.

Extensibility

While balancing the needs for simplicity in describing digital resources with the need for precise retrieval, Dublin Core developers have recognised the importance of providing a mechanism for extending the DC element set for additional resource discovery needs.

[ Previous | Next ]