Introduction

Contents of Lawi Data

 

1. Introduction

An Application Profile is a document (or set of documents) that specifies and describes the metadata used in a particular application. To accomplish this, a profile:

describes what a community wants to accomplish with its application (Functional Requirements);
characterizes the types of things described by the metadata and their relationships (Domain Model); enumerates the metadata terms to be used and the rules for their use (Description Set Profile and Usage Guidelines); and defines the machine syntax that will be used to encode the data (Syntax Guidelines and Data Formats).

An application profile is a declaration of the metadata terms an organization, information resource, application, or user community uses in its metadata. In a broader sense, it includes the set of metadata elements, policies, and guidelines defined for a particular application or implementation. The elements may be from one or more element sets, thus allowing a given application to meet its functional requirements by using metadata elements from several element sets including locally defined sets. For example, a given application might choose a specific subset of the Dublin Core elements that meets its needs, or may include elements from the Dublin Core, another element set, and several locally defined elements, all combined in a single schema. An application profile is not considered complete without documentation that defines the policies and best practices appropriate to the application.

It defines a set of high quality metadata on (legal) entries in the Encyclopedia of Law, and is directed at improving accessibility of materials on the Web.

The LAWI DATA Application Profile (LAWI DATA AP) is a metadata standard created specifically to enhance the description, exchange and subsequent retrieval of agricultural Document-Like Information Objects (DLIOs). It is a metadata schema which draws elements from well known Metadata standards such as Dublin Core (DC), Australian Government Locator Service Metadata (AGLS) and others Metadata Element Set namespaces. It allows sharing of information across dispersed bibliographic systems and provides guidelines on recommended best practices for cataloguing and subject indexing. The LAWI DATA AP is a major step towards exchanging high-quality and medium-complex metadata in an application independent format.

The LAWI DATA AP is based on the Dublin Core Elements and Qualifiers [2], tother Metadata Element Set [3], and the Australian Government Locator Service Metadata Set [4].

This document provides the best practices on the description of the LAWI DATA AP elements.

1.1 Goals and Objectives

The goal of the LAWI DATA Application Profile (LAWI DATA AP) is to facilitate interoperability of metadata formats currently in use to enable linking of various types of agricultural information, therefore allowing users to perform cross-searches and other value added services. This approach would also facilitate the harvesting of data; with the application of the LAWI DATA AP model, this harvesting process could be automated.

The expected benefits of LAWI DATA AP are:

  • a common format for exchange and description of information resources within the current LAWI DATA network;
  • a standard data model for bibliographic description of resources in the domain of law, covering publications in different areas of the domain such as Administrative Law, Family Law, Intellectual Property, etc.;
  • different communities being able to access and re-use existing application profile schema and to establish a common format for homogenizing results on a search interface derived from parallel searching of heterogeneous archives;
  • harvesting of metadata from data sources within and beyond the domain of law; and
  • a common approach to sharing information between applications and standards makers, while promoting interoperability between systems.

Introductory remarks

Scope

These guidelines are written primarily to facilitate the exchange of metadata, in compliance with the OAI-PMH definitions as distributed by DCMI. Basically these guidelines describe the mapping, and are not to be used as cataloguing instructions.
Language of the metadata is at the discretion of each encyclopedia.
The use of Unicode is mandatory.
Only one metadata record should be used for different versions of a digital object (e.g. a postscript and a pdf version), unless the intellectual content of the versions is different. The rule of thumb is to create a new metadata record when the metadata of a version is different. This happens for instance when a new version of the resource with modifications is created and in that case recommended best practice is to use the relation element to link the newer version to the older.

In some cases (DC element ‘subject’ and ‘type’) additional information may be useful for the harvesting party and service provider.
See for instance:3. Guidelines for Opitonal Containers at:
http://www.openarchives.org/OAI/2.0/guidelines.htm and: http://arXiv.org/oai2?verb=Identify as well as: http://doc.utwente.nl/oai/ir?verb=Identify for best practices. Additional information can also be given in the form of textual documentation about the use metadata elements subject and type, e.g. to give information on the local classification or keywords, or information on local review policies.

Namespace

The namespace Lawi Data is registered at http://data.lawin.org.
This name space is an authoritive placeholder for semantic terms, controlled vocabularies and identifiers.

The Lawi Data URIs are persistent identifiers for non-informational resources. Such non-informational resources include classifications and “real world objects”. One important category is concepts; concepts are classes or properties. For these a subclass of the info:eu-repo URIs is introduced: the info:eu-repo/semantics URIs. The info URIs are not resolvable which makes them ideal as persistent identifiers of abstract things like concepts. On the other hand there is a need to link the URIs to their semantics. In the Semantic Web this is done by a redirection to a RDF document in which the semantic relations of the object for which the URI stands are described. We propose a service that supports URIs of the following form: http://purl.org/info:eu-repo/… (which is the same as http://www.purl.org/info:eu-repo/… – default hostname is “www”). The URI http://purl.org/info:eu-repo/semantics URIs results in a 302 redirection to a RDF document in which the concepts for which the URIs stand are described.The namespace is an authoritive placeholder for semantic terms, controlled vocabularies and identifiers. By using this namespace all the terms used have a “web presence”. Therefore it is no longer an arbitrary string, but contains meaning. This utilisation makes it future-proof.The purpose of the info:eu-repo registry is not to create a comprehensive, complete ontology. Instead its purpose is to fill holes. The registry introduces terms with which existing ontologies can be complemented and connected with each other.

