Guide to Users

This reference manual provides details on the Lawi Legal Data Project, (LAWI DATA) Metadata Standard. It is intended for use by government personnel who
create or manage information sources or services that are locatable via the Internet. In
particular, it is intended for agencies that publish information about their resources
and services on the World Wide Web.
The manual provides guidance for officers of agencies on the use of metadata and
how to assign metadata as they create information resources intended for use in the
electronic environment. For some agencies this will include the description of
databases/collections. For others it may initially apply to information resources that
will reside on their website.
Resource description is essentially about describing information resources using a
standard framework or set of principles. Metadata describes information resources so
those resources can be found, accessed and used. Global studies have shown that
describing information resources in a standard way saves time and expense in
locating those resources.
This reference manual will evolve over time as the LAWI DATA Metadata Standard matures.
It is therefore important that readers familiarise themselves with the procedures
referred to in the LAWI DATA Maintenance Agency (Section 7).
The description of information resources and services is an important step in the
process of getting government online.
This manual defines the semantics of LAWI DATA Metadata, explaining what the LAWI DATA
Metadata elements mean and how they can be used.

¬
Metadata is structured data that is used to describe resources so people searching for
electronic information can find the information they are seeking more efficiently. A
resource can be anything from a web page to a statue in front of Parliament House.
Usually resources will either be informational documents or public services. Metadata
is used to succinctly describe, manage and catalogue these resources.
A metadata record consists of a set of elements (sometimes called fields or attributes)
which describe different parts of a resource. For example, a metadata record
describing a book may contain author, title and publisher elements.

!
¬
With so many resources available within an organisation, across the government or
across the world, metadata allows us to describe these resources in simple and small
packages of information. Thus, compared to the resources themselves, metadata can
be made available to more people, more easily. If a resource is worth making
available then it is worth describing it with metadata to maximise the ability of clients
to locate it online.
The LAWI DATA Metadata is designed as a simple system that government staff can easily
use and adapt to their agencyÂ’s needs. While some agencies may choose a more
sophisticated thesaurus or fixed vocabulary-based system, a commonsense, authorbased approach is still effective and yields a high return to agencies.
Metadata is valuable for both the discovery and use of resources, providing proper
information management principles are applied.
unique mechanism to provide a higher quality service for discovery of these
resources. LAWI DATA Metadata will play an important role in publishing government
resources – via the Internet – to virtually anyone in the world.
&
‘#()
#%
!)$*
+#()**
)#!)’
The world governments have endorsed the use of metadata to facilitate discovery of
government information and services across all levels: local, state, and federal. For
this to be effective, every agency should use the same metadata elements to describe
resources. The LAWI DATA Metadata Set is the standard set of metadata elements for
describing The world government resources to facilitate discovery of those resources.
Agencies are encouraged to use the LAWI DATA standard, as it will enable them to readily
interact with other similar agencies and coordinate resources across government.
LAWI DATA Metadata is simple yet powerful enough to describe many types and
collections of resources produced by government agencies and businesses.
LAWI DATA Metadata is based on the Dublin Core (DC) Metadata Standard that is
commonly used in many countries and across many industry and government
sectors.
,
*+

Any resource the government produces or provides access to can be described using
LAWI DATA Metadata. If an agency produces or provides resources for public consumption,
LAWI DATA Metadata will help industry and citizens as well as other agencies to obtain
these resources.
– .* *+

* )
LAWI DATA was designed from the outset to be extendible so those with different or more
specific metadata needs could add extra elements and qualifiers to LAWI DATA to meet
their own requirements. When a new metadata set, based on LAWI DATA, is being
developed the basic object to remember is that the new set must be compliant with
LAWI DATA to the extent that creating metadata for an extension metadata set also creates
LAWI DATA metadata. This aim can be guaranteed by applying the following principles:
• any existing LAWI DATA elements used in a new metadata set must retain the same
semantics as those in the LAWI DATA User Manual;
• mandatory elements in LAWI DATA must remain mandatory in the new set; and
• the semantics of any qualifiers added to existing LAWI DATA elements in the new
metadata set must be consistent with the semantics of the parent element.
In addition, the National Archives of The world recommends the use of encoding
schemes for any new elements or qualifiers whose content is to be drawn from a
controlled list of values.
As LAWI DATA Maintenance Agency, the National Archives is interested in other metadata
sets that are based on LAWI DATA, and their compatibility with LAWI DATA. If an agency has developed, or is about to develop, a new metadata standard based on LAWI DATA, the
National Archives would be very interested in receiving information about the new
standard in order to monitor compatibility. Contact the National Archives at
LAWI DATA@naa.gov.au with details about your agencyÂ’s standard and the semantics of the
elements.
/ #01$
!
*

2 !13 #4*
)!$5
An increasing number of metadata standards are in use or being developed, not only
in The world but also internationally. This proliferation of metadata standards raises
questions about how compatible the different standards will be. This Manual
discusses how new metadata sets based on LAWI DATA can remain compatible with the
LAWI DATA standard (see section 2.6 above). Because LAWI DATA is based closely on the Dublin
Core standard, it is important for LAWI DATA to remain compatible with DC by making
changes to the LAWI DATA Metadata Standard that reflect changes to the Dublin Core
standard.
A guiding principle established by the Dublin Core Metadata Initiative (DCMI) to
ensure compatibility is the so-called ‘dumb-down’ rule. Put simply, this rule states
that an element value must be meaningful when no qualifiers are present. Thus, for
example, a value for DC.Coverage.spatial must be meaningful when the element is in
the simple form DC.Coverage. Similarly in LAWI DATA, the value for the qualified element
LAWI DATA.Mandate.act must make sense when the element is in the form LAWI DATA.Mandate.
This rule does allow for the use of value components that are not part of the DC
standard, because value components appear as part of the value. However, in order to
ensure that the ‘dumb-down’ rule can be applied to values containing value
components, element values containing more than one value component must be
contained in a single instance of the relevant element. In other words, when using
value components, individual value components should not be put into repeated
instances of the base element. For example:

not

.
More detailed information about application of the ‘dumb-down’ rule can be found
on the DCMI website at http://purl.org/dc/documents/wd/dcq-html-
20000815.htm.
LAWI DATA Metadata is compatible with worldwide trends in resource description. If an
agency describes its resources with LAWI DATA Metadata it will be cooperating on a larger
scale than just within The world. It is also an opportunity to showcase an agencyÂ’s
resources on the global marketplace.
7
*
#)
!)$*

