About the Lawi Project

• Who We Are
• Who We Serve
• How We Work
• Where We Are

Overview of the Lawi Project

• Mission and Vision Statement
• Background of the Project
• Lawi Project Description
• Lawi Manifesto

About Lawi Data

What is Lawi Data?

The Lawi Data Project provides several resources relating to metadata and vocabularies in the legal sector.

It intends to provide a generic and easily extensible framework for the XML encoding of the structure and contents of legal and paralegal documents. This obviously includes legislation and case law, but also written public decisions, internal and external business regulations (for instance ship classification rules as in [Winkels et al. 1999]), and contracts. XML elements and structure are defined in schemas that can be used to validate a document.
Since there is a great variety of legal documents that cannot be covered by one normative standard, the Lawi Data Proposal consists of multiple schemas defining vocabularies that can be mixed in a document.

Other Usueful Resources

CEN workshop on an Open XML interchange format for legal and legislative resources

CEN workshop on an Open XML interchange format for legal and legislative resources. The workshop officially started on July 7 2006. The objective of the Workshop is to develop a CEN Workshop Agreement (CWA) on an Open XML interchange format for legal and legislative resources; The CWA is accepted by the CEN and associated standard organisations as a publicly available specification (PAS or pre-norm).

1.2 How do I make my resources accessible via LawAccess Online?
To make your legal resources and services accessible via LawAccess Online, you must add
metadata that conforms to the AGLS and the Justice Sector Metadata Standard (JSMS) schemes
to your webpages. In particular, the JSMS document scheme must be included in your metadata
as it will enable LawAccess Online to access the resources on your website.
Once you have added the metadata, contact LawAccess NSW with the address of your website
and we will harvest your website. Harvesting is the process by which LawAccess Online collects
the metadata from your webpages and ensures your resources are accessible through
LawAccess Online.
To ensure that our customers obtain plain language legal information that is accurate and
up to date, your website should conform to the Law and Justice Foundation of NSW,
Best Practice Guidelines for Australian Legal Websites at http://www.lawfoundation.net.au/
publications/guidelines/bpguide.html
By complying with these guidelines, customers can have confidence in the quality of the
information accessible via LawAccess Online.
1.3 Will all webpages with JSMS metadata be accessible by LawAccess Online?
No, LawAccess Online is designed to facilitate access to plain language legal materials and
will not initially include formal reports, primary materials or press releases. However, the JSMS
metadata can be picked up by other metadata enabled search engines such as the NSW
Government Online Entry Point http://www.nsw.gov.au.
1.4 How does LawAccess Online incorporate my metadata?
Metadata is harvested from the contributing websites, stored in the LawAccess OnlineÂ’s metadata
database and then accessed via the search interface. The customer will view part of the metadata
and a link to your resource.
1.5 Will my webpages be monitored by LawAccess Online?
There is no formal audit process. However, to ensure best practice, we will randomly check the
resources accessible via LawAccess Online to verify the accuracy of the metadata. Your metadata
may also undergo a validation process to ensure it conforms to the JSMS

Is a standard necessary?
The major reason for having an agreed standard is to ensure consistency across different websites
in the way information is described. Metadata allows search engines to find relevant and useful
information for consumers on particular topics.
For many people, finding information or services on the Internet can be frustrating. Some of the
most common problems encountered by Internet users when searching for information or services
are getting:
1. too many results
2. irrelevant or inappropriate information.
As a result, customers may miss important and relevant information.
The inclusion of metadata on websites aims to assist:
• customers to find reliable information quickly and easily
• website authors and administrators to organise their website information.
2.3 Can you see metadata on a webpage?
No. Metadata usually sits behind the webpage in what is called the ‘source code’.

The AGLS metadata standard is a set of 19 elements or fields. AGLS is based on the leading
international metadata standard, the Dublin Core Standard.
The AGLS metadata has been adopted by all Australian State and Territory governments.
In NSW, all government agency websites are required to comply with AGLS. State Records NSW
has also issued guidelines for the use of AGLS for government record keeping.
The aim of AGLS is to enhance the accessibility of government services to the community. Until
recently the community has needed to understand government structures to access information.
The use of metadata has enabled information to be organised in a way communities understand,
by subject or topic. The same principle underlies the development of JSMS.
3.2 How does JSMS fit in with AGLS?
The JSMS is a subset of the AGLS metadata standard.
EXAMPLE
AGLS metadata includes a ‘subject’ field to describe the subject matter of the web resource.
AGLS recommends that a thesaurus or controlled vocabulary be used to ensure all resources
on the same topic use the same subject heading. To be meaningful, the subject terms need to
be specific to the legal sector.
JSMS uses the ‘LIAC’ (Legal Information Access Centre) subject headings scheme, which
have been developed in conjunction with the Legal Information Access Centre to reflect the
way consumers think about legal issues.
The JSMS schemes can be used in the AGLS fields to describe legal information resources and
services. JSMS has been designed to comply with the requirements of AGLS version 1.3. JSMS
will be updated to ensure continuous compliance to AGLS.
JSMS defines a minimum set of AGLS metadata fields. The standard does not preclude the use
of optional AGLS fields and other schemes in addition to the JSMS schemes.
3.3 Will I comply with AGLS if I use JSMS?
AGLS allows sectors to create sector specific metadata schemes to be used in AGLS fields. For
example, the LIAC subject headings scheme is in plain language terms that describe particular
areas of law. The JSMSDocument scheme describes the types of resources, for example, case,
Act, legislation or factsheet.
In this way, JSMS is fully consistent with AGLS but is enhanced to reflect the specific needs
of justice sector organisations and consumers.

What is the Justice Sector Metadata Standard?
The Justice Sector Metadata Standard (JSMS) is a metadata set to describe legal resources and
services.
4.2 Why should the justice sector have a metadata standard?
A major issue confronting people in the justice system is how to find relevant and reliable legal
information and services. This is sometimes critical when time limits may operate on obtaining
remedies, or where getting the wrong information may lead to unnecessary costs or other
disadvantage.
Government, the community and the private legal sector have created thousands of plain
language legal resources that enhance access to justice. Use of metadata enables websites
like LawAccess Online to provide easy access to legal information that is reliable and specific
to a particular jurisdiction.

What are the JSMS fields?
The following list includes the standard metadata fields for the justice sector. The fields marked
with an asterix (*) are compulsory fields.
* DC.Title
* DC.Creator
* DC.Publisher
DC.Rights
* DC.Subject
Keywords
* DC.Description
Description
* DC.Language
* DC.Coverage
* DC.Coverage.jurisdiction
DC.Coverage.spatial
* DC.Date.created
* DC.Date.modified
* DC.Type.documentType
DC.Type.category
DC.Format
* DC.Identifier
AGLS.Availability
AGLS.Audience
Admin.Creator
Admin.DateCreated
Admin.DateValidTo
DC=Dublin Core
AGLS=Australian Government Locator Service

Should I use HTML tags as well?
Yes. HTML tags, such as, Description and Keywords are traditionally used to define the content of resources on the web. This system is being replaced by the DC scheme, however, many search facilities do not yet read DC metadata fields. These HTML tags should be used to improve relevance of search results from search engines, such as Google. These fields correlate to DC.Title, DC.Description and DC.Subject. You may wish to copy and paste the content of these fields to reduce data entry. 5.11 How do I include multiple terms in a metadata field? Terms in the metadata field should be separated by a semicolon ‘;’ followed by a space. For example: META NAME=“DC.Subject” Scheme=”LIAC” CONTENT=”Courts; Dispute resolution” Don’t use a comma ‘,’ or colon ‘:’ to separate terms as these are used for punctuation purposes. 5.12 How does the metadata look if you view the HTML source code? Below is a table of standard metadata fields and HTML tags for the justice sector, as they would appear in an HTML document:

DC.Title
What do I put in this field? The name of the resource.
How do I complete this field? Use the title as it appears on the resource itself.
Example

Title
What do I put in this field? The same name as given to DC.Title.
How do I complete this field? Use the same title as in DC.Title field.
ExampleGuide to the Law on the Internet – NSW

DC.Creator

Example

DC.Publisher
What do I put in this field? The name of the organisation responsible for
producing the resource, such as the name of the organisation
that owns the website. If the publisher name has a well-known acronym,
add the acronym in brackets at the end of the
name.
You can enter more than one name for joint
publications. Separate these with semicolons.
Example

DC.Subject
What do I put in this field? A broad topic heading to describe the area of law
the resource belongs in eg. employment.
Is this field compulsory? Yes
Can I include more than one item in this field? Yes
Is there a scheme for this field? Yes
Scheme: LIAC
See Appendix A for the LIAC Subject Headings
Scheme.
How do I complete this field? Select one or more of the terms from the LIAC
Subject Headings Scheme, second level subjects.
Separate these with semicolons.
Determine the subject from the resource content.
The LIAC subject headings has been designed to
describe plain language legal resources. The top
level topics are used for display of resources and
are not included in the metadata.
The Keywords field and DC.Description can be
used for entering words not included in the LIAC
subject headings.
Example

Keywords
What do I put in this field? Terms that assist in describing the resource in
addition to those used in DC.Subject e.g. renting;
unfair dismissal.
Is this field compulsory? No, but it is recommended to improve results from
search engines like Google.
Can I include more than one item in this field? Yes
Is there a scheme for this field? No
How do I complete this field? The terms used to complete the keywords field
should be descriptive of the content of the resource.
Try to limit the number of keywords to a maximum
of six.
Try not to use keywords that are too broad, as
this will result in users retrieving irrelevant material.
Avoid terms such as ‘law’, ‘rights’ etc. as they
can be associated with almost any legal resource.
The effect of using terms such as these will be that
customers searching for information on ‘tenancy
law’, for example, may return any resources
that used the term ‘law’ in the keywords field,
regardless of whether it relates to tenancy.
Other keywords to avoid are ‘legal information’
and ‘legal advice’.
Example

DC.Description
What do I put in this field? A concise description of the content or purpose of
the resource.
Is this field compulsory? Yes
Can I include more than one item in this field? No
Is there a scheme for this field? No
How do I complete this field? Generally, the description should be one or two
sentences – just enough to help a user decide
whether to view the resource. Use information from
the abstract or summary of the resource,
if available.
The description will often be displayed as part of
the search results. In writing a description, think of
the target audience and what they might need to
know about the resource.
Example

Description
What do I put in this field? The same content as DC.Description.
Is this field compulsory? No, but it is recommended to improve the results
from search engines like Google.
Can I include more than one item in this field? No
Is there a scheme for this field? No
How do I complete this field? Use the description from the DC.Description field.
Example

DC.Language
What do I put in this field? The language of the resourceÂ’s content.
Is this field compulsory? Yes
Can I include more than one item in this field? Yes, for example, if the resource has links to
documents in a variety of different languages.
Is there a scheme for this field? Yes
Scheme: RFC3066 – Tags for the identification
of languages.
Appendix B contains a list of commonly used
languages. The full list of codes is available
at http://lcweb.loc.gov/standards/iso639-
2/englangn.html.
How do I complete this field? Use the default ‘en’ for English.
If there is not a two-letter language code under the
scheme you can use the applicable three-letter
code.
More than one language can be entered. For
example, the metadata might be on a cover page
that links to versions of a document in different
languages. Use a semicolon between each entry.
Example

DC.Coverage
What do I put in this field? The country to which the resource relates.
Is this field compulsory? Yes
Can I include more than one item in this field? Yes, for example, if the resource is a report about
legal issues in a variety of different countries.
Is there a scheme for this field? Yes
Scheme: ISO3166 – Tags for the identification of
countries.
See Appendix C. The full list of codes is
available at http://www.iso.org/iso/en/prodsservices/iso3166ma/02iso-3166-code-lists/
list-en1.html
How do I complete this field? Use the default ‘au’ for Australia.
Example
Name DC.Coverage.jurisdiction
What do I put in this field? The geographic area based on legal jurisdiction of
the resource.
Is this field compulsory? Yes
Can I include more than one item in this field? Yes, for example, if the resource is a report about
legal issues in a variety of different states or both
Commonwealth and NSW. Separate items with
a semicolon.
Is there a scheme for this field? Yes
Scheme: Juri
This scheme is available at
http://www.naa.gov.au/recordkeeping/online/agls/schemes/AglsJuri1.0.html
How do I complete this field? Select a single state or territory for content that
is legally relevant to that jurisdiction. For example,
a guide to drafting a will in Victoria should be
noted as ‘vic’ to allow users to limit search results
to jurisdictionally relevant material.
Use the identifier ‘au’ if the content is relevant in
all Australian jurisdictions or relates exclusively
to Commonwealth legal jurisdiction. This may include a report on National Competition Policy
implementation in Australian states or a guide to
making an application in the Family Court.
In some cases, content may be relevant to multiple
jurisdictions. For example, a collaborative law
reform report. In this case, all jurisdictions covered
by the report should be included.
Be careful to ensure a resource is legally accurate
for all states or territories selected. If the resource
has not been validated against all jurisdictions,
a single state or territory identifier should be
selected.
Use ‘au’ for resources of general interest e.g.
an article on discrimination.
Example
Name DC.Coverage.spatial
What do I put in this field? The application of the resource to a geographic
area within NSW.
Is this field compulsory? No, unless the resource describes a service. It is
also recommended if the resource is applicable to
a specific region.
Can I include more than one item in this field? Yes, for example, if the resource is a report about
legal issues in a variety of different regions.
Is there a scheme for this field? Yes
Scheme: ASGC (Australian Standard Geographical
Classification)
All regions
Central West
Far West
Hunter
Illawarra
Mid-North Coast
Murray
Murrumbidgee
If the resource is not specific to a region, but
relevant to all regions, ‘all regions’ should be
selected.
Example

DC.Date.created
What do I put in this field? The date the resource was made available in its
present form.
Is this field compulsory? Yes, unless the date is unknown.
Can I include more than one item in this field? No
Is there a scheme for this field? Yes
Scheme: ISO8601
How do I complete this field? ISO8601 defines the format for dates. This scheme
uses the format: YYYY or YYYY-MM or YYYY-MMDD) e.g. 1944-02-19.
Try to enter full dates, if known. If the full date is
not known enter the part of the date that is known
e.g. YYYY. Leave the field blank if the date is
unknown.
Date.created is important to indicate the currency
of the resource. It should be the date when the
content was created/published, not the date it was
put on the web.
Example

DC.Date.modified
What do I put in this field? The date the content of the resource was last
modified (not including modification of visual
presentation or structural organisation).
Is this field compulsory? Yes, unless the date is unknown.
Can I include more than one item in this field? No
Is there a scheme for this field? Yes
Scheme: ISO8601
How do I complete this field? ISO8601 defines the format for dates. This scheme
uses the format: YYYY or YYYY-MM or YYYY-MMDD) e.g. 1944-02-19.
Try to enter full dates, if known.
If the resource has not been modified Date.
modified = Date.created.
Date.modified should reflect the currency of the
content of the resource. If the content is updated
Date.modified must also be updated. It should not
be updated for minor changes to the presentation
of the resource.
Example
Name DC.Type.documentType
What do I put in this field? The nature of the resource.
Is this field compulsory? Yes
Can I include more than one item in this field? Yes, but most resources should be allocated
a single category.
Is there a scheme for this field? Yes
Scheme: JSMSdocument
See Appendix B for a detailed explanation of
the categories.
How do I complete this field? These headings should be used to define the
purpose of a document, and to reflect the type of audience and complexity implicit in particular
document types.
Select one of the options in Appendix B to define
the resource.
Example

DC.Type.category
What do I put in this field? Describes the category of the web resource e.g.
document, service or agency.
Is this field compulsory? No, unless you are describing a service.
Can I include more than one item in this field? No
Is there a scheme for this field? AGLS recommends that the resource should be
identified as one of the following:
document
service
agency
How do I complete this field? Include the DC.Type.category element when you
are describing a service.
JSMS has developed schemes to describe legal
services which are outlined in Appendix G.
You can contact LawAccess NSW for advice and
assistance using these schemes.
Example Describing the LawAccess NSW service:

DC.Identifier
What do I put in this field? A unique identifier for the resource (e.g. the web
address of the resource).
Is this field compulsory? Yes
Can I include more than one item in this field? No
Is there a scheme for this field? Yes
URI (Uniform Resource Identifier).
How do I complete this field? Generally, use the resourceÂ’s web address or
unique resource identifier (URL).
For a non-HTML resource with a cover page,
generally use the cover page URL. This is
recommended so that users can find out more
information about the resource before deciding
whether to open/download it.
If the resource is not a web resource, you can use
the ISBN or ISSN number separated by a
semicolon.
Example

Example: JSMS Metadata
This example shows metadata is for an HTML page published by the NSW Anti-Discrimination Board.
Race Discrimination: Your Rights

JSMSDocument Schema
Name Definition / Examples
Act Includes an act, regulation, ordinance, notice, order, commission or other
statutory instrument.
Bill Includes bills and explanatory memoranda.
Case Judicial or quasi-judicial decisions of courts, commissions, tribunals or boards
empowered to make findings of fact or law in the form of a formal determination.

Language Codes
A list of language codes is provided below. It is based on the Internet Engineering Task Force
RFC3066: ‘Tags for the Identification of Languages’ available at www.ietf.org/rfc/rfc3066.txt.
A full list of the two letter and three letter language codes is available at
http://lcweb.loc.gov/standards/iso639-2/englangn.html.

Country Codes
A list of country codes is provided below. It is based on the ISO 3166:
‘Tags for the Identification of Countries’. A full list of the country codes is available at
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html

Service
Service type Description
Advocacy Acting on behalf of a customer in a non-legal
environment
Community education Seminars explaining the law
Complaints Assistance to resolve complaints about a service,
organisation or business
Counselling or Crisis assistance Assistance to resolve personal issues and
crisis situations
Dispute resolution Face-to-face resolution of disputes in the presence
of a neutral third party
Legal advice Providing options or advice about a legal problem
Legal information Provision of information explaining the law
Legal procedure Explanation of legal processes or assistance with
documentation such as forms or letters
Legal representation Representation of the customer in court

Anyone who has used a library can use GILS. Based on the ISO 23950 search standard, GILS includes the most commonly understood concepts by which people worldwide find information sources in libraries–concepts like Title, Author, Publisher, Date, and Place.

Metadata

The idea of metadata has been compared to bibliographic citations. Metadata is like the cataloguing that libraries have traditionally used to describe their holdings and provide access such as consistent headings for names and subject headings. As the Internet is not so much a library as a publication medium, it is important that creators of the resources take responsibility for describing them before releasing them into the web.

Metadata is information that is added to a resource to:

enhance retrieval by providing structured elements, for example, to describe the subject
assist authentication by informing resource discoverers who, when etc. created the resource
assist the resource creator and/or owner in managing their information by providing elements such as the dates when the resource was modified or by which the information is no longer valid
express rights management, that is, specify the ownership of the resource and any conditions that apply to its use.
provide content rating, that is, specify the audience for whom the resource is intended
enhance collaboration by bringing together access to resources that are actually distributed through different areas or different organisations.

RDF Schema and OWL

In addition to the RDF data model, additional RDF Schema and Web Ontology Language (OWL) statements can be defined. Both RDF Schema and OWL include the RDF model, but pose restrictions to it which make it useful for defining and describing statements in terms of classes and restrictions on properties, and allow the use of reasoners (e.g. FACT++, Racer, Pellet, Â…) to perform standard inferencing on models. OWL is typically used to build ontologies (e.g. LRI-Core), which define the concepts of a certain domain.

So what does this have to do with Legal Texts?

By integrating MetaLex with the semantic web standards RDF, RDFS and OWL, we can transparently describe metadata both on the elements of legal texts themselves, and on the contents of those texts. For example, RDF structures can be used to integrate different manifestations of the same legal text, by using the standard Uniform Resource Identifier (URI) of MetaLex elements. Furthermore, RDF can be used to capture elaborate version management issues. OWL and RDFS can be used to describe the contents of legal texts: the concepts, but also their normative content. These semantic representations of legal texts can be used to performe elaborate legal reasoning, such as consistency checking, legal assessment etc. and for building knowledge-based applications which can be used by citizens to gain advice on complex legal issues.

The advantage of integrating the syntactic structure (i.e. plain MetaLex XML) with the semantic structure is that changes to a text can be immediately propagated to the depending (i.e. referring) texts and applications: an advanced legal content management system

Semantic Mapping

Once we have generalized metadata to encompass characteristics of all manner of information and then focused on those few characteristics commonly used for discovery, the global information discovery problem begins to appear tractable. Yet, we are still faced with daunting diversity in the ways that these few metadata elements appear across information types, across languages, and over time. To arrive at the commonality among metadata, we need to see past the form of the metadata into its meaning-an abstraction process known as “semantic mapping”.

Consider the case of searching across three different information collections: book citations, news articles, and electronic mail messages. If the searcher wants to search by “title,” only the book citations have exactly this form of metadata. However, the provider can decide that other metadata have similar meanings to the concept of “title.” In the news articles, the provider might decide that “headline” is almost the same as “title.” In the electronic mail collection, the closest metadata for “title” might be “subject line”.

Semantic mapping refers to the drawing of equivalence between related concepts. In the context of information discovery, the beauty of semantic mapping is that searchers do not need to know each of the names used for metadata in each of the different collections. Searchers only need to know the common concepts. Also, with the semantic mapping approach, providers avoid having to force metadata into any particular format. Content providers can actually assemble metadata as needed from various sources and offer searchers a choice of formats. Providers may also choose to map search concepts in different ways for different audiences, e.g., search specialists may see a complex tool while children get a simple one.