|
Introduction:
Establishing
a common approach for the exchange and re-use of data across the Web would
be a major step towards achieving the vision of the Semantic Web. The
Semantic Web Activity statement articulates this vision as
'…having
data on the Web defined and linked in a way that it can be used for more
effective discovery, automation, integration, and reuse across various
applications. The Web can reach its full potential if it becomes a place
where data can be shared and processed by automated tools as well as by
people.' [i]
In order
to move towards this vision, we need to consider the tools on which such
'data sharing' will be based. In parallel with the growth of content on
the Web, there have been increases in the amount and variety of metadata to
manipulate this content. An inordinate amount of standards-making
activity focuses on metadata schemas (also referred to as vocabularies or
data element sets), and yet significant differences in schemas remain.
Different domains typically require differentiation in the complexity and
semantics of the schemas they use. Indeed, individual implementations
often specify local usage, thereby introducing local terms to metadata
schemas specified by standards-making bodies. Such differentiation
undermines interoperability between systems. Certainly unnecessary
variations in schemas should be avoided wherever possible, but it is
impossible, and undesirable, to try to impose complete uniformity.
Innovation emerges from such differentiation.
This
situation highlights a growing need for access by users to in-depth
information about metadata schemas and particular extensions or
variations to schemas. Currently, these 'users' are human — people
requesting information. Increasingly, such 'users' will be automated
— 'agents' as part of applications that need to navigate or query
schemas. It would be helpful to make available easy access to schemas
already in use to provide both humans and software with comprehensive,
accurate and authoritative information.
The W3C
Resource Description Framework (RDF) [ii] has provided the basis for a
common approach to declaring schemas in use. At present the RDF Schema
(RDFS) specification [iii] offers the basis for a simple declaration of
schema. It provides a common data model and simple declarative language.
Additional work is underway in the context of the W3C's RDFCore Working Group [iv] and the Web Ontology Group
[v] to add 'richness' and flexibility to the RDF schema language, to
incorporate the features of the DARPA Agent Markup Language (DAML) [1]
and the Ontology Interface Layer (OIL) [2] ontology language [vi], and to
bring this work to recommendation status. Even as it stands, an
increasing number of initiatives are using RDFS to 'publish' their
schemas.
Metadata
schema registries are, in effect, databases of schemas that can trace an
historical line back to shared data dictionaries and the registration
process encouraged by the ISO/IEC 11179 [vii] community. New impetus for
the development of registries has come with the development activities
surrounding creation of the Semantic Web. The motivation for establishing
registries arises from domain and standardization communities, and from
the knowledge management community. Examples of current registry activity
include:
- Agencies maintaining directories of data
elements in a domain area in accordance with ISO/IEC 11179 (This
standard specifies good practice for data element definition as well
as the registration process. Example implementations are the
National Health Information Knowledgebase hosted by the Australian
Institute of Health and Welfare [viii] and the Environmental Data
Registry hosted by the US Environmental Protection Agency [ix].);
- The xml.org directory of the Extended
Markup Language (XML) document specifications facilitating re-use of
Document Type Definition (DTD), hosted by the Organization for the
Advancement of Structured Information Standards (OASIS) [x];
- The MetaForm
database of Dublin Core usage and mappings maintained at the State
and University Library in Goettingen [xi];
- The Semantic Web Agreement Group
Dictionary, a database of terms for the Semantic Web that can be
referred to by humans and software agents [xii];
- LEXML, a multi-lingual and
multi-jurisdictional RDF Dictionary for the legal world [xiii];
- The SCHEMAS registry maintained by the
European Commission funded SCHEMAS project, which indexes several
metadata element sets as well as a large number of activity reports
describing metadata related activities and initiatives [xiv].
Metadata registries
essentially provide an index of terms. Given the distributed nature of
the Web, there are a number of ways this can be accomplished. For
example, the registry could link to terms and definitions in schemas
published by implementers and stored locally by the schema maintainer.
Alternatively, the registry might harvest various metadata schemas from
their maintainers. Registries provide 'added value' to users by indexing
schemas relevant to a particular 'domain' or 'community of use' and by
simplifying the navigation of terms by enabling multiple schemas to be
accessed from one view. An important benefit of this approach is an
increase in the reuse of existing terms, rather than users having to
reinvent them. Merging schemas to one view leads to harmonization between
applications and helps avoid duplication of effort. Additionally, the
establishment of registries to index terms actively being used in local
implementations facilitates the metadata standards activity by providing
implementation experience transferable to the standards-making process.
Scope And Functionality
The Dublin
Core Metadata Initiative (DCMI) has defined a relatively small set of
data elements (referred to within the DCMI as the DCMI vocabulary or DCMI
terms) for use in describing Internet resources as well as to provide a
base-line element set for interoperability between richer vocabularies.
The DCMI has long recognized the need to provide users with enhanced
access to information about these terms in the form of an added-value 'information
service'. This service should include information about the DCMI
vocabulary over and above that provided by the RDF schema, or any
explication of the vocabulary on the DCMI Web site. This service is
intended to assist humans and applications to obtain reliable and trusted
information about the DCMI. The interests of a variety of DCMI members
have converged around this idea, including: those interested in building
a generic schema registry, those interested in expressing the rich
structure of ontologies in a schema language,
those interested in providing a user friendly search interface to the
DCMI vocabulary, and those interested in effectively managing the
evolution of the DCMI vocabulary. It was with these goals, and this level
of interest, that the DCMI Registry Working Group [xv] was chartered.
The
original charter for the DCMI Registry Working Group was to establish a
metadata registry to support the activity of the DCMI. The aim was to
enable the registration, discovery, and navigation of semantics defined
by the DCMI, in order to provide an authoritative source of information
regarding the DCMI vocabulary. Emphasis was placed on promoting the use
of the Dublin Core and supporting the management of change and evolution
of the DCMI vocabulary.
The
overriding goal has been the development of a generic registry tool
useful for registry applications in general, not just useful for the
DCMI. The design objectives have been to provide a tool suitable for use
for the DCMI registry while also ensuring the registry was sufficiently
extensible to include other, non-DCMI schemas. In addition, the DCMI
Registry Working Group has been committed to using open standards and
developing the software from open-source distributions [3].
Discussions
within the DCMI Registry Working Group (held primarily on the group's
mailing list [4]) have produced draft documents regarding application
scope and functionality. These discussions and draft documents have been
the basis for the development of registry prototypes and continue to play
a central role in the iterative process of prototyping and feedback.
Application
scope and functional requirements have evolved through an iterative
process of prototyping, discussion and evaluation. Many aspects of
functionality have been identified using this process, including:
- Selecting a user interface that is both
meaningful and user-friendly to the largest possible set of users
(for example, metadata specialists, RDF experts, and automated
agents each require different interfaces [xvi]);
- Automating the identification of
relationships between terms in vocabularies, and linking those terms
in a way that facilitates their discovery and navigation;
- Implementing a metadata registry that is
multilingual, both from a user interface and a data perspective;
- Identifying appropriate administrative
metadata to describe the registered schemas themselves (i.e., title,
publisher, description, etc.);
- Associating encoding schemes (such as
date formats and identifier schemes) with data elements, to enable
the identification and navigation of encoding schemes belonging to
different resource communities in a way that is both flexible and
scalable;
- Evaluating various methods of persistent
storage of metadata terms for a solution that is both practical and
scalable.
An
important focus of the prototyping effort has been to provide a DCMI
oriented view of the data model that exists in the underlying RDF schema.
This enables users to easily visualize the 'grammar' that structures the DCMI
semantics (elements, element qualifiers and encoding schemes). In this
article, the 'classification' of DCMI terms is referred to as a taxonomy. A user interface based around
this taxonomy is felt to be particularly important for the novice user.
Another
significant issue, and one not easily solved, has been the requirement to
manage the evolution of the DCMI vocabulary. This has involved balancing
our internal vocabulary management requirements (audit trail, versioning,
status of proposed terms) with the provision of
a clear and authoritative view of the current vocabulary.
Developing With
Prototypes
Many of
the issues regarding metadata registries are unclear and ideas regarding
their scope and purpose vary. Additionally, registry issues are often difficult
to describe and comprehend without a working example. The DCMI makes use
of rapid prototyping to help solve these problems. Prototyping is a
process of quickly developing sample applications that can then be used
to demonstrate and evaluate functionality and technology.
The
following sections describe three metadata registry prototypes that were
written by the DCMI [5]. They serve two purposes: to facilitate the
generation of scope and functional requirements, and to assist in the
identification of practical technology solutions for registry
applications. While each of the prototypes provides a different solution,
they have several features in common. For example, the prototypes are all
open-source solutions, built entirely from open-source distributions [6].
All three prototypes rely on RDF schemas for their input data format, and
all three are multilingual [7] Java servlet
applications. From there the prototypes diverge, each providing a
different solution and each building on experience gained from the
previous prototype(s).
Prototype 1
Prototype
1 is a database solution, based on the Extensible Open RDF Toolkit (EOR)
[xvii]. EOR is an open-source RDF toolkit providing a collection of Java
classes and services designed to facilitate the rapid development of RDF
applications. EOR is based on the Stanford RDF API [8], which provides
classes and methods necessary for processing RDF data (i.e., parsing,
serializing, etc.).
Prototype
1 is essentially a search and navigation service for RDF schemas. It extends
the EOR search service by providing a compound search function, which is
required for several of the search types, such as "find x in
relation to y" and "find classes containing the following
term".
The user
interface (UI) for Prototype 1 is forms-based (see Figure 1) and is a
combination of Java Server Pages (JSP) and Extensible Stylesheet
Language Transformation (XSLT). The UI provides both standard and RDF
interfaces, intended to serve two different types of users: metadata
specialists and RDF experts. The differences between the two interfaces
are the types of searches supported and the labels used for the search
result set. For example, the standard interface provides queries for
"find refinements for term x". The corresponding RDF interface
query is "find terms that are a subProperty
(or subClass) of x". Additionally, the
standard interface supports the query "find registered encoding
schemes for term x".
This is a
good example of functionality that supports local terminology relevant to
its target audience (in this case, those interested in the DCMI). One can
envisage other 'community specific' registries orientating their UI to
specialized audiences (e.g., the IMS community [9]).
The
registry also provides an 'RDF interface' that takes account of the
underlying DCMI taxonomy of terms, but uses RDF terminology for the user
interface, rather than the more familiar DCMI terminology.
Figure 1. Standard user interface
An
additional difference between the standard and RDF interface is in the
labels generated for query results. Standard interface labels are
natural-language oriented and translated into each of the supported languages.
The RDF interface uses the fully qualified predicate (namespace-URI and
local-name) for its labels.
One
feature the standard and RDF interfaces have in common is that every
resolvable resource in the result-set is an HTML link either to that resource
or to a symbol used to link and navigate terms.
Query results often include both. For example, clicking on any of the
labels or resources generated by the query in Figure 2 would resolve to
that resource. Clicking on the "show refinements" symbol (
 ) would generate a new