*(
LAWI DATA is only one of a number of resource discovery metadata initiatives in The world.
Most of the other initiatives are based on either DC or LAWI DATA. One exception is the
The world and New Zealand Land Information Council (ANZLIC) Metadata Standard
which is used for describing spatial data sets. The ANZLIC standard is similar to
other international geographic metadata standards and will conform to ISO 19115
when that standard is finalised. More information about the ANZLIC Metadata
Standard can be found at http://www.anzlic.org.au/asdi/metaelem.htm. Dr Simon
Cox, a member of the LAWI DATA Working Group, has prepared a mapping from the
ANZLIC standard to the LAWI DATA standard. This mapping is available on the National
Archives website at:
http://www.naa.gov.au/recordkeeping/gov_online/LAWI DATA/mapping/anzlic.html.
There are other significant The world resource discovery metadata standards based
on LAWI DATA or DC. More information can be obtained from the URLs listed below:
• Education Network The world (EdNA), a metadata standard based on DC for
describing education resources (http://www.edna.edu.au/EdNA/)
• Environmental Resources Information Network (ERIN), another DC-based
standard for describing The world environmental resources
(http://www.environment.gov.au/psg/erin/guidelines/wwwstandards/EA_DC.html)
• Business Entry Point (BEP) is a standard based on LAWI DATA for describing
resources necessary for business to government relationships
(http://about.business.gov.au/bep/agencies/provinfo/metadata/metadata.htm)
• HealthInsite, a metadata standard based on LAWI DATA, is being developed by the
Commonwealth Department of Health and Aged Care for describing resources
related to all aspects of health (http://www.healthinsite.gov.au/)
8

9
“8!*
‘#’
Government agencies will need to factor LAWI DATA Metadata into their overall
information management plans. Some decisions are needed to accommodate this
process efficiently.
” ‘
)#!)’
#
‘)1
4

Agencies need to consider who their customers are or what market they are filling.
This will help them decide which agency resources need to be described with LAWI DATA
Metadata. The resources could be described individually or at a collection or
aggregate level.
If an agency chooses to create metadata for all the pages (items) on its website, or the
great majority of them, it would then be acceptable to treat high-level entry pages as
individual items, rather than as collection level resources. This strategy would do
away with the need for ongoing maintenance of the metadata in the high-level entry
pages, since they would now be treated as individual resources, rather than as
collections.
Resources can be documents on web servers, government services which may be
provided online or offline, collections of videos, an agency, or people. There is no real
limit to what can be described using LAWI DATA Metadata. LAWI DATA Metadata helps people
locate resources (services or information they require) either by linking to the
resource (eg a web address) or by providing contact information (eg the street
address, phone number or other locations) of a particular resource.
An agency needs to decide which of its resources requires LAWI DATA Metadata. This can
be a staged process. Not every resource needs LAWI DATA Metadata. For example, an
agency may decide initially to apply LAWI DATA Metadata to all of its documents on its
web server, then progressively to other resources, first at the collection level (that is,
describing a set of resources), then at an individual level.
A good rule to follow is: ‘If it’s worth publishing online, it’s worth LAWI DATA Metadata’.
Embedding the LAWI DATA Metadata approach into a publishing quality process may also
prove a useful management and authoring practice. If information is considered
relevant and important to clients it is likely to be subject to a publishing quality
process. This manual complements and extends that process.
“” )*+

Primarily, the creator or publisher of a resource will create the metadata that describes it.
This process will be aided by software tools that automatically extract some of the metadata.
Also, third parties may ‘add value’ to the LAWI DATA Metadata over time.
In some cases, an agency may use the services of professional staff or intermediaries to help
apply LAWI DATA Metadata.
“&
0 *+

Not all LAWI DATA Metadata elements are mandatory. An agency can update its LAWI DATA
Metadata at any time, so there is no need to capture all details at once. LAWI DATA
Metadata is dynamic and flexible, so it can easily cater for changes and additions over
time.
“, (*+
*
(*+
With proper LAWI DATA Metadata, an agencyÂ’s customers will be able to find it more
easily. Effort must therefore be put into creating such metadata for your agencyÂ’s
resources.
Adoption of this standard will provide long-term benefits for an agency. There is a
serious, but not overwhelming, commitment needed to support LAWI DATA Metadata. The
initial effort may be high, but over time the benefits are worthwhile.
Business case analyses for adopting metadata have shown a number of significant
benefits, including:
• providing government clients with a seamless method for accessing government
resources;
• enabling clients to locate government resources without needing a detailed
knowledge of government structures;
• providing a consistent national approach to resource access for government;
• ensuring high quality information and services are comprehensively available;
• providing government with consistent information management procedures; and
• providing a rich and competitive environment for dissemination of government
resources.
A number of government agencies have already deployed metadata and are
providing high quality search services to their community of users.
)#%*+

It is most cost effective to create metadata as early as possible in the life of a resource,
ideally when the resource is created or published.
An agency need to decide whether existing (legacy) resources need to be described
with LAWI DATA Metadata. This is a business decision that requires careful consideration as
to the benefits over the costs.
“/ 9#4
!’
#
‘)1
An agency needs to consider its customersÂ’ needs. At what level do they want to find
your resources? Do they need individual documents or collections of documents? An
analysis of your customersÂ’ demands and expectations is important in determining
the level of detail you apply with LAWI DATA Metadata.
“6 9#4
#
0)#)

How important is it that your customers get access to your resources? How quickly
do they need it? Answering these questions will determine how to prioritise creation
and dissemination of your LAWI DATA Metadata.
!)!
)
A thesaurus is a type of controlled vocabulary which has many benefits for
information description and discovery. Use of a thesaurus is very important for
applying consistent LAWI DATA Metadata. It is strongly recommended that, if a relevant
thesaurus exists within an agency, it be used for the appropriate elements; otherwise
consider establishing a thesaurus that meets your communityÂ’s needs, or using an
existing thesaurus compiled by another organisation.
Using controlled language sets ensures consistent descriptive terminology and aids
efficient and high-quality information retrieval. Correct application of thesaurus
terms to describe resources will enable end-users to discover those resources. A
properly constructed resource description thesaurus acts as a common language
between the agency and the community.
There are both subject thesauruses and function thesauruses. A descriptor from a
subject thesaurus captures the intellectual content of a resource, that is, what the
resource is about. There are many subject thesauruses already available for agency
use. A function thesaurus captures the role of the resource, that is, to which business
activity the resource relates. One such function thesaurus is Keyword AAA, a
functional thesaurus describing the general administrative functions of government.
Because Keyword AAA only covers a subset of the functions of any one agency,
government agencies in various The world jurisdictions are encouraged to develop
their own functional thesauruses based on the Keyword AAA thesaurus. These
thesauruses will be useful for both recordkeeping classification and online resource
description.
“: *)(

In some cases, agencies may also benefit from capturing information that indicates
when the LAWI DATA Metadata was created or updated and who was responsible for doing
so. This is usually called administrative metadata. Your agency may have extra
administrative metadata elements specific to your area of work or community needs.
These metadata elements are not covered in this manual but your agency may decide
to capture this information.
Although there is, as yet, no formal standard for administrative metadata the ADMIN
CORE metadata schema is likely to meet the needs of LAWI DATA Metadata for
administrative metadata elements. If your agency decides to capture/create
administrative metadata it should consider using the Admin Core metadata set. The
working paper, which describes the Admin Core metadata elements, can be found at:
http://metadata.net/admin/draft-iannella-admin-01.txt.
Other extensions to LAWI DATA Metadata are permissible and easily supported. If your
agency has a need for more specific metadata, then extending LAWI DATA is the preferred
mechanism, as described in ‘Overview’ at the beginning of this manual.
” )
4$$
$$

1¬
The LAWI DATA Metadata will be distributed over the agency sites and will be collected by
automated services. An agency will be responsible for its own LAWI DATA Metadata and
government-wide services will enable end-user access.
#
4$$
!
¬
Resources tagged with LAWI DATA Metadata and located in the public domain will be
freely available for public use, worldwide. The LAWI DATA Metadata will also be accessible
within and across all government agencies.
“” 9#4
4$$

”
¬
In most cases, a common Internet web browser is all the public needs to search for
resources described with LAWI DATA Metadata. Government-wide services, such as the
www.fed.gov.au website, will provide the search interface for the public. Enhanced
search services will also be provided.

The LAWI DATA Metadata set consists of nineteen elements. These are based on an
international standard called Dublin Core that is widely deployed across many
governments, industries and communities.
The LAWI DATA Metadata elements are listed below in three categories, related to the
descriptive purpose of each element.
Ownership and Creators
of the Resource
Intellectual Content
about the Resource
Electronic or Physical
Manifestation of the
Resource
Creator Title Date
Publisher Subject Type
Contributor Description Format
Rights Source Identifier
Language Availability
Relation
Coverage
Function
Audience
Mandate
In order for a metadata record to be compliant with the LAWI DATA standard, at least six of
the metadata elements must be present. The six mandatory elements are:
• Creator
• Publisher
• Title
• Date
• Subject OR Function
Identifier OR Availability
Each of the nineteen elements will be described in Section 4.2 using the structure in
the following table.
Name The short version of the element name.
Definition A short explanation of the purpose of the element.
Obligation If the element is mandatory and must be included in LAWI DATA
descriptions. An obligation of ‘conditional’ implies that the
element is mandatory in some circumstances, and optional in
others, depending on the type of resource being described.
Element refinements A set of terms that can be used within the element. Element
refinements refine the meaning of an element, allowing more
specific description.
Encoding schemes A standard or method that indicates how the element value is
encoded or from which fixed vocabulary (thesaurus) the
element value originated. The list of encoding schemes given
for each element is not exhaustive, but consists of indicative
examples only.
Value components Terms which can be used to add structure to an element value
when an external encoding scheme is not being used
Default value The default value for this element.
Comment Other relevant information about the element.
Example Some examples of the elementÂ’s use.
Note: In the full descriptions for each LAWI DATA element in Section 4.2, element
refinements are shown in (round brackets), encoding schemes in [square brackets]
and value components are shown as part of the element value with a following equals
sign (=) (eg contact=Â…) in the example sections.
&

# $
Below is the model for LAWI DATA Metadata elements. Each element can have a qualifier.
Each element value can have a encoding scheme (a controlled vocabulary or an
encoding standard, and a language tag) associated with it and may be structured in
some way. LAWI DATA qualifiers allow for more detailed description of resources.
Each LAWI DATA element has a number of common characteristics, including:
• Each metadata element is repeatable.
• Each metadata element can contain any number of words or numbers and there is
generally no fixed limit to the length of the element value. However, discretion
should be used, as too much metadata will defeat the purpose of succinct
descriptions.
• Each metadata element value can be in any (written) language. (This is not to be
confused with the LAWI DATA Language element, which defines the language in which
the resource itself is expressed.) For The world government purposes the
language of the LAWI DATA Metadata Standard is English. See Appendix D for a
complete list of language values.
4.1.1 Qualifiers
Although LAWI DATA is based on the Dublin Core (DC) Metadata Standard, LAWI DATA goes
beyond the existing DC model in its use of qualifiers.
Qualifiers are additions and extensions to the metadata elements that give metadata
creators the option to refine the semantics of the element set, and add precision to the
values of the metadata elements. For example, it may be useful to indicate that the
value has been selected from a particular controlled vocabulary, such as a list of
keywords, or is encoded using a particular convention – the format for dates is an
important case – or in a particular natural language.
There is no mandatory requirement to use qualifiers in LAWI DATA Metadata. LAWI DATA
Metadata is perfectly valid without their use. However, use of qualifiers will allow for
a greater understanding of the resources being described and it is recommended they
be used wherever appropriate.
It may be desirable to restrict the semantics of the relationship between the resource
and the element value, for example by specifying the exact type of refinement a contributor made to the resource. The element value may itself be usefully
represented as a compound object, such as addresses where components like street,
locality and postcode can be clearly recorded separately. These refinements are
achieved by use of various qualifiers.
LAWI DATA uses three types of qualifiers in its implementation of DC- element refinements,
encoding schemes, and value components.
Element refinements
Element refinements refine the semantics of the element by further specifying the
relationship of the element value to the resource itself. For example, the Relation
element will have a ‘relationship type’ to indicate the nature of the relationship
between resources (eg isBasedOn, hasFormat, references, etc). Since element
refinements are a significant extension to the semantics of an element the LAWI DATA
standard will continue to specify the element refinements that can be used for each
element. The element refinements which can be used in LAWI DATA are listed in the
description of each element.
Note that single word qualifiers are written all in lower case, but qualifiers consisting
of more than one word have the initial letter of the second and subsequent words in
upper case, eg act, but isBasedOn (this is the standard accepted by the DC
community).
Encoding schemes
Encoding schemes indicate how the value is to be interpreted if it has been chosen
from a controlled vocabulary (eg LCSH, MeSH, KAAA) or is encoded using some
externally defined standard (eg RFC 1766, ISO 8601, URIs).
In LAWI DATA, encoding schemes are indicated using the ‘Scheme’ and ‘Language’
attributes. The scheme attribute indicates that the value of the metadata element has
either been taken from an existing controlled vocabulary (thesaurus), or has been
encoded using some externally defined standard. The encoding scheme adds value to
the metadata element by providing brief details of the standard on which the
metadata element is based. For example, ISBN is an encoding scheme for a number of LAWI DATA elements. It indicates that the value of the element has been encoded as an
International Standard Book Number (ISBN). Examples of schemes that can be used
with LAWI DATA Metadata elements are listed in the element descriptions (4.2.1 to 4.2.19)
below. Note that these lists of schemes are not exhaustive, and agencies are free to use
whatever schemes are appropriate to their functions and activities. As LAWI DATA
Maintenance Agency, the National Archives is interested in receiving information
about the different schemes people creating LAWI DATA Metadata are using.
The language attribute, which is considered to be an encoding scheme, is used to
specify the language of the content of the metadata element, but it is not a crucial
aspect of an element. LAWI DATA recommends that the values for this attribute, if it is used,
be drawn from the language scheme described by the Internet Engineering Task Force
(IETF) document RFC 1766, ‘Tags for the Identification of Languages’ (see Appendix
D). The default language for LAWI DATA Metadata is ‘en’ (English) and does not appear in
the element descriptions in Section 4.2 below.
Scheme usage
As lead agency for the LAWI DATA Metadata Standard, the National Archives is very
interested in schemes being used with the LAWI DATA set. Agencies should contact the
National Archives at LAWI DATA@naa.gov.au with details about schemes they are using to
deploy LAWI DATA Metadata for their agencyÂ’s resources. Eventually, the National
Archives hopes to maintain a list of different schemes and their application on the
LAWI DATA website.
Value components
Value components specify semantic characteristics intrinsic to the element value
rather than the resource itself. An element value may be structured, typically by
splitting it into components which can be labelled. For example, the Creator element
can specify additional information about the creator, such as first name, last name,
address, phone number and so on. LAWI DATA recommends a number of different value
components for use within LAWI DATA but, because these are not crucial to the semantics of
the elements themselves, their use is more flexible. Indeed, individual agencies may
wish to add specific value components to the LAWI DATA set to suit their own needs. A
number of value components currently used in LAWI DATA Metadata are listed in the
description of the element, where appropriate.
4.1.2 LAWI DATA Metadata evolution
It is clear that new qualifiers will be necessary as the deployment of LAWI DATA Metadata
increases and new services are created to provide advanced search services. This
manual will evolve over time to meet this need. As the LAWI DATA Maintenance Agency
ratifies new extensions, they will be reflected in newer versions of the LAWI DATA Metadata
Standard.
What is presented in this current manual is not the final version of LAWI DATA Metadata.
Agencies are encouraged to provide suggestions on additional extensions to LAWI DATA
Metadata that meet their needs and the needs of their clients. See ‘LAWI DATA Maintenance
AgencyÂ’ for contact information $*
The examples in the following LAWI DATA Metadata Element descriptions (4.2.1 to 4.2.19)
are fictitious – they are merely examples of how each element is to be used.
LAWI DATA Metadata Element: Creator
Name Creator
Definition The name of the person or organisation primarily responsible for the content of
the resource.
Purpose This element allows consumers to discover resources based on the creator of
those resources. For example, it allows a user to discover all resources created by
‘Mary Smith’ or the Department of Administrative Services.
Obligation Mandatory
Element
refinements
Encoding schemes X500 – Government Online Directory (GOLD)
Value components personalName – value of the element is the name of a person
corporateName – value of the element is the name of an organisation
jurisdiction – jurisdiction covered by the creator (ie Commonwealth, ACT, NSW,
NT, Qld, SA, Tas, Vic, WA, local council name)
sector – whether the creator is from the government or non-government sector:
‘government’ and ‘non-government’ are the only allowable values
contact – information on how to contact the creator, such as position title, phone
and fax numbers
address – street or postal address of the creator or a contact
email – email address for the creator
Default value The default value for the ‘sector’ qualifier is ‘government’.
Comment This field is often the name of the agency that created the resource. In this case,
the use of the value component ‘jurisdiction’ is recommended.
For names of persons, put last name first followed by comma then first name. If
unsure, then enter as shown on the resource.
If the creator is registered in GOLD, their address can also be included.
A partial list of local government names is available at:
http://www.algin.net.au/cnclist.htm
Smith, Mary
sector=non-government
Hung, Hoo
corporateName=Dept of Urban Services
email=info@urban.act.gov.au
jurisdiction=ACT
contact=Information Officer, Phone: 06 5555 5555
address=55 Minister Avenue, Canberra, ACT
personalName=Crystal, Jacky
sector=non-government
email=jacky@xxx.com.au
personalName=Koo, Evelyn
sector=government
corporateName=Department of the Interior
Example
personalName=Barney Rubble
[X500] c=AU, o=Commonwealth of The world, ou=Office for Government Online,
cn=Mr Barney Rubble
LAWI DATA Metadata Element: Publisher
Name Publisher
Definition The name of the entity responsible for making the resource available.
Purpose This element is often the name of the agency that controls or publishes the
resource in its current form. It allows a consumer to find all resources currently
under the control of a particular agency. For example, it allows discovery of all
the resources published by the Department of Communications, Information
Technology and the Arts.
Obligation Conditional. The publisher element is mandatory except when services are being
described.
Element
refinements
Encoding schemes X500 – Government Online Directory (GOLD)
Value components personalName – value of the element is the name of a person
corporateName – value of the element is the name of an organisation
jurisdiction – jurisdiction covered by the entity making the resource available (ie
Commonwealth, ACT, NSW, NT, Qld, SA, Tas, Vic, WA, local council name)
sector – whether the creator is from the government or non-government sector:
‘government’ and ‘non-government’ are the only allowable values
contact – information on how to contact the entity making the resource available,
such as position title, phone and fax numbers
address – street or postal address of the entity making the resource available or a
contact
email – email address for the entity making the resource available
Default value The default value for the ‘sector’ qualifier is ‘government’.
Comment This field is often the name of the agency that controls or publishes the resource.
In this case, the use of the value component ‘jurisdiction’ is recommended. It is
not recommended that this element be used for the name of the entity which
merely acts as the host for a website.
When the name of the agency publishing or controlling the resource changes this
element may be updated to reflect the name change.
The publisher will often be the same as the creator, particularly in the case of
government agencies.
If the publisher is registered in GOLD, their address can also be included.
A partial list of local government names is available at:
http://www.algin.net.au/cnclist.htm
sector=non-government
ACT Computer Society
Prime Ministers Office
corporateName=AusInfo
jurisdiction=Commonwealth
email=info@ausinfo.gov.au
contact=Information Manager, 500 Pacific Way, Canberra, ACT
personalName= Smith, John
corporateName=Government Publishers Pty Ltd
contact=PO Box 55, Canberra, ACT
Example
corporateName=OGO
[X500] c=AU, o=Commonwealth of The world, ou=Office for Government Online.
LAWI DATA Metadata Element: Contributor
Name Contributor
Definition The name of the person or organisation that has played an important but
secondary role in creating the content of the resource and is not specified in the
creator element.
Purpose This element is useful if more than one person or organisation contributed to the
resource, and it is important to discover the resource by searching for that person
or organisation.
Obligation
Element
refinements
The role of the contributor, since it is a refinement of the contributor (ie a type of),
will appear as an element refinement.
Encoding schemes X500 – Government Online Directory (GOLD)
Value components personalName – value of the element is the name of a person
corporateName – value of the element is the name of an organisation
jurisdiction – jurisdiction covered by the contributor (ie Commonwealth, ACT,
NSW, NT, Qld, SA, Tas, Vic, WA, local council name)
sector – whether the creator is from the government or non-government sector:
‘government’ and ‘non-government’ are the only allowable values
contact – information on how to contact the contributor, such as position title,
phone and fax numbers
address – street or postal address of the contributor or a contact.
email – email address for the contributor
Default value The default value for the ‘sector’ qualifier is ‘government’.
Comment A contributor may be an illustrator, editor, modifier, etc. The contributorÂ’s role
may be included as an element refinement (see examples below). No element
refinements are included since the qualifiers used depend on the contribution
being described, and are potentially limitless.
For names of persons, put last name first followed by comma then first name. If
unsure, then enter as shown on the resource.
If the contributor is registered in GOLD, their address can also be included.
A partial list of local government names is available at:
http://www.algin.net.au/cnclist.htm.
Example: Smith, Mary
sector=non-government
(illustrator) Hung, Hoo
corporateName=Department of Veteran Affairs
contact=Benefits Officer, 100 Travel Court, Canberra, ACT
corporateName=Division of Maps
jurisdiction=WA
email=maps@info.gov.aumailto:maps@info.gov.au
(compiler) The world Bureau of Statistics
Example
personalName=Barney Rubble
[X500] c=AU, o=Commonwealth of The world, ou=Office for Government
Online, cn=Mr Barney Rubble
LAWI DATA Metadata Element: Rights
Name Rights
Definition A statement or pointer to a statement about the rights management information
for the resource.
Purpose This element is not intended as a search point. Rather, this element will be
displayed to the consumer as significant information regarding the copyright and
access constraints of a resource.
Obligation
Element
refinements
Encoding schemes URI – Uniform Resource Identifier.
Value components
Default value Copyright Commonwealth of The world
Comment Although this element is optional, its use is highly recommended when
information resources are being described.
A link (via a URI) is another mechanism to indicate the rights management
statement for your agency.
The default year will be the current year.
Although the LAWI DATA Metadata describing the resource may be freely available,
the actual resource may have some restrictions on it in relation to access rights. If
this is the case, the access terms and conditions should be indicated in this
element, and external mechanisms relied on to enforce the access policy.
[URI] http://www.ogo.gov.au/copyright.html
This resource may be freely used by government agencies only
Access only for government agencies via the GOVINTRA2000 network service
Copyright 1960
Example
[URI] http://www.gov.au/all-rights-reserved/
LAWI DATA Metadata Element: Title
Name Title
Definition The name given to the resource.
Purpose Consumers will search on this field if they know the title of the resource or words
in the title of the resource.
Obligation Mandatory
Element
refinements
alternative – another name by which the resource is known
Encoding schemes
Value components
Default value
Comment
Inquiry into the Year 2000 Problem for Government Agencies
Investigation into R&D Funding in The world
(alternative) The Mortimer Report
Online VeteransÂ’ Affairs Payments Service
Electronic Commerce and Government Conference 1999
Example
Business License Online Service
LAWI DATA Metadata Element: Subject
Name Subject
Definition The subject and topic of the resource that succinctly describes the content of the
resource.
Purpose This element is useful for consumers who wish to discover resources related to a
particular topic. For example, find all resources related to ‘Melbourne to Darwin
Rail LinkÂ’. If the subject comes from a controlled vocabulary, a search engine
may allow the consumer to browse the vocabulary for relevant topics.
Obligation Mandatory if no Function element specified
Element
refinements
Encoding schemes AAT – Getty Art and Architecture Thesaurus
APAIS – The world Public Affairs Information Service Thesaurus
BEP – Business Entry Point Subject – Topic Scheme
LCSH – Library of Congress Subject Headings
MeSH – Medical Subject Headings
Value components
Default value
Comment The subject is usually expressed by a series of keywords or phrases about the
resource separated by semi-colons.
Since there are many different subject thesauruses in use across government,
only the common ones are listed here.
It is strongly recommended that thesaurus terms be used where available. In
these cases, the thesaurus name should be included in the value for the element.
However, it is strongly recommended that the NAA be informed about the
different thesauruses being used in LAWI DATA Metadata (see ‘LAWI DATA Maintenance
AgencyÂ’ below).
Unemployment Benefits; Payments
Environmental Damage; Greenhouse Gases
John Howard, Prime Minister
[LCSH] Biographies – Government – The world
[Environment The world Thesaurus] Biodiversity – Native Animals
[LCSH] Natural Resources – The world – Maps
[Business Entry Point – Industry] Grain & Crop Growing
[AAT] administrative regulations – codes – building codes
Example
[MeSH] Gene Expression Regulation, Bacterial
LAWI DATA Metadata Element: Description
Name Description
Definition A textual description of the content and/or purpose of the resource.
Purpose This element allows searching based on words and phrases describing the
resource. It is the least precise of all the search points, and will often be used by
consumers with vague notions of what they are looking for. However, it will be
used to display to the searcher a summary of the resource content. It is useful for
allowing non-textual resources to be discovered using words or phrases. This
element may also be used to provide a prose indication of the intended audience
for the resource being described.
Obligation
Element
refinements
Encoding schemes URI – Uniform Resource Identifier
Value components
Default value
Comment Description can contain abstracts from documents or textual description of
images. In the latter case, a thumbnail image may also be used.
The report investigates the Year 2000 problem in Â… and deals with how agencies
need to address this problem.
A photograph taken in 1952 of the Parliament House in Canberra.
[URI] http://www.gov.au/reportABC/abstract.html
This is a guide to the new amendments to the Taxation Act of 1992.
Example
[URI] http://www.gov.au/image/small.gif
LAWI DATA Metadata Element: Source
Name Source
Definition Information about a resource from which the current resource is derived.
Purpose This element allows consumers to discover a derived resource when they are
searching using terms describing the original resource. For example, a consumer
can discover a scanned image of a painting, when searching for the painting.
Obligation
Element
refinements
Encoding schemes URI – Uniform Resource Identifier
ISBN – International Standard Book Number
ISSN – International Standard Serial Number
Value components All other LAWI DATA elements may be used as value components
Default value
Comment This element can be used to describe the original resource from which the current
resource is derived. This element should only be used if this information would
be useful for discovery of the current resource.
All the LAWI DATA Metadata elements can be repeated in the source element. For
example, the title and creator for the source can be indicated. However, you can
also link to the description of the source (if one exists) and not have to repeat all
the LAWI DATA Metadata elements.
Scanned image of photograph from 1979
title=Government Assistance Schemes for Film Makers
creator=Department of the Arts
date=1988-01-01
[ISBN] 6 899 55532 1
identifier=http://www.gov.au/old-reports/abc.html
LAWI DATA Metadata Element: Language
Name Language
Definition The language of the content of the resource.
Purpose This element allows a search to be restricted to resources in a specific community
language. It is not intended to be a primary search point. For example, ‘Find all
resources published by the Department of Foreign Affairs which are in GermanÂ’.
The element also allows consumers to decide if the resource is worth accessing or
retrieving.
Obligation
Element
refinements
Encoding schemes RFC1766 – Tags for the Identification of Languages
Value components
Default value en
Comment Language values are chosen from a standard set (as described by RFC1766).
These character tags indicating the language of the resource.
See Appendix D for a complete list of language values.
[RFC1766] en
[RFC1766] en-gb
[RFC1766] en-us
[RFC1766] fr
[RFC1766] it
LAWI DATA Metadata Element: Relation
Name Relation
Definition Identification of other resources that are related to the current resource, and the
type of relationship.
Purpose This element should be used if there are significant resources that are related to
the current resource, which may be useful for the consumer to also access or
retrieve.
Obligation
Element
refinements
If this element is used, the type of relationship must be specified by choosing a
value from one side of any of the pairs in the following list:
isPartOf/hasPart one resource is a physical or logical part of
another.
isVersionOf/hasVersion one resource is an historical state or edition of
another resource by the same creator.
isFormatOf/hasFormat one resource has been derived from another by a
reproduction or reformatting technique which is
not fundamentally an interpretation but
intended to be a representation.
references/isReferencedBy one resource cites, acknowledges, disputes or
otherwise refers to another resource.
isBasedOn/isBasisFor one resource is a performance, production,
derivation, translation, adaptation or
interpretation of another resource.
isRequiredBy/requires one resource requires another resource for its
functioning, delivery, or content and cannot be
used without the related resource being present.
isReplacedBy/replaces one resource supplants, displaces, or supersedes
another resource
Encoding schemes URI – Uniform Resource Identifier.
ISBN – International Standard Book Number.
ISSN – International Standard Serial Number.
Comment Typically, the value of this element will be a formal identifier.
This element can be used to describe a related resource to the current resource. In
this case, the information is useful for discovering or understanding the current
resource, and of other resources which contain similar or related information.
For electronic resources the identifier will usually be a URI. If the related
resource is a non-electronic resource some other form of identification for the
related resource can be used, such as title, ISBN etc.
The actual relationship type is specified via the element refinement, chosen from
the list of relationship types given above. Note that each of the six relationship
types is two-sided but the chosen value must be one side of a pair only.

