Australian Government Locator Service Implementation Plan
A Report by the Australian Government Locator Service Working Group (AGLS WG)
December 1997
Table of Contents
2.2 The importance of metadata in the business environment
3. Implementation Plan for Australian Government Locator Service Schema
3.2 What Agency Resources need to be Described?
Australian Government Locator Service Implementation Plan
In order to implement the Australian Government Locator Service, the Working Group recommends that the Navigation Issues Working Party of the Government Technology and Telecommunications Conference:
This plan represents the Commonwealth’s position for an Australian Government Locator Service (AGLS) formerly termed the Australian Government Information Locator System or AusGILS. The description and recommended activities which follow in the body of this paper are the direct result of the Chief Government Information Officer’s (CGIO’s) request to the Australian Archives to design an implementation plan for the then named Australian Government Information Locator System.
The AGLS initiative, represents one of the three technical access architecture recommendations of the IMSC report (Recommendations 4, 5 and 6). A search engine and the Australian Government’s Entry Point make up the three projects. These latter two activities are being dealt with independently by the Search Engine Working Group and by a consultancy to provide a navigable common entry point. The Australian Archives in response to the CGIO’s letter, set up and chaired an AusGILS Working Group. This paper is the result of their work.
This Plan is further underpinned by several influential statements emanating from the prime Minister’s recent industry policy announcement. Identifying Government as a leading edge user, the Prime Minister set down six clear innovations to "get Australia online". Among the six initiatives are:
These activities underline the critical nature of our ability to describe and locate information reserves. In technological and business terms one of the answers to this need today is in the use of metadata.
The IMSC Technical Group analysed available metadata sets to assess their suitability for making government information visible and retrieval in an Internet environment. Criteria against which potential metadata sets were evaluated included:
Metadata sets evaluated against these criteria included traditional descriptive metadata standards such as MARC, the Commonwealth Records Series System (CRS) and other developed schemes already in use for this purpose such as Text Encoding Initiative (TEI)
headers in Standard Generalised Markup Language (SGML), and IAFA Templates and Encoded Archival Description (EAD). The two standards most close to the criteria specified were the Dublin Core and the US Government Information Locator System (GILS) Core Elements. Due to the international uptake of Dublin Core as a defacto Internet metadata
standard and the poor reception within the US of the GILS initiative the Dublin Core was selected as the base metadata set meeting most of the selection criteria and a suitable base for AGLS. These findings were affirmed by the AGLS WG.
In a classical sense information professionals have always used metadata. It is with the advent of the Internet that our needs to describe and locate vast amounts of information have exploded upon us. Metatdata is a means of assigning descriptive tags to government information so that it is easily searchable and retrievable by clients from any electronic or online tool, be it an Internet connection through their home or business PC, via a public kiosk or by using a call centre as the middle access environment (the Government Information Centre is a good example of this environment). In non technical terms metadata then is information which describes information.
The advent of online communication, and the subsequent expectations of government clients for access to publicly releasable government information, has spearheaded the uptake of business tools such as the Internet.
As well, the Government’s policies of applying shared systems suites such as records management systems, human resource management systems, financial management systems in an online environment necessitates a business driven, technology enabled approach to identifying and describing the vast amounts of information held by government agencies. This relates to information that agencies need to place online for access by their clients.
Thus the purpose of metadata is to assist in providing easy, efficient and effective access to government held (publicly releasable) information, to allow clients to refine their searches and meet their particular needs. This refinement is presently not fully available using current web tools.
2.2 The importance of metadata in the business environment
The aforementioned IMSC report and the current AGLS Working Group comparatively analysed a number of metadata set contenders prior to selecting the Dublin Core as the most appropriate to describe Australian Government information in a web environment. The metadata schema described in this paper therefore, is based on the Dublin Core rules with minor variations to suit Australian Government requirements.
The Working Group accepted the premise that any client, or customer approaching government does so in order to conduct business with government, much of this activity being transaction related. Users and clients, expect to find information quickly and receive resultant information and/or services from government relatively painlessly.
The costs to industry when conducting business with government in the past is infamous for its affect in terms of time and resources. Agencies such as Customs, the Australian Taxation Office, the Australian Bureau of Statistics have gathered significant market data to establish this fact well, enabling them to target relevant audiences to meet particular activities and to reduce costs to industry in particular.
Thus, the metadata element of the technical access architecture is an essential ingredient in the development and implementation of an efficient and effective government online business environment incorporating in addition to metadata:
International Governments as well as State Governments within Australia have proclaimed the Internet as being one of the major vehicles for current and future communication of government business. This principle (together with information management principles cited in the IMSC report) underpins the rationale and recommended activities of this Implementation Plan.
The Working Group has identified three key processes deemed critical to assist clients to access government information holdings:
To achieve this in an online environment we need information that assists the description, discovery and transaction processes - metadata will assist to achieve this outcome.
The use of the metadata attribute set specified under the subheading, ‘Implementation Plan for Australian Government Locator Service Metadata Schema’ (see also Recommendation 1, and Attachment A below), will:
In order to achieve these deliverables, there is a need to manage the change in business processes incumbent with the use of online technology. The essential element is to integrate the suggested changes into the fabric of government business operations. The ongoing business management aspects of the Australian Government Locator Service are acknowledged by Recommendation 2 of this Implementation Plan.
This recommendation provides scope for the development of a business case to support the use of a metadata attribute scheme complementing the remaining elements of the technical access architecture (the search engine and the Australian Government’s Entry Point). A business case will allow the full costing (both qualitative and quantitative) of the implementation of the metadata attribute set in Commonwealth agencies. The business case will cover the exploration of other important aspects such as the implications for government business - technical and resource imperatives including the collection, storage, management and access to government information.
Recommendation 2 of this Implementation Plan also focuses on the need to better understand the deliverables. The Working Group considered a number of deliverables which would assist agencies even in their most fundamental of activities. Some major deliverables are:
Recent Government announcements about the online (or information) economy places in perspective the growing needs and expectations of both government and its clients. The realisation of the technical access architecture is dependent on government agencies being able to make the transition from a hard copy environment into the electronic communication environment. This environment no longer sits on our front door step, it is firmly placed in our front room, and metadata is one of the building blocks.
3. Implementation Plan
for an Australian Government Locator Service
Here are the specific steps needed to implement metadata in the Australian government.
The Internet is an international communication tool and as such the metadata set used by Australian governments must be consistent with that used internationally. Dublin Core is the emerging metadata standard used widely in the Internet environment. The Australian Government Locator Service (AGLS) is based on agencies creating metadata records that describe and show the location of government information resources. The metadata record may point to information holdings on an agency web site, to resources located elsewhere on the Internet or may point to information resource holdings of an agency held external to the Internet environment. The information resources held externally to the Internet environment, and to which metadata records point or link, may be printed publications, helpdesk details directories or databases and call centres.
The metadata record, pointing to these resources, will be composed of metadata elements from within the metadata set agreed to by the AGLS Working Group. The Working Group agreed that a metadata set based on the Dublin Core plus two element extensions would be appropriate. The accepted metadata set has the following:
| Title | Creator |
| Subject | Description |
| Publisher | Contributor Date |
| Type | Format |
| Identifier | Source |
| Language | Relation |
| Coverage | Rights |
| Proposed extensions: | |
| Function | Availability |
3.2 What Agency Resources are to be
Described?
The thrust of the IMSC report and its supporting recommendations were that if government wished to transact business with its constituents in an online and interactive environment via the Internet, users need to be able to easily identify publicly available government information and transactional services.
Users expect access to government information services and information resources to occur quickly and effectively. For this to occur agencies need to identify those resources to be made visible and accessible in order to support agency client and business services. This is very much a business decision for each agency and tools such as agency Information Management Plan will be invaluable in making business decisions about the release of, access to and visibility of agency information resources.
Having decided what resources are to be made visible and whether they will be made accessible via the Internet, metadata records would be created to describe and locate those resources.
To create a metadata record, the AGLS metadata will need to be collected or assigned by agencies either manually or automatically. The more easily the metadata can be created and collected at point of creation of a resource or at point of publication the more efficient the process. Records keeping systems are ideally placed to collect metadata. Information collected in this way will form the basis of metadata records used to describe and locate agency information resources
Tools that are available for the creation of Dublin Core metadata
are:
The National Library of Australia, in its MetaWeb project is currently assessing these and other tools, with the view of adopting and/or enhancing them for the Australian metadata community. Simple extensions to the Dublin Core, as suggested in this paper, can be accommodated by the products above. The software could also be copied and configured by any department for in-house use.
Once metadata elements have been collected agencies need to make arrangements for its storage in such a way that Web search/retrieval tools can access the metadata. There are a number of metadata record storage options available to agencies. Four alternatives are:
The first mechanism utilizes the current technologies supportable by the World-Wide Web (WWW) and the Hyper-Text Markup Language (HTML). In this case, the metadata records become an integral part of the resource being described. The metadata records are included within HTML files using the HTML META tag. The syntax to support this was recommended by the Distributed Indexing/Searching Workshop in 1996 and available at <http://www.oclc.org:5046/~weibel/html-meta.html>
One drawback of this mechanism is that non-HTML resources must have a HTML description if they are to be described using AGLS.
It should be noted that with new versions of HTML, the syntactic requirements for the META tags change, and so the AGLS descriptions will need to be periodically updated. This should be taken into account for agencies that publish metadata using this mechanism. See <http://purl.oclc.org/metadata/dublin_core/syntax.htm.> for some of the new options for the META tags.
The third mechanism utilizes the database approach to information management. AGLS metadata records can be made available from a database that allows access via a common standard protocol. Such standards include Z39.50 and X.500.
This mechanism gives agencies more flexibility as the metadata is not kept as static records. The metadata can be made available in various syntaxes, which can easily be modified over time. In the first instance, the metadata records from the databases should support their native syntaxes.
The preferred mechanism, referred to in dot point three, is to store metadata records within agency Record Management Systems (RMS). Agency RMS’s will collect and hold significant volumes of metadata, including metadata as specified by AGLS. Agency RMS’s can provide the automatic facility to:
The underlying assumption of the above three mechanisms is that there exists a layer of technology that will gather and index the metadata (from any of the sources) and make this available to the Single Entry Point.
In the case of AGLS if metadata is either embedded within documents or is stored as a metadata record on the Internet, the search engines indexing the metadata must be Dublin Core aware.
If the metadata is stored in agency repositories, a standard interface to that repository is needed to allow for seamless searching. The predominant standard used Z39.50, allows for this seamless search mechanism across a number of remote or external databases, indeed the external database could be one holding the agency metadata. Z39.50 supports a series of ‘profiles’ in order to enable translation between the various databases. Recognising the value of querying distributed Dublin Core based databases via Z39.50, a number of organisations within these communities are exploring the feasibility of creating a specific Dublin Core profile.
Consideration should also be made for support for a common syntax across the mechanisms listed above. Such syntax is currently being developed in the WWW Consortium (W3C) Resource Description Framework <http://www.w3.org/Metadata/RDF/> and should be strongly supported when available in the near future.
4. Management arrangements
for implementation
The CGIO’s invitation to Australian Archives to be the lead agency to drive the AGLS initiative reflects the importance of the lead agency concept. This concept identifies the most appropriate agency whose expertise fits the perceived needs of the project to be completed. The criteria for a lead agency also identifies the ongoing management of the initiative where applicable.
The Working Group believes the ongoing management of the Australian Government Locator Service to be a principle element in the successful implementation of the technical access architecture - it being a key enabler for the achievement of the Government’s commitment to be a "leading edge user" of Internet technology by 2001 and of electronic transactions by 2000.
To ensure that the deliverables of the business case are achieved the Working Group also recommends that its role be extended to monitor the development and implementation of the AGLS across government agencies (see Recommendation 5 of this Plan).
Given the dimension of change that the implementation of a technical access architecture represents, there is a need to develop information, awareness and education initiatives to ensure successful delivery of business and technical outcomes (see Recommendation 3 of this Plan).
As part of the overall process of business based decision making incorporating marketing, education and implementation, the Working Group recommends that a trial of the Locator Service within select departments for 6 months should precede its government wide implementation (see Recommendation 4).
This trial will demonstrate:
However it is vital that the search engine and entry point initiatives of the access architecture be in place to fully enable the proposed trial to provide value added/benchmarked results, as an AGLS trial in isolation, will yield limited conclusions.
The semantics of the enclosed metadata set incorporates the discussion of the AGLS Working Group and draws heavily on the semantics and definitions of the various Dublin Core Working Groups, as at October 1997.
AGLS Metadata Attribution Set
Element 1: Title
Purpose
To name the resource.
Rules
This element is the assigned title or description of the resource. A title is a label that should convey, accurately and succinctly, the subject or nature of the business which is documented. It should provide sufficient information to allow users to make an initial decision on likely relevance. It should convey the most significant information available, including the general topic area, as well as a specific reference to the subject. In some cases a descriptive phrase might be appropriate. If greater precision is required, titles may be qualified by a scheme.
For an AGLS locator record the title is the officially assigned name for the system or aggregate being described. If the system or aggregate is known by an acronym, follow instructions in the Government Style Manual.
If the resource is a series within a recordkeeping system, the series title should be used and is the formal, official name of the series. The series title serves two main purposes
1. to distinguish the records being described from other records appearing under the same system of documentation
2. to convey as much information about the records as may assist a user to decide whether to look more closely at the records, at a fuller description of the records, or at documentation concerning the content of the records eg item lists.
Use of Qualifiers (DC = Dublin Core)
DC.Title (unqualified)
DC.Title.Alternative (used for any titles other than the main title including subtitles)
Use of Schemes
CRS System
Used for
( The AGLS Working Group has identified three key processes deemed critical to assist clients to access government information holdings, these being:
To achieve this in an online environment we will need information that assists the description, discovery and transaction processes - metadata will assist to achieve this outcome.)
Description, discovery
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 2: Creator
Purpose
To identify the organisation(s) or person(s) responsible for the creation of the resource and to place it in context of government.
Rules
This should be the name of the agency, as agencies can be creators, that is responsible for the intellectual content of the aggregate/collection whether the collection be in hardcopy form, be part of a recordkeeping system or part of another automated system. Often for AGLS locator records an agency would be the creator.
This could also be the person(s) primarily responsible for the intellectual content of the resource. For example, authors in the case of written documents and artists, photographers, or illustrators in the case of visual resources.
So that users can place retrieved material in the context of government the domain of the creator is important and needs to be discussed further. Should organisation(s) creators be qualified by the portfolio minister responsible and should person(s) creators be qualified by recording agency.
Use of Qualifiers
DC.Creator (unqualified)
DC.Creator.PersonalName
DC.Creator.CorporateName (includes conference name)
DC.Creator.PersonalName.Address (includes any type of address, email or otherwise
DC.Creator.CorporateName.Address
AGLS.AgencyRecording (new qualifier)
One suggestion of the AGLS Working Group was that we take out qualifiers and flag that authors can be personal or corporate. Also suggested that there is no need for email etc and discourage use or take out because of the volatility of addresses.
Use of Schemes
Government Directories
Archives’ Register of Agencies
USMARC
LCNAF (Library of Congress Name Authority File)
Where do we get our standard list of agency names, what directory - GOLD?
Used for
Description, discovery, transaction
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 3: Subject
Purpose
To specify the subject or topic of the resource using keywords that describe its content.
Rules
The central purpose of AGLS will be to help the public locate and access government information of possible interest or use. In order to be able to identify this material, there must be some indication in the AGLS core entry as to what the information resource is about. One option would be to rely on free text searching, but more precise results are desirable and could be obtained through the use of controlled vocabulary. In some cases it may be useful to include terms from two or more agency thesauri.
There may be cases where use of this element is redundant as the file title, document, photograph etc might already contain within its title some controlled vocabulary or keywords. However, if this is not the case, use of descriptors/keywords is recommended.
Use of Qualifiers
Mandate which classification scheme used.
Use of Schemes
Subject classification schemes
from DC Subelement Working Group
•LCSH (Library of Congress Subject Headings)
•MeSH (Medical Subject Headings
•AAT (Art and Architechture Thesaurus)
•LCNAF (Library of Congress Name Authority File): for names used as subjects
•DDC (Dewey Decimal Classification)
•LCC (Library of Congress Classification)
•NLM (National Library of Medicine Classification)
•UDC (Universal Decimal Classification
The above are the most frequently used. The scheme could point to the controlled list maintained by the Library of Congress in the USMARC Code List for Relators, Sources, Description Conventions, which includes many others (Part III: Classification Sources and Part IV: Subject/Index Term Sources; these documents are currently under revision for a new edition). Many locally defined thesauri or classification schemes are possible.
Used for
Discovery
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 4: Description
Purpose
To provide a textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources. This element describes why the information resource is offered and identifies other programs, projects and legislative actions wholly or partly responsible for provision of access to the information.
Rules
This element presents a narrative description of the resource. This narrative should provide enough general information to allow the user to determine if the resource has sufficient potential to warrant accessing the resource or follow up access links to the material. A concise note should be present in the locator record, including significant information not contained in other elements.
Agencies may not have the resources to add a descriptive note or abstract at item level hence this element at item level should not be seen as mandatory. However if an agency produces abstracts as a normal part of the item level creation process then they should be encouraged to tag the abstract accordingly.
Use of Qualifiers
Use of Schemes
URL
Used for
Discovery
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 5: Publisher
Purpose
To name the entity responsible for making the resource available in its present form, such as an agency or person, a publishing house, a university department or a corporate entity.
Rules
Use of Qualifiers
•DC.Publisher (unqualified)
•DC.Publisher.PersonalName
•DC.Publisher.CorporateName
•DC.Publisher.PersonalName.Address •DC.Publisher.CorporateName.Address
•AGLS.AgencyControlling (suggested new qualifier)
Use of Schemes
Used for
Discovery, transaction
Issues
The publisher may or may not be the controlling agency. It could be the current custodian or a third party service provider. For example, Australian Archives (AA) puts an exhibit on the web using CSIRO records, AA administers access terms and conditions but CSIRO has custody rights. In this case do we need to identify the agency controlling in a qualifier - see additional qualifier above.
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 6: Contributor
Purpose
To identify other significant contributors to the intellectual content of the resource. Someone whose contribution is secondary to any person or organisation specified in the Creator field would be mentioned here eg editor, illustrator.
Rules
Use is optional but it is felt that if the contribution is a significant one then there needs to be an entry in the Creator field.
Optional or recommended not to be used within government. Committee thought that Creator field would cover most instances they could think of.
Use of Qualifiers
Use of Schemes
Used for
Discovery
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 7: Date
Purpose
To specify the date(s) of importance that relate to the resource. Dublin Core targets the date the resource was made available in its present form but the DC Working Group is currently involved in further definition of this element.
The AGLS Metadata Workshop held in Canberra in December 1997 saw the need for coverage of the following three aspects within the date element:
. date and time of creation
. date and time of receipt
. date and time of registration
Rules
The date could be one of the following depending on how the record/document/object keeping system is configured.
Date and time of creation. Computer systems commonly record the date and time of creation and last modification of the document. This information is easily lost when a document is copied, moved, restored from back-up or retrieved. These dates and times should reflect the situation from the author’s point of view rather than that of the computer system. A new version would have a new date and time of creation.
Date and time of receipt. This is required for documents which
are sent electronically to an agency. It can be assigned by the computer
system and should be the date and time of delivery to the agency, not the
date and time of access by the action officer.
Date and time of registration. This can be assigned by the
computer at the time of registration. It should be noted that a new version
of a registered document should be registered separately. Version control
arrangements should link different versions of a document.
The date element would always need to be qualified. Other dates needed could be the contents date range, date last modified, date of publication and date posted to the web.
Use of Qualifiers
Note that the names of the subelements have not been agreed upon. The DC Date Working Group continues to work on these. There was some controversy at the end of DC5 as to whether the first two type subelements should be combined. It was also uncertain whether to include the last three subelements.
•DC.Date.Creation_of_intellectual_content
•DC.Date.Creation/Modification_of_present_form
•DC.Date.Formal_publication
•DC.Date.Available
•DC.Date.Valid (includes verification)
•DC.Date.Acquisition/Accession
•DC.Date.Accepted
•DC.Date.DataGathering
Use of Schemes
ISO 8601 recommends the standard date format as YYYY MM DD
Used for
Description, discovery
Issues
Consultation will be needed with the DC Date Working Group in view of some of our requirements.
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 8: Type
Purpose
To specify the genre of the resource eg home page, novel, poem, working paper, form, technical report, record, file. Dublin Core has a list of type options and is developing further categories.
Rules
Assign a type from the DC list.
Use of Qualifiers
For the sake of interoperability, type should be selected from an enumerated list that is under development in the workshop series at present.
See http://sunsite.berkeley.edu/Metadata/types.html for current thinking on the application of this element.
Use of Schemes
Used for
Description, discovery
Issues
Consultation with the DC Type Working Group is needed as we feel the need for the type aggregate to be available for use so a locator record can identify locator records from item description metadata.
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 9: Format
Purpose
To specify physical format and data representation of the resource. Need to look at format in
. a physical sense eg book, microfiche
. a rendered sense eg software configuration.
Rules
Assign a format type.
For the sake of interoperability, format should be selected from an enumerated list that is under development in the workshop series at present.
Use of Qualifiers
No DC qualifiers as yet
Use of Schemes
•IMT (i.e. MIME)
•DCPMT (Dublin Core Physical Medium Type) This is a new concept discussed by the Subelement Working Group at DC5. It would be an enumerated list of types of physical media when an IMT is inappropriate (e.g. a nonelectronic resource)
Used for
Transaction
Issues
Consultation with the DC Format Working Group.
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 10: Identifier
Purpose
To provide a string or number that uniquely identifies the resource within its domain. It should:
. identify the domain
. identify the uniqueness of the resource
Rules
Use:
. the domain specific identifier
. the Creator’s control number as issued by the recordkeeping system (CRS number)
. URLs and URNs - or PURLs
. ISBNs or ISSNs
Use of Qualifiers
Use of Schemes
Dublin Core proposes:
•(URL is default)
•URN (Uniform Resource Name)
•ISBN (International Standard Book Number)
•ISSN (International Standard Serial Number)
•SICI (Serial Item and Contribution Identifier)
•FPI (Formal Public Identifier)
Used for
Description
Issues
Does the Identifier element incorporate the identity of the resource being pointed to? eg if a metadata record points to a transactional database
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution
Set
Element 11: Source
Purpose
To identify other principal information resources with the same intellectual content from which this resource was derived or generated.
Rules
This element should link the electronic version of a resource to hard copies or other formats available. For example, a PDF version of a novel might have a source element containing an ISBN number for the physical book from which the PDF version was derived.
Use of Qualifiers
Use of Schemes
Dublin Core proposes:
•(Free text is default)
•URL
•URN
•ISBN
•ISSN
Used for
Description
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 12: Language
Purpose
To specify the language of the intellectual content of the resource. Australia is a multicultural society and documents sent electronically to an agency might not be in English. Recording the language will aid future retrieval.
Rules
Record the predominant language(s) of the resource.
Use of Qualifiers
Use of Schemes
Where practical, the content of this field should coincide with the Z39.53 three character code languages.
Dublin Core proposes:
IETF RFC 1766
Z39.53
ISO 639-1
ISO 639-2/B (after final publication)
Note that the current ISO 639 (to become ISO 639-1 when ISO 639-2
3-character code is approved), which is used in RFC 1766, covers only about 140
languages as compared with the newly developed standard ISO 639-2, which
includes about 400 languages. (For instance, ISO 639-1 does not distinguish
ancient languages from modern languages.) Many agencies will need the larger
more extensive list that ISO 639-2 provides. ISO 639-2 was approved in 1997;
approval of the Final Draft International Standard is forthcoming followed by
publication by ISO. Note that ISO 639-2 includes a bibliographic set (ISO
639-2/B) and a terminologic set (ISO 639-2/T); the bibliographic set is
preferred for metadata because of its widespread use in bibliographic agencies.
The new standard is closer to Z39.53 than to ISO 639-1.
Used for
Description, discovery
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 13: Relation
Purpose
To identify related information resources to assist discovery. The intent of specifying this element is to provide a means to express relationships among resources that have formal relationships to others, but exist as discrete resources themselves. For example, images in a document, chapters in a book, or items in a collection. A formal specification of RELATION is currently under development. Users and developers should understand that use of this element should be currently considered experimental.
Rules
The element is also intended to identify parent/child relationships amongst agency resources and will point to items or aggregates that the resource described relates to. In that case a new qualifier to show the relationships will be needed. Needs to be discussed further.
Use of Qualifiers
This element is considered to be developing rapidly within the context of collection-level descriptions. Subelements may be defined at a later date. The following Relation categories were enumerated at DC5; these should not be considered formal subelement names:
•Creative (e.g. translation, annotation)
•Mechanical (copy, format change, mirror copy)
•Version (edition, draft)
•Inclusion (collection, part)
•Reference (citation)
•Parent/child (new AGLS qualifier)
Use of Schemes
The Dublin Core Relation Working Group is developing a categorisation of relations which will be adopted in this set.
Used for
Description, discovery
Issues
Consultation with the DC Relation Working Group
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 14: Coverage
Purpose
To specify spatial locations and temporal durations of the resource. The means of specifying spatial parameters must be qualified.
Rules
Formal specification of coverage is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.
Use of Qualifiers
The following were determined by the Coverage Working Group. More information is in http://www.sdc.ucsb.edu/~mary/coverage. htm
•DC.Coverage.PeriodName
•DC.Coverage.PlaceName
•DC.Coverage.t
•DC.Coverage.x
•DC.Coverage.y
•DC.Coverage.z
•DC.Coverage.Polygon
•DC.Coverage.Line
•DC.Coverage.3d
Use of Schemes
To be determined by the DC Coverage Working Group.
In Australia, use of ANZLIC standards by AUSLIG
Used for
Description, discovery
Issues
Consultation with the DC Coverage Working Group
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 15: Rights
Purpose
To specify terms and conditions relating to access, security classification, privacy, copyright, intellectual property, use and reuse, and pricing. To provide provenance and to provide retention information.
Rules
Rights described need to be qualified by identifying the controlling agency that authorised the right or the legislation that provides the service by law.
Retention status of the resource described will be entered in this element.
Use of Qualifiers
None set by Dublin Core but the AGLS Working Group sees the need for qualifiers to cover points outlined below in Issues.
Use of Schemes
A number of schemes would be relevant eg FOI and archival legislation access provisions, Commonwealth Protective Security Manual.
Used for
Transaction
Issues
ACCESS
1. There are certain rights externally controlled by legislation and Commonwealth wide guidelines which relate to
. privacy
. security
. copyright/intellectual property
and detailed information can be made available by linking users to appropriate web sites.
ACCESS
2. There are other rights that are agency specific
eg
. access terms and conditions
. conditions of use
. pricing.
Agencies may have information on these on their own web site or may wish to include such information with the metadata record. If so new qualifiers will be required.
PROVENANCE
3. The advantage of including provenance with locator records is that it gives context within various levels of government and the lineage within government that a resource has been associated with.
How and where provenance details will be captured needs to be discussed further . One possibility is to link the locator record with the Australian Archives RINSE database.
RETENTION STATUS
4. This subelement informs users of the minimum period for which a resource must be kept. Retention period can be included in the metadata record or the record can point to relevant disposal authorities held in agencies. A new qualifier would be needed for this.
Formal specification of rights is currently under development by a DC Working Group. Users and developers should understand that use of this element is currently considered to be experimental. AGLS Working Group will need to forward submission on new qualifiers required.
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 16: Function Descriptor
Purpose
To specify the business function of the agency to which the resource is related. Government information aggregates can best be described via the business function that a collection represents. Users want access to government information via the functions and business that government performs, rather than by subject.
Rules
Assign term(s) from the appropriate thesaurus
eg Merged Keyword AAA/agency functional Thesaurus
Use of Qualifiers
Type/level of function
Government function
Agency function
Business function
Activity
Transaction
Example:
Archives Authority of NSW Scheme
Government function: Law and Order
Agency function: Corrective Services
Business function: Parole
Activity: Reporting
Transaction: Monthly Return
Use of Schemes
Keyword AAA Thesaurus
Agency Specific Function Thesaurus
Used for
Description, discovery
mandatory/not mandatory?
repeatable/not repeatable?
AGLS Metadata Attribution Set
Element 17: Availability
Purpose
To specify how the resource can be made available/obtained by providing contact information.
Rules
Would not be a searchable element
Use of Qualifiers
Use of Schemes
Used for
Delivery
Issues
This element is necessary for locator records as not all resources and services pointed to are on the web. However for items, the availability element may already have been covered in the publisher/creator element. This will need further discussion.
mandatory/not mandatory?
repeatable/not repeatable?
Canberra
December 09, 1997