Implementation Approach

Data managers tend to be either technically literate scientists or scientifically literate computer specialists. Creating correct metadata is like library cataloguing, except the creator needs to know more of the scientific information behind the data in order to properly document them. Don't assume that every professional needs to be able to create proper metadata. They may complain that it is too hard and they may not recognise the benefits. In this case, ensure that there is good communication between the metadata producer and the data producer; the former may have to ask questions of the latter to collaboratively develop adequate documentation.

The form for maintaining metadata will depend on a number of factors:

• the size of the data holdings,
• the size of an organisation and
• the patterns of data management within an organisation

Indeed many organisations will start with a basic audit of their data holdings that will alert them of the vast wealth of data that they possess and where it is being used, replicated or improved across the organisation. As the data holdings become larger and the access to the data becomes distributed, then organisations would look at more advanced methods for maintaining metadata of their data holdings. These advanced tools may consist of commercial or self-developed forms based systems that may also form part of the operational GI systems to extract aspects of the metadata automatically from the data itself.

How does one deal with people who complain that it's too hard? The solution in most cases is to redesign the workflow rather than to develop new tools or training. People often assume that data producers must generate their own metadata. Certainly they should provide informal, unstructured documentation, but they may not need to go through the rigors of fully structured formal metadata. For scientists or GIS specialists who produce one or two data sets per year it may not be worth their time to fully learn a complex metadata standard. Instead, they might be asked to fill out a less- complicated form or template that will be rendered in the proper format by a data manager or cataloguer who is familiar (not necessarily expert) with the subject and well-versed in the metadata standard. If twenty or thirty scientists are passing data to the data manager in a year, it is worth the data manager's time to learn the complex metadata standard. With good communication, this strategy complements the existing combination of software tools and training.

The metadata standard

The first data set documented is always the worst. The other aspect to "It's too hard" is that documenting a data set fully requires a (sometimes) uncomfortably close look at the data and brings home the realisation of how little is really known about its processing history.

"Insufficient time" to document data sets is also a common complaint. This is a situation in which managers who appreciate the value of GIS data sets can set priorities to protect their data investment by allocating time to document it. Spending one or two days documenting a data set that may have taken months or years to develop at thousands of dollars in cost hardly seems like an excessive amount of time.

These 'pain' and 'time' concerns have some legitimacy, especially for agencies that may have hundreds of legacy data sets which could be documented, but for which the time spent documenting them takes away from current projects. At this point in time, it seems much more useful to have a lot of 'shortcut' metadata rather a small amount of full-blown metadata. So what recommendations can be made to these agencies with regard to a sort of 'minimum metadata' or means to reduce the documentation load?

In some operations, small amounts of metadata, or "notes" are collected sporadically during the data processing flow. These hints can then be assembled more readily later into a clear statement of the history and processing of the dataset. This can present a less daunting task at the end of a project as most of the details are already documented, a little at a time. Increasingly, GIS and image processing software are capable of collecting and reporting quantitative metadata that can be filled-in for the user rather than expecting human input. These procedures can amount to significant savings in overall time and effort over a single manual metadata preparation process at the conclusion of a project.

Don't invent your own standard. Select a supported international standard wherever possible. Try to stay within its constructs. Subtle changes from an international standard such as collapse of compound elements may be costly in the long run - you won't be able to use standard metadata tools and your metadata may not be directly exchangeable or paresable by software.

Don't confuse the metadata presentation (view) with the metadata itself. There is a temptation to lump form and content into the same bin (e.g. "What I see in my database is what I print"). However, the ability to differentiate the contents of the metadatabase (the columns or fields) from its presentation (writing formatted reports) is now commonplace in desktop database software packages. This allows users to consider more flexibly how to present what information.

There are typically three forms of metadata that should be recognized and supported in systems: the implementation form (within a database or software system), the export or encoding format (a machine-readable form designed for transfer of metadata between computers), and the presentation form (a format suitable to viewing by humans). By recognizing the connections between these dispositions of metadata, one can build systems that support mission requirements, standard encoding for exchange, and permit many "report" views of the metadata to satisfy the needs and experience of different user constituencies.