search for all refinements (subClassOf or subPropertyOf) of that term. The "new
search" symbol (
 ) generates a new query for
that particular item. This provides a simple means to navigate terms and
illustrates the relationship between terms.
Prototype
1 uses a PostgreSQL relational database [10] as
a persistent data store. PostgreSQL was chosen
because it is one of the few open-source database management systems
(DBMS) that support Unicode. Separate databases are maintained for each language.
This is due to the limited support within EOR and the Stanford RDF API
for the xml:lang
attribute. This distribution of translations works fine for displaying
results in a particular language, but it limits the application's ability
to simultaneously display all the translations for a particular term
(i.e., display all translations for the term "title").
Omitted
Figure 2. Hyperlinked query
results
Multilingual
support for the user interface is provided using Java resource bundles
[11]. Resource bundles are Java classes that are essentially tables of
locale-specific translations. A separate bundle was created for each
supported language. These bundles are loaded into the client session
whenever a language selection is made. The registry uses the resource
bundles to display the user interface in the selected language.
Ontology
relationships (i.e., complementOf, equivalentTo, inverseOf,
etc.), as are provided with DAML+OIL, are supported by the Stanford RDF
API via the DAML_O class. However, this layer of support is not currently
part of the EOR toolkit and is not supported by this prototype.
Solutions
built on RDF toolkits such as EOR can be implemented quickly due to the
extensive classes and services provided by the toolkit (only a small
number of changes to EOR were required to produce Prototype 1). However,
this is a complex and resource-intensive approach, which did not perform
as well as other solutions.
Prototype 2
Prototype
2 is an extremely lightweight, in-memory solution. It is a small Java servlet application and differs significantly from
the other prototypes in that it does not use an RDF API. Data is parsed
using an XML parser, and queries are resolved on the client-side using
XSLT stylesheets.
All input
data is in the form of RDF schemas, which are stored locally as
sequential ASCII files [12]. The schemas are loaded by the XSLT stylesheets and rely on the search servlet to identify which schemas to load. This
information is passed from the servlet to the stylesheets as parameters. All non-ASCII characters
in the schemas are required to be escape-sequenced.
The
server-side processing for this prototype is very simple and is the key
to its flexibility. The search servlet is the
primary component and consists of less than 200 lines of code. This servlet evaluates the input data that was posted and
sets parameters identifying the specific request and the current language
selection. These are then passed to the appropriate stylesheet
for processing.
Figure 3. Point-and-click style
user interface
The user
interface has an intuitive point-and-click style, designed to facilitate navigation
rather than searching [13] (see Figure 3). The UI of the search service
is composed entirely of XSLT stylesheets. The stylesheets are segregated by function (banner,
navigation bar, footer, etc.) and language. The multilingual aspects of
the UI are managed by isolating all language-dependent text to individual
stylesheets, and including those stylesheets as needed. In Prototype 2, the
translations were isolated to the intro, navbar
and labels stylesheets. Non-ASCII characters in
these stylesheets are encoded as
escape-sequenced strings.
Prototype
2 provides one interface style. This UI is designed to provide
native-language labels for terms. However, due to the modular approach of
the XSLT stylesheets, additional interfaces
(i.e., the RDF interface provided in Prototype 1) could be added.
All
resources in the result-set are displayed as HTML links that resolve
either to the listed resource, or that initiate a new query for the
listed resource. This includes both labels (predicates) and property values
(objects) and allows users to easily navigate the metadata terms and
explore the relationship between terms.
Due to the
simplified data model of Prototype 2, refinements for terms (subClassOf or subPropertyOf)
are much easier to discover and navigate, and can be displayed in a more
intuitive manner. All refinements for each selected term are
automatically included in query results (see Figure 4).
Support
for ontologies is limited. Complex
relationships (such as those provided with DAML+OIL) between terms cannot
be easily automated without an RDF parser, and would be difficult to
implement with this type of lightweight solution.
The
modular approach of the stylesheets does offer,
to a greater degree, more flexibility regarding local DCMI vocabulary
taxonomy (i.e., elements, qualifiers, encoding schemes, controlled
vocabulary terms). However, a method to automate the discovery and
navigation of this taxonomy has not yet been discovered.
Figure 4. Discovery and
navigation of refinements
Lightweight,
in-memory solutions, such as Prototype 2, can be implemented quickly, and
are flexible and fairly simple to maintain. However, they are not
expected to scale well due to the limitations of in-memory processing.
This may be perfectly acceptable for applications that are able to limit
the number of schemas they plan to register.
Prototype 3
The third
prototype, like Prototype 1, is a database solution. It is based on the
Jena Semantic Web Toolkit [14], the ARP RDF Parser [15] and the BerkeleyDB [16] database management system.
Jena is a functionally rich Java API for
processing RDF data. It supports both in-memory and persistent storage RDF
models, RDF Data Query Language (RDQL), integrated RDF parsers (i.e., ARP
and SirPac) and a rich set of resource-centric
and model-centric methods for manipulating RDF data. Jena
and the ARP parser are open-source and were developed by the HP Labs
Semantic Web Activity.
Prototype
3 uses BerkeleyDB for persistent data storage. BerkeleyDB is an open-source database management
system that provides a comprehensive set of features, including data
concurrency, recovery and transaction support. It differs from most
database management systems in that it is neither relational nor
object-oriented. Databases are composed of simple key-value pair records.
BerkeleyDB performs better than relational
database systems for a couple of reasons. First, it uses simple function
calls to access data, thus eliminating the overhead of a query language,
such as SQL. Second, it is an "embedded" database, running in
the same address space as the application that uses it. This eliminates
the need for inter-process communication. BerkeleyDB
appears to be a perfect solution for a persistent RDF data store, but the
interface between Jena
and the database is not completely stable and can result in unexpected
system failures.
Prototype
3 is also a Java servlet application. It builds
on the previous prototypes and is composed of a number of services,
including search/navigate, registration, login, and import.
The user
interface is written entirely in XSLT. Each of the services produces an
XML document that is then parsed using XSLT. The XSLT stylesheets
produce HTML, which is delivered to the client. One UI style is currently
provided, which produces native-language style labels (i.e., DCMI data
element identifiers such as title, description, publisher, etc.).
The
search/navigate service includes features from both of the previous
prototypes. The user interface has a more advanced search engine than
Prototype 1 (see Figure 5) and incorporates the point and click
navigation style of Prototype 2. The search form enables case-sensitive
searching and supports specific types of searches (i.e., match all terms,
match any term, etc.). This function can be easily expanded to further
refine searches to a specific schema or taxonomy.
Figure 5. Search Service
Like
Prototype 2, this application uses an intuitive point-and-click style of
navigation. As with the previous prototypes, all resources are displayed as
HTML links that resolve to the listed resource or initiate a new query
for that resource. Additionally, "canned" queries are provided
for displaying registered schemas, properties, classes, namespaces, or a
summary of all registered items.
The
register, login, and import services provide a means for authorizing
users and for allowing those users to register schemas. Additionally, the
import service provides two very important functions: an alternative
means for users to specify the schema language, and two methods for
specifying the administrative metadata associated with a schema.
Metadata
describing the schema itself is required for each registered schema. This
includes title, description, publisher, URL of related documents, and
date. This information can be included as part of the schema, as is the
case with the DCMI schemas, or can be provided when the schema is
imported using the fields provided on the import screen (see Figure 6).
Figure 6. Import service
The schema
language must also be specified when the schema is registered. This can
be accomplished in two ways: by coding the xml:lang attribute on all literals within the
schema [xviii] (see Figure 7) or by specifying the language at
registration time using the field provided on the import screen.
Identifying the schema language during registration enables the discovery
and navigation of terms and schemas in multiple languages. Users can
specify their language preference, using the preferences service, by
selecting from a list of supported UI languages and result-set languages.
The search service selects the appropriate query results based on the
language preferences selected and the language encoding used by the
schemas.
Figure 7. Language
identification using xml:lang
The
multilingual user interface is accomplished via an XSLT
"translate" stylesheet. This stylesheet is passed the term requiring translation
and the requested language. It uses language-specific XML documents,
similar to Java resource bundles, to perform the translations. Translations
are done both for the user interface and the result-set labels.
Prototype
3 appears the most promising of the three solutions. The extensive amount
of functionality for manipulating RDF data provided with the Jena API
offers a big advantage over the other prototypes. This is especially
significant regarding support for DAML ontologies.
Conclusions
Software and performance issues
Java
proved an ideal solution for multilingual registry applications because of
its use of UTF-8 encoding for internal string representation and because
of the rich application-programming interface provided for
internationalization [xix]. One significant difference between the
multilingual solutions we tried is the xml:lang support offered by the Jena API. This
attribute simplifies language processing and enables flexibility not
easily offered by other solutions.
Relational
database solutions, such as was tried with Prototype 1, do not appear to
be an ideal fit for RDF, at least not from a performance standpoint. The
overhead of using a high-level data access (such as SQL) with a data
model as minimalist as RDF is noticeable, and performance suffers. BerkeleyDB, in conjunction with the Jena API, offers
significantly better performance, but is not 100% stable. This problem is
expected to be resolved in the near future. In the interim, the best
choice for a persistent data store for RDF metadata registries appears to
be the slower-performing, but more reliable, relational model.
Prototype
3 demonstrates a solution for automating the identification and
management of administrative metadata that describes the registered
schemas (i.e., title, publisher, description, etc.). A standard method
for describing administrative metadata for schemas does not currently
exist. Prototype 3 resolves this issue by providing two alternative
methods for capturing this information.
The
modular use of XSLT stylesheets has proven to
be a good solution for providing user interfaces that can be customized
to suit multiple user types. This level of functionality is demonstrated
with Prototype 1, and could be easily adopted by the other prototypes due
to their common use of XSLT.
Functionality and data model issues
There has
been an ongoing tension between the requirements for managing the
evolution of the DCMI vocabulary and the requirement to provide user
friendly navigation of the DCMI vocabulary. The internal vocabulary
management requirements of the DCMI (i.e., audit trail, versioning,
tracking status of proposed terms, etc.) could not easily be resolved
with the requirements for an "open" metadata registry and were
not addressed by the three prototypes described in this article. The
principal obstacle to satisfying vocabulary management requirements has
been a lack of data. The DCMI RDF schemas do not include this level of
information. Although several solutions were proposed-- including
overloading the schemas to include this data and maintaining multiple
data sources-- none were considered acceptable. While this may be
considered a complication particular to metadata 'standards-making
bodies', such as the DCMI, it is also, to a lesser extent, an issue faced
by all schema maintainers. The DCMI has chosen to split their vocabulary
management requirements into a separate application. It will be
interesting to see if such a system has more widespread use amongst
schema maintainers.
The
formulation of a 'definitive' set of RDF schemas within the DCMI that can
serve as the recommended, comprehensive and accurate expression of the
DCMI vocabulary has hindered the development of the DCMI registry. To
some extent, this has been due to the changing nature of the RDF Schema
specification and its W3C candidate recommendation status. However, it
should be recognized that the lack of consensus within the DCMI community
regarding the RDF schemas has proven to be equally as impeding.
The
identification and navigation of the 'taxonomy' (the 'grammar' of a
vocabulary arising from the data model) belonging to different resource
communities is still an open issue. Each of the prototypes demonstrate a limited degree of functionality in this
area, but do not provide a method for automating it. Until an automated
method can be found, "canned queries" and other navigational
aids to these structures will be limited to widely accepted taxonomies
(i.e., properties, classes, etc.) and locally defined taxonomies (such as
DCMI elements, qualifiers, etc.) that are manually maintained.
The
automated sharing of metadata across applications is an important part of
realizing the goal of the Semantic Web. Users and applications need
practical solutions for discovering and sharing semantics. Schema
registries provide a viable means of achieving this. Much has been
learned from the prototyping efforts to date, and the DCMI has renewed
its commitment to developing an operational registry that facilitates the
discovery, exchange and reuse of semantics.
Acknowledgements
The authors would like to acknowledge
the DCMI Registry Working Group and other members of the DCMI for their
contribution to the formulation of ideas expressed in this article and
for their support in the development work.
Notes and References
[1] The DARPA Agent Markup Language is accessible at <http://www.daml.org/>.
[2] The Ontology Interface Layer is accessible at <http://www.ontoknowledge.org/oil/>.
[3] Source code for the registry applications is available at
<http://eor.dublincore.org/>.
[4] The registry working group archives are available at <http://www.jiscmail.ac.uk/lists/dc-registry.html>.
[5] The prototypes are accessible at <http://wip.dublincore.org:8080/registry/Registry>.
[6 ] Java is developed using Sun's Java
Community Process. This process is dedicated to open standards and has
many similarities to open-source, but is not technically considered
open-source.
[7] One of the known requirements for the metadata registry is
that it be multilingual, both from a user interface (UI) and a data
perspective. All three of the prototypes were written with this requirement
in mind, and several different approaches were used. The Dublin Core
element set is currently translated into fourteen different languages, of
which six were selected to serve as proof of concept. The selected
languages include those comprised of both single and double byte
character sets (i.e., Spanish and Japanese). Due to the cost of the
translations, and the temporary nature of the prototypes, only portions
of the data and user interface (enough to serve as proof of concept) were
translated in each application.
[8] The Stanford API is accessible at <http://www-db.stanford.edu/~melnik/rdf/api.html>.
[9]The IMS Global Consortium, Inc. (<http://imsproject.org/metadata/>)
is an organization committed to the development and promotion of metadata
standards related to various aspects of distributed learning.
[10] PostgreSQL is accessible at <http://www.us.postgresql.org/>.
[11] The ResourceBundle class
documentation (<http://java.sun.com/products/jdk/1.1/docs/api/java.util.ResourceBundle.html>)
is a good source of information regarding resource bundles and their use.
[12] This was done as a temporary measure. A more practical
approach for a production version of this prototype would be to store the
URL of the registered schemas and load them via the network at system
startup.
[13] A limited degree of searching is still possible due to the
internal search function provided with most Web browsers.
[14] Jena is
accessible at <http://www.hpl.hp.com/semweb/jena-top.html>.
[15] The ARP Parser is accessible at <http://www.hpl.hp.com/semweb/arp.html>.
[16] BerkeleyDB is accessible at <http://www.sleepycat.com/index.html>.
Resources
[i] W3C Semantic Web Activity Group.
Accessed February 11, 2002. <http://www.w3.org/2001/sw/Activity>.
[ii] Resource Description Framework (RDF). Accessed February 11,
2002. <http://www.w3.org/RDF/>.
[iii] Resource Description Framework (RDF) Schema Specification
1.0. W3C Candidate Recommendation 27 March 2000. Work in progress. <http://www.w3.org/TR/rdf-schema>.
[iv] RDFCore Working Group. Accessed
February 11, 2002. <http://www.w3.org/2001/sw/RDFCore/>.
[v] W3C Web-Ontology (WebOnt) Working Group. Accessed February 11, 2002.
<http://www.w3.org/2001/sw/WebOnt/>.
[vi] DAML+OIL Web Ontology Language. Accessed January 14, 2002.
<http://www.w3.org/Submission/2001/12/>.
[vii] ISO/IEC 11179-1:1999 Specification and standardization of
data elements. Part 1: Framework for the specification and
standardization of data elements (available in English only).
International Standards Organisation.
[viii] National Health Information Knowledgebase. Hosted by the
Australian Institute of Health and Welfare. Accessed February 11, 2002.
<http://www.aihw.gov.au/knowledgebase/index.html>.
[ix] Environmental Data Registry. Accessed February 8, 2002. <http://www.epa.gov/edr/>.
[x] The XML Registry hosted by OASIS. Accessed February 11, 2002.
<http://www.xml.org/xml/registry.jsp>.
[xi] MetaForm: Database containing
Dublin Core manifestations and other metadata formats. Hosted at the
State and University Library in Goettingen.
Accessed February 11, 2002. <http://www2.sub.uni-goettingen.de/metaform/>.
[xii] SWAG Dictionary. Accessed February 11, 2002. <http://webns.net/>.
[xiii] LEXML: Open Source Development of an RDF Dictionary.
Accessed February 11, 2002. <http://home.snafu.de/mmuller/lexmlde/rdf.htm>.
[xiv] SCHEMAS Forum for Metadata Implementors
Registry. Accessed February 11, 2002. <http://www.schemas-forum.org/registry/>.
[xv] Dublin Core Metadata Initiative. DCMI Registry Working
Group. Accessed January 14, 2002. <http://dublincore.org/groups/registry/>.
[xvi] Dublin Core Metadata Initiative DCMI Registry Functional Requirements.
Rachel Heery. Accessed January 10, 2002. <http://dublincore.org/groups/registry/fun_req_ph1-20011031.shtml>.
[xvii] OCLC Office of Research. Dublin
Core Metadata Initiative. Extensible Open RDF Toolkit. Accessed January
14, 2002. <http://eor.dublincore.org/>.
[xiii] World Wide Web Consortium. RDF Schema for the RDF Data
Model. Accessed January 15, 2002. <http://www.w3.org/1999/02/22-rdf-syntax-ns>.
[xix] Sun Microsystems. Internationalization. Accessed January
15, 2002. <http://java.sun.com/products/jdk/1.1/docs/guide/intl/>.
|