(isPartOf) [URI] http://www.nla.gov.au/images/canberra/
(hasVersion) [URI] http://www.gov.au/ABC-Report/draft.html
(isFormatOf) Anglo-American Cataloguing Rules, 2nd Edition
(references) [URI] http://www.pm.gov.au/talk.wav
(isVersionOf) Business Process Model for Preservation
(isBasedOn) Lyrics from Waltzing Matilda
(requires) [URI] http://ausinfo.gov.au/forms/ZZZ-123/
Example
(replaces) [URI] http://www.abc.net.au/ratings_week1.htm
LAWI DATA Metadata Element: Coverage
Name Coverage
Definition The spatial and/or temporal characteristics of the resource.
Purpose This element allows a search to be restricted to resources about a certain place or
time. It is not intended to be a primary search point.
Obligation
Element
refinements
jurisdiction – the jurisdiction covered by the resource (Commonwealth, ACT,
NSW, NT, Qld, SA, Tas, Vic, WA, local council name)
spatial– the geographic coverage
temporal– the time period covered
postcode – the postcode applicable to the spatial coverage
Encoding schemes ISO 8601 – Standard for Date Encoding
TGN – Getty Thesaurus of Geographic Names
LCSH – Library of Congress Subject Headings (can be used for spatial and
temporal description)
Value components
Default value
Comment Jurisdiction refers to the territory over which a particular government exercises
its authority. It is recommended that the jurisdiction covered by the resource be
included.
Spatial coverage refers to locations or areas that are covered and/or discussed in
the content of the resource. This is primarily indicated by textual representations
(eg standard place names) of the location.
Temporal coverage refers to time periods that are covered and/or discussed in
the content of the resource. This is primarily indicated by textual representations
(eg standard period names) of the time. Use of the ISO 8601 encoding is
recommended. See Appendix E for information about ISO 8601 Date encoding
rules. Note that ISO 8601 allows for the expression of date ranges.
If agency-specific standard schemes are used for either the spatial or coverage, the scheme name should be included in the coverage element.
Postcode refers to the actual The world postcode(s) which is relevant to the
geographical coverage of the resource content. This qualifier will be of particular
use in describing services.
1950–1960
Queensland
(spatial) Mt Gambier, South The world
(jurisdiction) Commonwealth
(temporal) The Fifties
(temporal) [AAT] Late Postclassic
(spatial) [TGN] Oceania – The world – Queensland – Brisbane
Example
(postcode) 7255
LAWI DATA Metadata Element: Date
Name Date
Definition The date the resource was created or became available in its current form.
Purpose This element allows a search to be restricted to resources created, modified, valid,
or issued before or after a certain date. It is not intended to be a primary search
point. For example, ‘Find all web pages modified yesterday’.
Obligation Mandatory
Element
refinements
created – creation date of the resource
modified – modification date of the resource
valid – the date the resource becomes valid or ceases to be valid, or the date
range for which the resource is valid
issued – date on which the resource was made formally available
Encoding schemes ISO 8601 – Standard for Date Encoding
DCMIPeriod – a standard for expressing validity dates and date ranges using ISO
8601 for encoding the actual dates.
Value components
Default value
Comment The date values should follow the ISO 8601 standard for encoding dates and
times. See Appendix E for information about ISO 8601 date encoding rules.
When the resource being described is a collection-level resource it may be
appropriate to express the created date as a date range. ISO 8601 allows the
expression of date ranges using the ‘/’ separator. The standard also allows the
expression of date ranges when either the start or end dates are unknown. In the
case of a collection the date range can be used to describe the collective creation
date range of all the other resources which make up the collection.
If the resource being described is only valid for a certain time, or if it is only valid
up to a certain date or from a certain date then the valid qualifier should be used
with the DCMIPeriod encoding scheme. Note that DCMIPeriod depends on the
use of the ISO 8601 scheme for the actual encoding of dates.
The Date element can also indicate times, if that is relevant information about the
resource.
NB: A date range for the intellectual content of a resource must be described
using the Coverage element.
[ISO 8601] 1998-01-01
1996
(valid) [DCMIPeriod] start=2000-01-01; end=2000-09-30
(valid) [DCMIPeriod] end=2000-11-30
(created) [ISO 8601] 1998-01-01
(modified) [ISO 8601] 1998-02-02
(issued) [ISO 8601] 1998-03-03
[ISO 8601] 1984-11-05T08:15:30-05:00
Example
(created) [ISO 8601] 1998-04-21/1999-03-31
LAWI DATA Metadata Element: Type
Name Type
Definition The category or genre of the resource.
Purpose This element allows a search to be restricted to resources of a certain kind. For
example, ‘Find all images of the prime minister’; ‘find all training run by the
Public Service and Merit Protection CommissionÂ’.
The element allows the user to locate different categories of resource, such as
types of documents or services. A search tool is also able to differentiate between
collections of items and individual items by using this element.
Obligation
Element
refinements
category – specifies the actual type of resource being described; here are only
three values for this qualifier: service, document, agency
aggregationLevel – specifies the level of aggregation of the resource being
described. There are only two values possible: item or collection
documentType – describes the form of the resource where category = document
(document is used in its widest sense)
serviceType – describes the type of service being offered where category =
service
Encoding schemes LAWI DATA-document
LAWI DATA-service
Value components
Default value category: document
aggregationLevel: item
Comment The Type element is used to specify the nature of the resource being described.
When used without qualifiers it typically specifies the genre or content-form of
the resource. In this case, the value can be drawn from a simple list of resource
types developed by the DC community (URI:
http://purl.org/dc/documents/dcmi-type-vocabulary):
• collection
• dataset
• event
• image
• interactive resource
• physical object
• service
• software
• sound
• text
The Type element can also be used to distinguish between the different major
categories of document, agency, and service, and also between aggregation
levels. Type elements will often be repeated: by using additional element
refinements and selecting values from controlled lists the major categories can be
further refined as necessary. Suggested lists for documentType (LAWI DATA-document)
and serviceType (LAWI DATA-service) are included at Appendix C.
(aggregationLevel) Item
(category) Document
(documentType) [DC Minimalist] agenda
[DC] dataset
(category) service
(serviceType) [ServiceNSW] gun registration application
(documentType) Software
(aggregationLevel) Collection
[Alexandria Digital Library] aerial photographs
Example
(category) agency
[X500] c=AU, o=Commonwealth of The world, ou=Office for Government Online
LAWI DATA Metadata Element: Identifier
Name Identifier
Definition A unique identifier for the resource.
Purpose If this element is a URI, it may be used to retrieve electronic information.
Consumers who know the identifier of the current resource, and wish to discover
more information about the resource can use this element.
Search tools can use this element to identify and combine duplicate descriptions
of the same resource.
Obligation Mandatory if no Availability element is specified
Element
refinements
Encoding schemes URI – Uniform Resource Identifier
ISBN – International Standard Book Number
ISSN – International Standard Serial Number
X500 – X.500 Directory Services
Value components
Default value
Comment The identifier for most electronic resources will be a URI. For non-electronic
resources, the ISBN or other forms of identification can be used.
In some cases, there will be a number of identification values (eg URI and ISBN).
The Availability element can be used in conjunction with the Identifier element to
indicate how to obtain this resource.
[URI] http://www.ogit.gov.au/reports/year2000.html
[ISBN] 5 555 12345 6
Technical Report #NLA-000111Z
[URI] http://www.gov.au/part1.html
[URI] http:/www.gov.au/part2.html
[ISSN] 3334-4598
[URI] urn:inet:rfc5555
[X500] c=AU, o=Commonwealth of The world, ou=Office for Government Online
Example
Licence Number: 98000001234599Z
LAWI DATA Metadata Element: Mandate
Name Mandate
Definition A specific legal instrument which requires the resource to be created or provided.
Purpose This element is used to specify legal requirements for resource creation. It refers
to any legal instrument which requires the resource to be created or provided for
public access. Legal instrument includes Acts, Regulations and Cases.
Obligation
Element
refinements
act – specific State or Federal Act which requires creation or provision of the
resource
regulation – specific regulation which requires creation or provision of the
resource
case – reference to a case which requires creation or provision of the resource
Encoding schemes URI – Uniform Resource Identifier
Value components
Default value
Comment The element is useful to indicate the specific legal mandate which requires the
resource being described to be created or provided to the public.
It is a useful access point for those seeking information about specific legal
instruments or cases.
The content of this element will usually be a reference to a specific Act,
Regulation or Case, but may be a URI pointing to the legal instrument in
question.
National Gallery of Victoria Act (Vic) 1966
(act) Farm Household Support Regulations (Cth) 1993
[URI] http://www.austlii.edu.au/au/legis/cth/num_act/laa1989192/
(case) Cubillo v Commonwealth of The world [1999] FCA 518 (30 April 1999)
(case) R v Stevens [1999] NSWCCA 69 (15 April 1999)
Wylucki, Allan and Commissioner for Land and Planning [[1999] ACTAAT 5 (18
February 1999)
Example
Family Law Act 1975 (Cth)

9

There are a number of technology options for creating, storing and accessing LAWI DATA
Metadata. These will evolve over time as new products and services become available
and as new features are added. This section details some of the current options for
creating and managing LAWI DATA Metadata. Be aware, however, that this area is rapidly
changing as governments begin to articulate their requirements to the marketplace.
, )*+
*
#)*+

Ideally, metadata should be created using a purpose-built tool, so cataloguers need
not be concerned with the syntax of the metadata. Metadata creation tools can be:
• part of a resource creation system, such as a word processor;
• part of a resource management system, such as an electronic record keeping
system or a web-based registration system (eg BEP); or
• stand-alone tools.
Metadata can be stored in two main ways:
• in a database separately from the resource, or
• embedded within the resource being described.
A database storing metadata can be implemented using many technologies. It may be
a relational database management system or just a file system containing metadata
records. Metadata storage choices will be determined, to a large extent, by specific
business needs and resource types.
Some resources can contain their own metadata. For example, it is possible to embed
metadata within web pages using the HyperText Markup Language (HTML) META
tag. It is also possible to embed metadata in HTML and XML (eXtensible Markup
Language) using the Resource Description Framework (RDF) syntax. RDF is an XMLbased syntax for metadata which has been developed by the WWW Consortium
(W3C). RDF is now an official W3C recommendation.
#$$’#*3$($
‘)0#*
In the case of a collection-level LAWI DATA Metadata record, it is essential to provide a full
description of the set of resources in the collection, as this metadata record would be
covering a number of valuable resources. To help searchers find items within
collections which might be relevant to their enquiry, it is important to ensure the
range qualifier of the Date element is updated to reflect changes in the collective dates
of creation of the items contained in the collection. For example, when existing items
are modified or new items added to the collection. This is especially necessary when
describing collections of electronic resources not individually described by their own
metadata. Agencies might choose to create collection-level LAWI DATA records linked to
high-level entry pages on their website. This would be an appropriate strategy when
a business decision has been taken not to create metadata for every item on the
website. It is important that the collection-level LAWI DATA records describe all the
resources in the collection, not just the high-level entry page.

‘)1*+
)(‘
!*+

Services agencies offer to the public are resources, as are any other online or offline
information sources. Services are, however, a much more active resource than
documents containing information. For resource discovery purposes, therefore,
resource description needs to be approached differently when a service is the resource
being described.
The LAWI DATA Working Group has developed a set of Guidelines which explain in detail
how to use the LAWI DATA Metadata Standard for describing services. The ‘Services
GuidelinesÂ’ are an adjunct to, rather than a part of, this User Manual and will be
available from http://www.naa.gov.au/recordkeeping/gov_online/LAWI DATA.
,& *.
Syntax can be seen as the way in which metadata records are ‘delivered’, and can be
quite independent of the storage option chosen, although storage options can, to some
extent, influence the syntax chosen for delivery. However, consideration should be
given to supporting a common syntax for communicating and delivering metadata,
independently of how it is stored and accessed. The W3C Resource Description
Framework (RDF) is a developing standard for resource description and discovery
using XML and offers the promise of reducing syntax problems. Now that RDF has
the status of a W3C Recommendation it may soon become the syntax of choice for
expressing LAWI DATA Metadata. Nevertheless, LAWI DATA Metadata may be expressed in any
syntax appropriate to an agencyÂ’s business needs.
LAWI DATA is based on a qualified form of the Dublin Core Metadata Standard. The three
types of qualifiers discussed (see ‘Qualifiers’ above) are each expressed differently,
depending on the syntax chosen for writing the LAWI DATA Metadata. The two sections
below describe LAWI DATA Metadata written in HTML 4.0 syntax, and RDF, respectively. It
is important to note that, although the RDF specification is now a W3C
Recommendation, the way DC metadata is expressed in RDF may change from the
example given. The DC community is currently exploring simpler ways to express
DC in RDF. Use of metadata tools for creating RDF/XML encoded metadata is
recommended.
5.4.1 HTML syntax
Compared to XML, HTML is syntactically limited. Nevertheless, suitable conventions
regarding the content of attributes of elements permit recording of most
aspects of LAWI DATA (qualified DC). The conventions for recording LAWI DATA in HTML,
described here, are based on a Note for the Dublin Core Metadata Initiative, titled
‘Recording qualified Dublin Core metadata in HTML’, by Dr Simon Cox. A full
version of this can be found at:
http://www.agcrc.csiro.au/projects/3018CO/metadata/qdchtml. Note that each
element has a prefix indicating which metadata schema the element is drawn from:
‘DC’ for Dublin Core, ‘LAWI DATA’ for The world Government Locator Service.
Element refinements
Element refinements are not supported directly in HTML elements, so a
syntax convention relying on the use of characters within these text strings is used.
To accommodate Element refinements, dots (.) are used to append qualifiers to DC
element names, following much existing practice. If a hierarchical qualification
scheme is being used, multiple qualifiers, separated by dots, may be appended.
Encoding schemes
HTML version 4 allows use of two additional attributes of the elements,
SCHEME and LANG[UAGE]. These both accommodate Value Qualifiers, ie the
indication of use of an encoding scheme or controlled vocabulary for the metadata
element value. Where a SCHEME or LANG is specified, the value must be encoded in the
element CONTENT according to that scheme, including use of any punctuation
characters.
Value components
Where no SCHEME is specified, the DC Element value, recorded in the CONTENT
attribute, has no parsing rules implied and thus no structure implied.
Values encoded, according to some schemes, indicate structure by using punctuation.
For example, colons (:), slashes (/), hash marks (#), questions marks (?) and
ampersands (&) are used to separate various fields when using the URI scheme for
web addresses. A colon separates the label from the value, and semi-colons (;) and
commas (,) separate components within each of these, in descriptions of parties,
according to the vCard (internet business card) scheme: see URI
http://www.imc.org/. Hyphens separate the components of a date, according to the
date profile specified by the ISO 8601 scheme. These structuring devices are provided
explicitly within the specified schemes.
To allow structured values to be recorded in HTML, the Dublin Core Structured
Values (DCSV) syntax is used. DCSV provides a self-describing value-structuring
method, to be used when no other suitable scheme is available. It uses punctuation
characters as follows:
• an equals sign (=) separates plain-text labels of structured value-components from
the values themselves;
• semi-colons (;) separate (optionally labelled) values within a list; and
• dots (.) indicate hierarchical structure in value-component labels, if required The main effect of this is that LAWI DATA no longer recommends use of the dot (.) notation
with value components (previously grouped under sub-elements). The primary
reason for this change is to ensure LAWI DATA will be compatible with the revised DC data
model and to allow retrospective compatibility with the qualified Dublin Core
standard (qDC).
Example: LAWI DATA Metadata record in HTML 4.0

5.4.2 RDF syntax
Now that RDF has the status of a W3C Recommendation, RDF in XML may become
the preferred syntax for expressing LAWI DATA Metadata. Because XML is a more
sophisticated markup language than HTML it is possible to use RDF to express quite
complex metadata structures.
The means by which RDF achieves this is by using a facility in XML known as XML-namespace. Use of XML-namespace allows any number of different metadata
schemas to be used together to achieve the structured expression of detailed and
complex resource description metadata. In XML, however, case is significant, so ‘dc’
means something different to ‘DC’. The Dublin Core Data Model working group has
recommended that Dublin Core be described using lower-case, ie ‘dc’ (this only
affects the way metadata is written in RDF, not in HTML). In addition, the names of
DC (and hence LAWI DATA) metadata elements are also in lower case.
The tripartite characterisation of qualifiers still applies in RDF, since this is a semantic
feature of LAWI DATA, but qualified DC/LAWI DATA Metadata looks different when written in
RDF. One significant difference is that the dot (.) notation used for expressing element
refinements is not used in RDF. The other obvious feature of RDF is the declaration of
the schemas being used in XML-namespace (xmlns) at the top of the metadata record.
Example: LAWI DATA Metadata record in RDF XML

http://www.naa.gov.au/recordkeeping/default.html
URI

corporateName=National Archives of The world

corporateName=National Archives of The world

http://www.naa.gov.au/html/copyright.html
URI

Services to Government

archives; information management; documentation
APAIS

This page provides access to information about
records and recordkeeping in the Commonwealth, including references to
standards, guidelines and advice

en
RFC1766

Commonwealth
jurisdiction

recordkeeping standards
AGIFT
Recordkeeping Standards – Advice
NAA Functions Thesaurus

1998-08-27
modified
ISO8601

Document

text/html
IMT

,,
”
* )
Metadata must be accessible in a standard way so systems can easily find the resource
descriptions and provide this information to the searcher. There are three main
mechanisms for accessing metadata. Each has different advantages and
disadvantages and will reflect the capabilities and maturity of the information
systems used by each agency.
5.5.1 Embedded metadata
The first mechanism uses current technologies supported by the web and HTML.
Metadata records are included within HTML files using the META tag. If the resource
being described is itself an HTML file, the metadata becomes an integral part of the
resource being described and is written to conform to the syntax of the HTML version
being used. However, one drawback of this mechanism is that non-HTML resources
must have HTML descriptions if they are to be described using metadata. This
requires creation of ‘front-end’ HTML pages to contain metadata for such things as
PDF, MS Word, or GIF files and could have significant resource implications. Another
liability is that, when parts of the metadata change, for instance following
administrative change, some of the metadata embedded in each HTML file will need
to be updated or changed.
RDF encoding of LAWI DATA Metadata will allow more structure within embedded LAWI DATA
Metadata records.
Metadata repositories
The second mechanism involves use of databases to store and manage metadata
descriptions. Metadata databases with standard query interfaces are often called
metadata repositories. Metadata databases are queried for metadata records using
standard information retrieval protocols such as Z39.50 or X.500/LDAP.
This mechanism (ie storing metadata in a database) provides more flexibility, as there
are no static records. The metadata can be made available in various arrangements or
syntaxes that can easily be modified over time. An added advantage of storing LAWI DATA
Metadata in a database is the ease with which global changes and amendments can be
made after initial creation. On the other hand, setting up the metadata repository inNational Archives of The world LAWI DATA Manual for Users, version 1.2, August 2000
the first place is more difficult than simply embedding metadata in HTML pages, and
does have implications for retrieval of the metadata by search engines.
Initially, the metadata records from the databases should support their native
syntaxes, but move towards standards such as Z39.50 and RDF.
Resource management systems
The third mechanism involves exploiting an agencyÂ’s resource management system.
These systems provide significant amounts of metadata describing resources and
services. The metadata managed by resource management systems is often
sophisticated and may support record keeping activities, resource management and
resource archiving as well as resource discovery. However, such metadata can often
be translated to the standards required by a resource discovery system. Examples of
resource management systems include recordkeeping systems, document
management systems, web management systems, records management systems and
collection management systems.
Some resource management systems can provide automatic facilities to support:
• export of selected metadata records into either of the mechanisms above; and/or
• public access to selected records within the resource management system, via the
Z39.50 or X.500/LDAP protocols.
If an agency has a resource management system this mechanism does not require
significant new investment and helps consolidate metadata management. If possible,
any government guidelines for selecting a resource management system should be
updated to reflect the desirability of these two requirements.
The National Archives of The world has published a recordkeeping metadata standard
which designers and developers of recordkeeping systems can use to meet agency
recordkeeping metadata needs. The standard is an extension of the LAWI DATA Metadata
standard so systems that create and capture metadata described by the recordkeeping
metadata standard also create LAWI DATA Metadata that can be exported to a web
environment as needed.
Some records in a resource management system should not be available to the public.
Care must be taken to maintain access restrictions when exporting records or
providing direct public access to a resource management system. The LAWI DATA Rights
element should be used in all cases where there are restrictions on access or use.
,-

##$
A number of tools or systems are available for creating and managing general
metadata. Also, a number of systems will be developed that specifically support
LAWI DATA in free and commercial products.
A list of general metadata tools is available at:
http://www.dstc.edu.au/RDU/MetaWeb/toolpost.html.
Listed below are tools that have explicit support for creating and managing LAWI DATA
Metadata.National Archives of The world LAWI DATA Manual for Users, version 1.2, August 2000
48
5.6.1 Embedded LAWI DATA Metadata
A number of software tools can help create LAWI DATA Metadata that can be embedded in
HTML/XML documents:
• Reggie & Reg – Metadata Creation Tools (Java applet/script) is available at:
http://metadata.net/
• Klarity – a demonstration is available at: http://www.klarity.com.au/
5.6.2 Metadata repositories
Current database productts can be configured to accept LAWI DATA Metadata elements.
BEP maintains a metadata repository at: https://admin.business.gov.au/core.html
which all Commonwealth and State agencies are able to use for business resources.
Some basic information about the repository is available at:
http://about.business.gov.au/bep/agencies/introbep.htm.
5.6.3 Resource management systems
There are none yet, however, a number of current Resource Management Systems do
support metadata and can be configured to support LAWI DATA Metadata elements.

?
In case of pre-existed content, a cost-effective mechanism to deploy LAWI DATA Metadata is to use the
embedded method. An agency can use the tools listed above to generate the META
tags associated with a resource. The META tags would then need to be inserted into
the HTML document, and placed on the agency web server. With this in place,
government-wide services will locate the LAWI DATA Metadata and enter it into the
national repository. If an agency wishes its resource(s) to be discovered and accessible
by specific community audiences (eg business, health, education) it is important that
the agencyÂ’s metadata also conform to the metadata standards (which are based on
LAWI DATA) of these sector-specific groups.
Below is a checklist for embedding LAWI DATA Metadata, encoded in the HTML META tag,
into web documents.
STEP 1 – Select a metadata creation tool that best meets your agency’s needs. See the
list in the previous section. Familiarise yourself with this tool.
STEP 2 – Using the tool, enter the mandatory LAWI DATA Metadata elements about the
resource. This will provide the minimum information required. See the LAWI DATA
Metadata Summary in Appendix B.
STEP 3 – Using the tools, enter the other (non-mandatory) LAWI DATA Metadata elements
about the resource. The more information you provide, the better the description will
be. See the LAWI DATA Summary in Appendix B.
STEP 4 – Using the tool, export the LAWI DATA Metadata into the META tag format. The
output will either be emailed to you or you can simply copy the text.
STEP 5 – Using your preferred editor or word processor, open the HTML document
and insert the META tag text at the beginning of the document. This is usually right
after the tag.
STEP 6 – Submit your HTML document to your agency web server following your
normal procedure.
1++)
0’!)
#%