The Extensible Markup Language (XML) provides two solutions to this metadata problem. First, it includes a capable markup language with structural rules enforced through a control file to validate document structure. Second, through a companion standard (XML Style Language, or XSL), an XML document may be used along with a style sheet to produce standardised presentations of content, allowing the user to shuffle field order, change tag names, or show only certain fields of information. Used together XML and style sheets allow for a structured exchange format and for flexible presentation. Thus, a metadata entry can be rendered in many ways from the same, single structured encoding.

XML is a widely accepted encoding methodology with international software support. It is supported by a lot of software, both free and commercial. However, the metadata-producing community doesn't have much experience using it to solve problems yet. Through reference implementations of software and experimentation, local Spatial Data Infrastructures can share their successes and failures in applying this new technology to fullest community benefit.

Consider data granularity. Can you document many of your data sets (or tiles) under an umbrella parent? Prioritise your data. Begin by documenting those data sets that have current or anticipated future use, data sets that form the framework upon which others are based, and data sets that represent your organisation's largest commitment in terms of effort or cost.

Document at a level that preserves the value of the data within your organisation. Consider how much you would like to know about your data sets if one of your senior GIS operators left suddenly in favour of a primitive lifestyle on a tropical island.

The various metadata standards are truly content standards. They do not dictate the layout of metadata in computer files. Since the standard is so complex, this has the practical effect that almost any metadata can be said to conceptually conform to the standard; the file containing metadata need only contain the appropriate information, and that information need not be easily interpretable or accessible by a person or even a computer.

This rather broad notion of conformance is not very useful. Unfortunately it is rather common. To be truly useful, the metadata must be clearly comparable with other metadata, not only in a visual sense, but also to software that indexes, searches, and retrieves the documents over the Internet. To accomplish this, there are several encoding standards that specify the content of a metadata entry for exchange between computers, For real value, metadata must be both parseable, meaning machine-readable, and interoperable, meaning they work with software used in services such as the FGDC Clearinghouse through OpenGIS Catalogue Services. Both the FGDC and the ISO 19115 efforts have encoding standards to assist in this effort.

Parseable

To parse information is to analyse it by disassembling it and recognising its components. Metadata that are parseable clearly separate the information associated with each element from that of other elements. Moreover, the element values are not only separated from one another but are clearly related to the corresponding element names, and the element names are clearly related to each other as they are in the standard.

In practice this means that your metadata are usually arranged in a hierarchy, just as the elements are in the standard, and they must use standard names for the elements as a way to identify the information contained in the element values.

Interoperable

To operate with metadata service software, your metadata must be readable by that software. Generally this means that they must be parseable and must identify the elements in the manner expected by the software.

There is a general consensus that metadata should be exchanged in Extensible Markup Language (XML) conforming to a Document Type Declaration (DTD). In the World Wide Web Consortium, there is progress on developing successor to the DTD, known as XML-Schema. Support for XML in parsing and presentation solutions is widespread on the Web and is presumed in current draft standards of the ISO TC 211 and OpenGIS specifications.

When searching for information, the inquirer may not find any references based on the words used to describe the information sought. This problem can be overcome by use of a thesaurus. In the context of metadata and other electronic documents, a thesaurus is a tool for the organisation and retrieval of information in electronic materials. It allows data to be indexed and retrieved in a consistent manner. It permits the display of hierarchies of concepts and ideas, leading the user, whether as indexer or information seeker, to define his or her search in terms that are most likely to lead to the retrieval of relevant information.

For example, it will allow improved information retrieval by providing successful searching on synonyms - if the user enters the term "farming" the thesaurus will find the term "agriculture". Hierarchies of meaning can be shown - the term "Great Britain" may retrieve data indexed with that term but could also expand the search to retrieve data on England, Wales and Scotland which have been indexed under those three terms. The term "meals on wheels", although in a hierarchy of terms related to food, could also be linked to concepts relating to personal social services and to the different categories of recipients and a user can elect to follow and retrieve these related terms. Consistent searching for metadata will be achieved if all those who prepare metadata use the same thesaurus.

• The Cookbook authors recommend that you prioritise your data.

• The Cookbook authors suggest collecting metadata a little at a time.

• The Cookbook authors recommend the development of a coordinated spatial data product identifier system within the GSDI

• The Cookbook authors suggest that research into a common thematic classification system for geospatial data be conducted by the Technical Working Group of the GSDI.