The following types have been identified for controlled vocabularies and identifiers.

……………………….

We define application profiles as schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application.The experience of implementors is critical to effective metadata management.

DC Education Schema

The DC Education Working Group has proposed a schema (3) for describing educational resources. Jon Mason of Education Network Australia (EdNA) and Stuart Sutton of the Gateway to Educational Materials (GEM) have led this activity, with a particular focus on five areas of interest to educational metadata projects:

users
duration
learning processes
standards
quality

Subsequent discussions at meetings and on mailing lists considered whether elements could be identified and evaluated within these areas. The recommendation of the DC Education Working Group suggests a schema incorporating

Various standard DC elements and recommended qualifiers
DC Education ‘namespace’ (domain specific) extensions such as

DCEducation Element: audience
DCEducation Audience qualifier: mediator
DCEducation Element: standard
DCEducation Standard qualifier: identifier
DCEducation Standard qualifier: version
DCEducation Relation qualifier: conforms to

Various IEEE Learning Object Metadata (LOM) (4) elements such as

InteractivityType
InteractivityLevel
TypicalLearningTime

We can see from this schema extract that it consists of DC ‘standard’ elements, domain specific additions to recommended standard DC elements, and particular elements from other distinct element sets.

Encyclopedia Schema

An extract of this schema includes
dc:title The name of the collection
dc: identifier A formal identifier for the collection
dc:description A description of the collection

Namespaces and application profiles

This paper suggests that we can distinguish ‘namespace schema’ from ‘application profile schema’. Namespace schema contain all those elements defined by the managing body or registration authority (whatever that might be) for a particular namespace. Application profiles are tailored for particular implementations and will typically contain combinations of sub-sets of one or more namespace schemas.

‘Namespace’ is defined within the W3C XML schema activity (6) and allows for unique identification of elements. Within the W3C XML and RDF schema specifications, namespaces are the domain names associated with elements which, along with the individual element name, produce a URL that uniquely identifies the element. In W3C terms the namespace does not have to be a ‘realÂ’ registration authority, nor does the element identifying URL need to point to a ‘realÂ’ web address. However in order to ensure a well managed metadata environment we would argue that the namespace should refer to a real registration authority that takes responsibility for the declaration and maintenance of their schema.

There is a continuum of formality in such registration authorities from those where the authority is an internationally recognised standards body through to those where the authority derives from national or sectoral de facto standards, and at the other end of the continuum, to self-contained schemas defined within a local project or service.

By means of ‘namespace’ we can

Identify the management authority for an element set
Support definition of unique identifiers for elements
Uniquely define particular data element sets or vocabularies

The DESIRE project constructed a prototype metadata registry schema with a data model within which ‘namespace’ consisted of three parts:

Registration authority
Namespace concept
Namespace

It may be useful to consider how, in combination, these entities might help us to identify well managed metadata element sets. By use of these entities, a distinctive element set can be identified by a ‘namespace’, that namespace may have different instantiations over time (versioning) each of which require a separate namespace but all are associated with a namespace concept. A namespaceconcept, is therefore a grouping mechanism for successive versions of anamespace. Each namespace and namespace concept is associated with a registration authority. Within the DESIRE registry this enabled us to consider that one registration authority might have several different element sets associated with it.
What is an application profile?

Application profiles consist of data elements drawn from one or more namespace schemas combined together by implementors and optimised for a particular local application. Application profiles are useful as they allow the implementor to declare how they are using standard schemas. In the context of working applications where there is often a difference between the schema in use and the ‘standard’ namespace schema.

Schema application profiles are distinguished by a number of characteristics. They

May draw on one or more existing namespaces

The application profile may use elements from one or more different element sets, but the application profile cannot create new elements not defined in existing namespaces.

Introduce no new data elements

All elements in an application profile are drawn from elsewhere, from distinct namespace schemas. If an implementor wishes to create ‘new’ elements that do not exist elsewhere then (under this model) they must create their own namespace schema, and take responsibility for ‘declaring’ and maintaining that schema.

May specify permitted schemes and values

Often individual implementations wish to specify which range of values are permitted for a particular element, in other words they want to specify a particular controlled vocabulary for use in metadata created in accordance with that schema. The implementor may also want to specify mandatory schemes to be used for particular elements, for example particular date formats, particular formats for personal names.

Can refine standard definitions

The application profile can refine the definitions within the namespace schema, but it may only make the definition semantically narrower or more specific. This is to take account of situations where particular implementations use domain specific, or resource specific language.