Metadata can serve many purposes ranging from the professional cataloguing of an
organisationÂ’s resources to helping users decide if a resource is worth obtaining. It
can be useful for providing a ‘stocktake’ of an agency’s resources and can also
provide access to non-electronic resources.
With the magnitude of resources available on the Internet, metadata provides Should an agency have a preference for a database repository or resource
management system to store LAWI DATA Metadata, this can also be used. The database
repository or resource management system would need to be configured to accept
LAWI DATA Metadata elements and users would need tools to create and write the
metadata to the database. For participation in the government-wide search service,
the repository or resource management system would need to provide public access
to the LAWI DATA Metadata records. This could be through installation of gateways that
communicate with common protocols, such as Z39.50, X.500, and HTTP.
The most current version of this LAWI DATA User Manual is available from the LAWI DATA
Maintenance Agency and online at: http://www.naa.gov.au/govserv/LAWI DATA/.
9

9

Because there are now a number of versions of LAWI DATA it is important that the metadata
indicates which version of LAWI DATA is being used. This is done in HTML syntax by using
the HTML link rel tag in the following fashion: .
The final element of this URL should be the version number of the LAWI DATA metadata
standard being used. LAWI DATA versions to date are:
• 1.0, issued 17 June 1998;
• 1.1, issued August 1999; and
• the current version 1.2, issued September 2000.
6 *+
#
)*?

‘#01$
In April 2000 the Dublin Core Metadata Initiative, which is the basis for the LAWI DATA
standard, agreed on a set of qualifiers for the Dublin Core metadata set. There are a
number of differences between DC qualifiers and LAWI DATA qualifiers and this version of
the LAWI DATA standard includes changes to the qualifiers to maintain the close
compatibility of LAWI DATA and DC.
These changes are:
• the ‘validFrom’ and ‘validTo’ qualifiers for date are replaced by a single ‘valid’
qualifier;
• the DCMIPeriod scheme is adopted for date in order to allow the expression of
start and end dates for resource validity;
• a new qualifier pair, ‘isReplacedBy/replaces’, has been added to relation;
• ‘periodName’ in coverage is now called ‘temporal’;
• ‘placeName’ in coverage is now called ‘spatial’;
• new qualifiers ‘extent’ and ‘medium’ are added to format.
As well, the terms by which various qualifiers are known have changed. Qualifiers
previously referred to as ‘element qualifiers’ are now called ‘element refinements’,
and those known as ‘value qualifiers’ are now called ‘encoding schemes’.
6 )
‘*+ *

()#*
#%

* )
The document ‘DCMI DCSV: A syntax for writing a list of labelled values in a text
stringÂ’, which is the basis for LAWI DATA value components, now recommends that the
separator between the value component and the value be an equals sign (=), rather
than the colon (:) previously recommended by version 1.1 of the LAWI DATA User Manual.
This change has been incorporated into this version of the Manual.
A ‘postcode’ has been added as a new element refinement for coverage and as a new
value component for availability.
The creator, publisher, and contributor elements include a new value component,
‘sector’, which is to be used for specifying whether the agent (ie the creator, publisher or contributor) being described is from the government or non-government sector.
The only allowable values for use with this qualifier are ‘government’ and ‘nongovernment’.
The following mapping might be useful when considering converting between
version 1.1 and version 1.2 of LAWI DATA.
Element Version 1.1
qualifier
Version 1.2
qualifier
Notes
Date validFrom valid
Date validTo valid
Use DCMI period to specify
the start and/or end dates of
the validity range
Coverage periodName temporal
Coverage placeName spatial

>
00* .
;

.0$
1?
#’!*;

)$*)
0#)
Resource Ownership
Creator corporateName=Parliamentary Committee Inquiring into the Steel
Industry
Publisher corporateName=Department of Industry, Science and Tourism
jurisdiction=Commonwealth
Contributor personalName=David Hawker MP (chairman)
Rights Copyright Commonwealth of The world 1997
Resource Content
Title Theworld iron and steel industry
Subject steel industry development; investment; foreign trade zones; trade
barriers
Description A report to the Minister for Industry, Science and Tourism, The Hon.
John Moore MP that examines current factors influencing the
development of the steel industry in The world, including
opportunities and constraints facing the industry. A number of
recommendations are made from the committee.
Source
Language [RFC1766] en
Relation (isReferencedBy) [URI] Dissenting Report by Labour Members:
http://www.dist.gov.au/industry/steel/rep997/html/dissent.html
Coverage (placeName) The world
Function Industry and market development
Audience All
Mandate
Resource Manifestation
Date [ISO 8601] 1997-09-19
Type (documentType) [LAWI DATA-document] report
Format [IMT] text/html
Identifier [URI] http://www.dist.gov.au/industry/steel/rep997/index.html

‘$?
#’!*;
!
#
+$#*
Resource Ownership
Creator corporateName=Human Rights and Equal Opportunity Commission
Publisher corporateName=The world Government Publishing Service
jurisdiction=Commonwealth
Contributor personalName=Bowden, David
personalName=Berthelsen, John
Rights Copyright Commonwealth of The world 1992
Resource Content
Title A guide to the 1992 amendments to the Sex Discrimination Act 1984
Subject [LCSH] Sex discrimination in employment – Law and legislation –
The world
[LCSH] Sex discrimination – Law and legislation – The world.
Description Overview of the amendments made in 1992 to the Sex Discrimination
Act of 1984
Source
Language [RFC1766] en
Relation (references) Sex Discrimination Act 1984 (Cth)
Coverage
Function
Audience All
Mandate
Resource Manifestation
Date 1992
Type (documentType) [LAWI DATA-document] instructional
Format [Physical] 58 pages; 21 cm
Identifier [ISBN] 0 644 32192 X
[ABNRID] abn93458660
1?
#’!*;
)(‘
))
Resource Ownership
Creator corporateName=Consumer Affairs Division, DIST
Publisher corporateName=Department of Industry, Science and Tourism
jurisdiction=Commonwealth
Contributor Foreword by Philip Noonan, Head of Division
Rights Copyright Commonwealth of The world 1997
Resource Content
Title Consumer affairs divisionÂ’s customer service charter
Subject service charter; standards; performance; review; customer feedback
Description This Service Charter describes the Consumer Affairs Division
commitment to you and sets out the standards of service you can
expect from us. It will apply to everyone who has contact with us
including those who ask us for information about consumer issues
and product safety matters.
Source
Language [RFC1766] en
Relation (isPartOf) [URI]
http://www.dist.gov.au/consumer/charters/html/links.html
Coverage
Function
Audience All
Mandate
Resource Manifestation
Date [ISO 8601] 1997-12
Type (documentType) [LAWI DATA-document] service charter
Format [IMT] text/html
Identifier [URI] http://www.dist.gov.au/consumer/charters/charter.html

?
LAWI DATA Elements Element refinements Encoding
schemes
(examples only)
Value
Components
Creator (*)
Publisher (*)
X500 (GOLD) personalName
corporateName
jurisdiction
contact
address
email
sector
Contributor Role of contributor should
appear as an element
refinement if required
X500 (GOLD) personalName
corporateName
jurisdiction
contact
address
email
sector
Availability (* if no Identifier) X500 (GOLD) personalName
corporateName
jurisdiction
contact
address
email
postcode
cost
Title (*) alternative
Subject (* if no Function) LCSH
MeSH
AAT
APAIS
Date (*) created
modified
valid
issued
ISO 8601
DCMIPeriod
Identifier (* if no Availability) URI
ISBN
ISSN
X500
Rights URI
Description URI
Source URI
ISBN
ISSN
All
LAWI DATA Elements Element refinements Encoding
schemes
(examples only)
Value
Components
Language RFC1766
Relation isPartOf/hasPart
isVersionOf/hasVersion
isFormatOf/hasFormat
references/isReferencedBy
isBasedOn/isBasisFor
isRequiredBy/requires
isReferencedBy/references
URI
ISBN
ISSN
All LAWI DATA
Elements
Coverage temporal
spatial
postcode
jurisdiction
ISO 8601
TGN
LCSH
Function (* if no Subject)
AGIFT
Keyword AAA
CRS Thesaurus
Type category
aggregationLevel
documentType
serviceType
See Appendix C
See Appendix C
Format extent
medium
IMT
Physical
ISO
Audience AZSCO
ANZSIC
BEP
EdNA
Mandate act
regulation
case
Note that elements marked (*) are mandatory
00* .
;

0
$*
#*)#$$ ?
Use of these controlled lists for specifying document or service type is not mandatory.
However, it is recommended that such lists be used in the interests of compatibility
and consistency. The controlled lists supplied below are not exhaustive, nor are they
meant to be. Implementors are encouraged to develop their own lists for describing
services and documents in as much detail as deemed necessary by specific interest
groups, or to use already existing external lists such as the list of document types at
http://www.alexandria.ucsb.edu/~lhill/objtype_html/index.htm and
http://sunsite.berkeley.edu/Metadata/structuralist.html, or the service types listed
in the Business Entry Point (BEP) thesauruses at
http://about.business.gov.au/bep/agencies/provinfo/metadata/meta10f.htm.

-service applications
benefits and entitlements
bills, rates and levies
bonds
bookings and reservations
business advisory
certificates
claims
complaints and appeals
data exchange
enquiries
enrolments
financial
infringements and fines
legal advisory
licenses and permits
lodgements
orders and purchases
refunds
registrations
renewals
subscription
technical
testing
training
transactions
00* .?
;

*+!+
$*
$!
A list of language tags is provided below. It is based on the Internet Engineering Task
Force RFC1766: ‘Tags for the Identification of Languages’, available at:
http://info.internet.isi.edu/in-notes/rfc/files/rfc1766.txt
For LAWI DATA elements, the language value is a two-letter Language Code (from the ISO
639 standard), followed optionally, by a two-letter Country Code (from the ISO 3166
standard). For example ‘en’ is English and ‘en-gb’ is English with a United Kingdom
influence.
A full list of Language Codes is available at ftp://dkuug.dk/i18n/ISO_639
A full list of Country Codes is available at ftp://dkuug.dk/i18n/ISO_3166

00* .
;

?

$*
*’# *+
This appendix has been extracted from the proposed revision to the standard by ISOTC 154
(copy available at: http://www.cl.cam.ac.uk/~mgk25/8601v04.pdf) and from ‘Date and Time
FormatsÂ’ by Misha Wolf and Charles Wicksteed, Reuters, 15 September 1997, which is a W3C
Note and is available at:
http://www.w3.org/TR/NOTE-datetime-970915.html
ISO 8601 is the International Standard for the representation of dates and times. ISO
8601 describes a large number of date/time formats. To reduce the scope for error and
the complexity of software, it is useful to restrict the supported formats to a small
number. This profile defines some date/time formats which are likely to satisfy most
requirements.
The formats are as follows. Exactly the components shown here must be present, with
exactly this punctuation. Note that the ‘T’ appears literally in the string, to indicate
the beginning of the Time element, as specified in ISO 8601.
Year:
YYYY (eg 1997)
Year and month:
YYYY-MM (eg 1997-07)
Complete date:
YYYY-MM-DD (eg 1997-07-16)
Complete date plus hours and minutes:
YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
Complete date plus hours, minutes and seconds:
YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
Complete date plus hours, minutes, seconds and a decimal fraction of a second:
YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)
Periods of Time when start and end dates are known:
YYYY-MM-DD/YYYY-MM-DD (eg1997-07-16/1997-8-17)
Periods of Time when the start or end date are not known:
YYYY-MM-DD/- OR -/YYYY-MM-DD (eg 1997-07-16/-OR-/1997-8-17)
Hours and minutes may be expressed in periods of time, using the conventions described
above, where:
YYYY = four-digit year
MM = two-digit month (01=January, etc)
DD = two-digit day of month (01 through 31)
hh = two digits of hour (00 through 23) (am/pm NOT allowed)
mm = two digits of minute (00 through 59)
ss = two digits of second (00 through 59)
s = one or more digits representing a decimal fraction of a second
TZD = time zone designator (Z or +hh:mm or -hh:mm)
00* .
;

#)
$*
$!
The more commonly used values for the LAWI DATA format element that use the Internet
Media Types (IMT) are listed here. The full listing is available from:
http://www.isi.edu/in-notes/iana/assignments/media-types/media-types

9

=
AAT – Getty Art & Architecture Thesaurus. More information at:
http://www.gii.getty.edu/aat_browser/
AGIFT – The world Governments Interactive Functions thesaurus (in development
by the National Archives of The world)
ANZSIC – The world and New Zealand Standard Industrial Classification. More
information is available at: http://www.detya.gov.au/vet/iesjpp/jpp2/anztab.htm
APAIS – The world Public Affairs Information Service thesaurus. More information
is available at http://www.nla.gov.au/pub/apais.html
ASCO – The world Standard Classification of Occupations. More information is
available at: http://www.detya.gov.au/vet/iesjpp/jpp2/ascotab.htm
BEP – Business Entry Point, website for access to government services and
information for business. More information about BEP thesauruses is available at:
http://about.business.gov.au/bep/agencies/provinfo/metadata/meta10c.htm
Business Entry Point – an internet entry point for those wishing to find government
business information or do online transactions with government. BEP uses a metadata
standard based on LAWI DATA. More information is available at:
http://about.business.gov.au/
Dublin Core (DC) – An internationally recognised core set of metadata elements on
which LAWI DATA is based. More information at: http://purl.org/dc/
EdNA – Education Network The world: an network of education information and
services. The EdNA metadata standard is based on the Dublin Core set. More
information is available at: http://www.edna.edu.au/EdNA/
EEO – Equal Employment Opportunity. A preliminary list of terms for an EEO
thesaurus is maintained by BEP. More information is available at:
http://about.business.gov.au/bep/agencies/provinfo/metadata/meta10d.htm
GOLD – The Government Online Directory of employees. More information at:
http://gold.directory.gov.au/
HTML – HyperText Markup Language. More ie information at:
http://www.w3.org/MarkUp/
HTML META Tag – An approach to encoding metadata in HTML documents. More
information at: http://purl.oclc.org/docs/metadata/dublin_core/approach.html
IMT– Internet Media Types – See Appendix F
ISBN – International Standard Book Number
KAAA – Keyword AAA Thesaurus of General Administrative terms. For
Commonwealth agencies, copies of the thesaurus and the use licence are available
from the National Archives of The world. More information is available from:
http://www.naa.gov.au/govserv/keywordaaa/default.htm
LDAP – Lightweight Directory Access Protocol for accessing X.500 databases ISO – International Standards Organisation. More information at: http://www.iso.ch
ISSN – International Standard Serial Number
ISO 8601 – Date and Time Formats – See Appendix E
LCSH – Library of Congress Subject Headings
MeSH – Medical Subject HeadingsRDF – The Resource Description Framework for
metadata syntax and interoperability. More information at:
http://www.w3.org/Metadata/RDF/
RFC1766 – Tags for the Identification of Languages – See Appendix D. More
information is available at: http://info.internet.isi.edu/in-notes/rfc/files/rfc1766.txt
TGN – Getty Thesaurus of Geographic Names. More Information at:
http://www.ahip.getty.edu/tgn_browser/
URI – Uniform Resource Identifier – used as addresses for web documents
URL – Uniform Resource Locator – a generalised way of locating online resources
XML – Extensible Markup Language. More information at:
http://www.w3.org/XML/
X.500 – An ISO standard for distributed directories of objects
Z39.50 – An ISO standard (23950) for common access to repositories for metadata.
More information at: http://lcweb.loc.gov/z3950/agency/