By defining application profiles and, most importantly by declaring them, implementors can start to share information about their schemas in order to inter-work with wider groupings. Typically implementors are part of larger communities, they form part of a sector (education, cultural heritage, industry, government), possibly a subject grouping, they are part of programmes with common funding, they work with others serving the same target audiences. In order to work effectively these communities need to share information about the way they are implementing standards. Communities can start to align practice and develop common approaches by sharing their application profiles.

Declaring profiles for application areas is a mechanism used elsewhere in computing. In other contexts, agreement on usage by means of a profile will be familiar to readers. For example within the area of resource discovery, Z39.50 application profiles have been used for some years, where implementors reach consensus on compliance with a sub-set of the Z39.50 standard. The Z39.50 Maintenance Agency (**ref http://lcweb.loc.gov/z3950/agency/profiles/profiles.html. see last reference) defines a Z39.50 Profile as follows

A profile specifies the use of a particular standard, or group of standards, to support a particular:

application, for example GILS or WAIS;
function, for example author/title/subject searching;
community, examples: the museum community, chemists, musicians, etc.; or
environment, examples: the Internet, North America, Europe, etc.
By “specifying the use” we mean to select options, subsets, and values of parameters, where these choices are left open in the standard.

A number of such profiles are maintained by the Z39.50 maintenance agency and are referenced from its web site, such as the CIMI profile for cultural heritage information , the Bath profile for library applications and resource discovery.
Examples

In order to illustrate the difference between namespace schemas and application profiles it may be helpful to refer to the DESIRE metadata registry where a few element sets have been treated in this way:

Examples of Namespace schemas

Examples of Namespace schemas

Examples of Application Profiles

References

  1. DESIRE metadata registry: a prototype registry developed as part of the EC funded DESIRE project http://desire.ukoln.ac.uk/registry/
  2. Carl Lagoze. The Warwick Framework A Container Architecture for Diverse Sets of Metadata Digital Library Research Group. D-Lib Magazine, July/August 1996 http://mirrored.ukoln.ac.uk/lis-journals/dlib/dlib/dlib/july96/lagoze/07lagoze.html
  3. The DC-Education Working Group proposal to the DCAdvisory Committee http://www.ischool.washington.edu/sasutton/dc-ed/Dc-ac/DC-Education.html
  4. IEEE Learning Technology Standards Committee’s Learning Object Meta-data Working Group. Version 3.5 Learning Object Meta-data Scheme.
  5. http://ltsc.ieee.org/doc/wg12/scheme.html The RSLP collection description home page is at http://www.ukoln.ac.uk/metadata/rslp/
  6. Tim Bray, Dave Hollander, and Andrew Layman. Namespaces in XML. World Wide Web Consortium.14-January-1999 http://www.w3.org/TR/REC-xml-names
  7. The SCHEMAS project home page is at http://www.schemas-forum.org/
  8. Dublin Core Registry discussion list http://www.mailbase.ac.uk/lists/dc-registry/
  9. The RDF Schema Specification is at http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
  10. The BIBLINK Core Application Profile used is at http://www.schemas-forum.org/registry/schemas/biblink/BC-schema.html
  11. The BIBLINK namespace in RDF schemas is at http://www.schemas-forum.org/registry/schemas/biblink/1.0/bc-rdfs
  12. The BIBLINK Core Application Profile expressed in RDF schemas is at http://www.schemas-forum.org/registry/schemas/biblink/1.0/bc-ap-rdfs
  13. A record conforming to the BIBLINK Core Application Profile is at http://www.schemas-forum.org/registry/schemas/biblink/bc-ap-eg1-rdf
  14. A record conforming to the BIBLINK Core Application Profile is at http://www.schemas-forum.org/registry/schemas/biblink/bc-ap-eg2-rdf
  15. A record conforming to the BIBLINK Core Application Profile is at http://www.schemas-forum.org/registry/schemas/biblink/bc-ap-eg3-rdf
  16. Z39.50 International Standard Maintenance Agency. Z39.50 profiles. http://lcweb.loc.gov/z3950/agency/profiles/profiles.html
  17. Examples of such conventions are given by Priscilla Caplan in a mail to the dc-general mailing list, see http://www.mailbase.ac.uk/lists/dc-general/2000-08/0043.html. Proposals for expressing these in XML Schema are suggested by Jane Hunter see http://www.mailbase.ac.uk/lists/dc-general/2000-08/0050.html
Rachel Heery and Manjula Patel
UK Office for Library and Information networking (UKOLN), University of Bath

Article Title: “Application profiles: mixing and matching metadata schemas”
Author: Rachel Heery; Manjula Patel
Publication Date: 24-Sep-2000

Publication: Ariadne Issue 25
Originating URL: http://www.ariadne.ac.uk/issue25/app-profiles/

Acknowledgements This document is based on several recommendations, include the use of simple Dublin Core metadata as described in: USING SIMPLE DUBLIN CORE TO DESCRIBE EPRINTS, by Andy Powell, Michael Day and Peter Cliff, UKOLN, University of Bath, Version 1.2
[see also: http://www.intute.ac.uk/publications/eprints-uk/simpledc-guidelines.html ]

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *