Information Systems Design Paper
IMT 548, Fall 2003
October 24, 2003
[not the final version that I submitted to Roger.]
Title: A survey of the terminology and the activity of metadata architecture
What is metadata architecture? This paper samples some of the current thinking as
expressed in books, on-line articles, and other sources to understand what the terms and
the concept mean to information professionals. There are such things as metadata
architectures, people are using them, talking about them, and designing them. There is a
distinction to be made between ‘a metadata architecture’, such as an instance of an
architecture; and the process of ‘metadata architecture’, that is the practice of creating
one: the former is a blueprint, the latter the activity of drawing of them. This paper
reports on the current thinking on both things. It also makes a business case to support
why we should care about what metadata architecture is and why and how to follow
current best practices.
Keywords: metadata, information, system of systems architecture. Taxonomies, website
navigation, Dublin Core, information modeling.
This paper was inspired by a special workshop session at the 2003 Dublin Core
Conference held in Seattle this year. The session was entitled “The Computer and
Information Architectures of Metadata”. The session was meant to be provocative, to
make all of us think and converse about the use of metadata in information architecture.
This paper aims to be an extension of that dialog, asking the question, what is metadata
architecture? Is there even such thing as a metadata architecture? What would it look
like? Who does it? How is it different from information architecture and where would it
fit in some of the current thinking of architectural frameworks? And why care? In order
to answer these questions, this paper will sample some of the current ideas about
metadata architecture as found in books, on-line articles, and other sources in order
determine what the terms and the concepts mean.
Hopefully, this paper will help define the terminology and the practice. There is
some distinction to be made between ‘a metadata architecture’, such as an instance of an
architecture; and the process of ‘metadata architecture’, that is the practice of creating
one. The former is a blueprint, the latter the activity of drawing of them.
The 2003 Dublin Core Conference in Seattle this year is the departure point for
the topic of metadata architecture. Mary Lee Kennedy, director of Microsoft’s
Knowledge Network Group (KNG), gave the first plenary addresses (Kennedy 2003).
She said that the mission of any information system is to simply meet the user needs thru
the organization of information resources. She talked about KNG’s approach to
information systems design: they look first at the business needs from the business
perspective. Their model is based upon the belief that information excellence will result
in employees finding the right quality and quantity of information they need (which, she
said, no one has yet done perfectly). She showed the audience that much of the success of
their new intranet knowledge management system was due to sophisticated metadata
Definitions: What is it?
First, what is metadata? Metadata, as it is used in information systems (also
spelled ‘meta-data’, or ‘meta data’), acts something like label attached to an information
resource (Hutchinson). It has a long history of use in the library science profession. The
W3C included special “META” tags for this purpose in the early HTML specifications. I
was to be used by web page authors to help make finding and sharing their content easier
on their web sites. Metadata therefore has a purpose: “it makes content findable by
describing it in structured ways that both people and computers can understand” (ibid).
We use metadata to describe any information resource we store away, manage, and
retrieve. For information systems, such as a web site, metadata is used in sophisticated
ways “to describe documents, pages, images…and other content objects for the purposes
of improved navigation and retrieval” (Rosenfeld 177).
There are various ways to associate metadata with an information resource. For
example, there is embedded metadata, which is metadata embedded in the resource itself
(such as between the “<HEAD>” tags of an HTML document). There is associated
metadata, which is the management of metadata records for those resources in a separate
container (like library card-catalogs). There is third-party metadata, such as an index of
web pages managed by a search engine (Duval 7). Metadata can be created for a resource
automatically by the program creating it (such as with a MS Word document). Authors of
such resources often have the option to create metadata at the time they create their
documents --although seldom do (ibid).
Next, what is architecture? Specifically, what is information system architecture?
An IBM Systems Journal author defined it as the following:
“The architecture of an IT system is the structure of structures of the
system, which comprise software and hardware components, the externally visible
properties of those components, and the relationships among them” (Youngs 35).
Another author, who specializes in information architecture consulting (mostly for
web sites and search engines), defined information architecture as several things:
“The combination of organization, labeling, and navigation schemes
within an information system”; and, “The structural design of an information
space to facilitate task completion and intuitive access to content”; and, “The art
and science of structuring and classifying web sites and intranets to help people
find and manage information” (Rosenfeld 4).
Another useful definition comes from Richard Saul Wurman (or, at least, it was
attributed to him). Wurman saw the “problems of gathering, organizing, and presenting
information as closely analogous to the problems an architect faces in designing a
building that will serve the needs of its occupants” (Wyllys). For Wurman, architecture
whether for buildings or for information systems, must identify such needs and organize
them “into a coherent pattern that clarifies their nature and interactions” (ibid).
These contrasting views help build a context for a definition of metadata
architecture and its use in information systems design. The first definition is devoid of
any reference to any human beings involved in the system. Metadata components in a
system can play such a ‘structure of the structure’ role, detached from human invention.
The next few definitions are more human centered and certainly web-centric. Metadata
usage in the last ten years has paralleled the growth of the WWW. The last definition
uses the analogy of the architecture of buildings to describe the ideal nature of
information architecture. The design and implementation of metadata components serve
the navigational needs of the users of the system, just as the arrangement and
functionality of certain rooms would in a house.
One of the first uses of the term ‘metadata architecture’ can be found in an
informal W3C web page by Tim Berners-Lee in 1997 (Berners-Lee 1997). The paper
represented some of his earliest thinking on what he and the W3C would call the
‘semantic web’. The paper can be seen as an early framework to build systems that used
‘self-describing data’. Today, his statements in the paper resonate more as ‘metadata
axioms’ rather than a set of heuristics to guide a practical framework. His statements
abstractly describe the functional use of metadata with axioms like “(m)etadata is
machine understandable information about web resources and other things” (Berners-Lee
1997:1). He presented other useful axioms such as “(m)etadata about one document can
occur within the document, or within a separate document, or it may be transferred
accompanying the document” (1997:2). The paper lays out several general rules,
culminating with the use of propositional logic statement to formally describe his model.
His ideas probably didn’t make many headlines back in 1997. Even today, the
esoteric subject and the Euclidean tone of it might put off a reader. But this paper is an
important contribution to any quest to understand what a metadata architecture might be.
For instance, he declared that “metadata can be a first class object” (ibid) meaning (I
think) that a metadata object (like a class instance of some metadata) may serve as a
representation, even a viable proxy, of an information resource. He suggested that “(t)he
architecture is of metadata represented as a set of independent assertions” (3) and this is
certainly true whether you read a library catalog entry, or view a page about a CD on
Amazon.com. Those ‘independent assertions’ are attributes of the resource they represent
(ibid). Any number of assertions (mostly as value pairs), whether independent of each
other or not, can be combined to create sets of statements about a resource. These simple
ideas form a basic, abstract model of metadata for information resources. How machine
readable and human understandable value pairs become ‘self describing data’, as
Berners-Lee envisioned, is (I believe) thru the work of architecture.
Metadata architecture to some other authors has more to do with the
implementation and arrangement of metadata resources, such as what kind of mark-up
language to use and what role registry servers should play (Dodds 328, Lang 2003). Just
as in the arrangement of the interior of a house, a metadata architecture implementation
would be concerned with the arrangement of what type of metadata the information
resources would have (such as embedded or external). It would also be concerned with
the arrangement of things known as ‘registries’, where the schema for a metadata record
is stored and retrieved; and ‘catalogs’ (also called ‘repositories’), where instances of
metadata records are stored and retrieved.
Implementation issues are an important part of a metadata architecture; but
focusing on implementation and technological issues can no longer suffice for a
repeatable, proven framework. During the 2003 DCMI conference (Seattle), a special
session held that also considered the question, ‘what is metadata architecture’. There
seems no doubt among many practicing information system architects as to the value and
role of metadata in their system architecture; but how, some of us asked, should the
‘structure of structures of the system’ involving metadata be articulated, framed, and
One presenter at that session, Carol A. Hert, Syracuse University, said that
information architectures must address “what metadata are necessary to support the user
experience” (Hert). She said that information architecture must be informed as to “what
representations and systems support (would be need for) the processing of metadata”
(ibid). For Carol Hert, what a metadata architecture might do is to describe the
“(r)elationships of metadata schemas/structures/etc., to the inherent structures and use of
the information represented”. It would also include definitions of the “(r)elationships of
information architectures and the available technologies to support the information”
The idea that a metadata architecture is an essential part of a larger information
architecture of an information system was a theme in the other presentations and the
session in general. Such an architecture is concerned with schemas and information
structures (as components which support the user experience), and the consideration of
the right technology to implement it. Two other presenters at the special session, Anca
Mosoiu and Brett Lider, shared a case study of a corporate web site overhaul. In their
case, the architectural focus on an information system’s metadata drove the site’s re-
design. The improved site improved internal knowledge sharing and influenced the
corporation’s business processes for the better. In their metadata architecture taxonomy, a
kind of codification of the business process domain played a critical role. This is an
important facet of metadata architecture: metadata helps manage the human meaning of
information in a system.
So far in this paper, a metadata architecture might be defined as the description
(as in a design description) of structured and semantically meaningful to an audience
(some user group) of metadata that mean something about a resource. Each assertion may
be independent of the other. Metadata may be embedded in the resource or external to it.
Metadata may be created by the author; or, by default with the software used by the
author; or, a third party may create it. A metadata architecture can be said to be
concerned with any aspect of the structure, use, and implementation of metadata in an
information system. Further, whether metadata is embedded in the information resource,
or not, will influence the architectural decisions. Lastly, metadata architecture does not
seem to be the same as a data model for a system; rather, it seems to be more of a model
of the meaning users have about their information, a kind of semantic access layer to
resources that might be represented in a data model.
What are some examples?
Metadata architecture is not a trivial add-on to existing information system, or a
roughly applied set of tags to existing web pages. It is more than mark-up added to a web
page or named value pairs embedded in Word document. It is useful for information
retrieval by human beings and it is consumed by software (sometimes called ‘agents’ in
the literature) to find resources in a networked environment. But just throwing metadata
at a problem assuming this alone can improve information retrieval performance
(Maclaclan) is not a complete picture of its utility. Metadata in itself is meaningless
without some sort of interpretative structure to use it with. This section will examine a
sample of people and institutions that used some kind of metadata architecture, or where
metadata was architected as a component architecture of a larger information architecture
As information architects, an excellent resource for learning good architectural
and design methodology is from the experiences of librarians, archivists, and academic
researchers. The best approach to designing anything is to know beforehand what will
work and why, and what might be improved upon or customized to work to help solve
our business problems. For example, in the mid-nineties, the Library of Congress started
the National Digital Library Project (NDLP). Their goal was to digitize certain historical
collections and make them available for researchers on the web (Arms 3). By 1997,
they’d created a pilot system. Their architecture was built from simple components they
called ‘digital objects’. These objects could be a single resource, such as a diary from the
Civil War, or some portion of that resource (such as a single entry). This was necessary to
address the nature of their collection: “a single work may have many parts, a complex
structure, and one or more arbitrary relations to other works (2).
The NDLP architecture started with a high-level model of activities: user-search,
user-select, system-retrieve, and system-display. This architectural approach was based
upon three essential principles (or model): First, “the organization of information must
not be biased by expectations about how users will approach the system, nor assumptions
about their level of expertise, or the sequence in which items will be accessed” (5). Next,
the digital library assets must be easy to manage (ibid); finally, the architecture “must
reflect the economic, social, and legal frameworks developing in the information
infrastructure” (ibid). For the NDLP system, the philosophical principles used to govern
the architecture lead to meeting one of their primary goals, the implementation of a
flexible information management retrieval system for their diverse community of users.
Paul Miller, a prolific author and theorist of information system interoperability
from the digital library world, considers “architectures as forming a philosophical basis”
(Miller 2001:1) from which interoperability frameworks may be created. He saw
information architecture in general as having three distinct elements. There is the
‘technical architecture’, such as a technical or implementation view of how the system
might work. There is a ‘functional architecture’, which can be thought of as a process
view. Lastly, there is something he termed “the landscape architecture” that “serves to
bound the realm of possibilities, to define what is in and what is out and to describe the
relationships between users, resources, and technical systems” (2). I think He would
likely agree that metadata architecture would belong here.
In systems analysis, analysts usually define the boundaries of a system. How they
arrive at what those may be is sometimes a best guess (we call it ‘professional
engineering judgment’). Metadata architecture can provide substantial and verifiable
boundaries for a collection of structured information: these boundaries can be modeled
with taxonomies, or with ontologies (which are not the same thing as taxonomies).
Metadata and its structure becomes an important architectural element to define the
semantic boundaries of our information ‘architectural landscape’. Such boundaries might
further be the relationships of information resources to each other, to external collections,
or by the relationships resources have to an audience (discrete user groups). Miller
reminds us that defining audience is still a challenge in our field. He warns us all that it is
not trivial: “Information architects, and others”, he wrote, “always make sweeping
assumptions about what users want, often based upon their own behavior or upon
unrealistic expectations of the ‘typical user’, were such an individual to exist” (6).
Taxonomies were mentioned above as an important aspect of a metadata
architecture. Brett Lider, who gave a separate presentation at the special session of the
2003 DCMI Conference, suggested that taxonomies and metadata should be used as tools
of the information architect. Lider showed that an architect’s use of taxonomy provide
users with a natural navigation to information and functionality. “Metadata”, he said ,
“can support holistic modeling of the business, making the website a manifestation of the
business and not just a separate entity” (Lider). Paul Miller recommended,
“(t)erminolgical tools such as thesauri are an important foundation in effectively creating,
curating, and reusing rich information resources in an on-line environment (Miller
Certain academic, government (including military), and library communities in
the United Kingdom see the architecture of metadata as an extremely important topic.
Some of these institutions, such as the UKOLN (United Kingdom Office for Library and
Information Networking), are leaders in the research and art of information and metadata
architectures. Initiatives such as the UK’s e-Government Strategy (e-Gif 7), for example,
required a new level of thinking from all stakeholders about the architecture and
arrangement of information resources. Some of the things they had to deal with were
non-trivial issues such as the need for a commonality of structure, use, and semantics to
coordinate and share resources. The UK’s recent e-Science program is another excellent
example: “e-Science is about global collaboration in key areas of science, and the next
generation of infrastructure that will enable it” (Adrianne 2002:6). The e-Science
program contains a number of projects to find more effective ways to share vast amounts
of scientific research data. Among other things, their experiments with “(d)iscovery
process mark-up language” and more robust federated searching are another link in a
chain of this evolving metadata architecture practice. How metadata is implemented in
these projects may change the way scientific research is done: researchers will be able to
do more ‘collection based research’ more easily (2).
Metadata architecture is critical for the success of such initiatives as e-Science
and e-Government in the U.K. Web services technology, becoming more prevalent today,
use metadata for service discovery, navigation, and retrieval of distributed information
resources. Metadata architecture could be said to add a kind of semantic layer between
resources and the diversity of the audience of information consumers (who might be
human or software agents) for those resources. This is a new kind of architectural
thinking for information systems design, perhaps owed to the earlier work done by those
implementers of Z39.5 for library systems. It is a model that moves us away from direct
queries of resources to a federated search of multiple metadata resources and services for
information –in effect, building haystacks to find needles (4).
The JISC Information Environment (United Kingdom) architecture showed how
the implementation of multiple resource searching (also called a federated search)
accomplished thru web services and an architectural arrangement of metadata can be
achieved (Powell 2002). In order to support discovery and quires across multiple content
providers, metadata had to be made available for searching, harvesting and for alert
services. The functionality of what they called the “fusion layer “(Adrianne 2002:2) may
be another example of metadata architecture: “(t)his layer is responsible for combining
metadata records from one or more content providers . . ..” (Ibid). The fusion layer
included several components of modest cohesion, such as “terminology services,
metadata schema registries, index services, institutional profiling services, and user-
personalization services” (3).
Digital Rights Management (DRM) is another domain where the concepts of
metadata architecture are becoming prominent. The Open DRM Framework (a proposal
from a W3C workshop) demonstrated the need for a new model for digital rights
management. The framework described a metadata model to support privacy (social
stream), rights (legal stream), and a common mark-up language to support the exchange
of digital information (business stream) (Iannella).
How is it done?
The trend of enterprise information systems away from static, stovepipe client-
server transactional systems toward flexible, federated web services, and the new so-
called “content-centric applications” (Gilpin), may require some sort of metadata
architecture to mature into a distinct discipline providing essential structure for an larger
information architectural picture. Something like this is already necessary to deal with the
details of user-terminology and environmental vocabulary control in large systems; or,
how to arrange schema registries and repositories for optimal performance and
interoperability with other systems; or, even what metadata schemas are appropriate for
what problem. This section will examine some ideas about such frameworks.
The Dublin Core metadata initiative was a movement driven by the efforts of
volunteers from a broad community of interests and specialties. It can point to its origins
to a workshop in 1995 sponsored by the OCLC in Dublin, Ohio, USA (hence the name
“Dublin Core”). The group conscience of the workshop believed that library science
principles could be applied to the chaotic, unbounded collection of material on the WWW
(Hudgins-Bonafield 2). The library science profession had evolved proven and effective
means to catalog bounded collections with cataloging systems such as the MARC. It has
also nearly perfected the implementation of federated searching over networks, sharing
library catalogs with the Z39.5 application protocol (Miller 1999). These models and
expertise had great initial influence on the Dublin Core Metadata Element Set.
Dublin Core is still evolving and working hard to gain acceptance in the US
business and government communities (in contrast to the UK and the EC, which,
comparatively, have embraced it). Andy Powell and the Dublin Core Architecture
Working Group in proposed a draft abstract model this year (Powell 2003). It was
presented at the 2003 convention in Seattle. Andy said it was informed by the best
practices of how people are actually using the DC in their metadata architecture. His
model was written in prose, with some generalized examples. This sort of approach
turned off some UML/OMG Nazis at the conference, who seem to reject any model that
is not displayed with hieroglyphic boxes and cryptic arrows. They and others missed the
point of the model: it was to assess how the use of DC has evolved and is practiced, eight
years after its inception. It was a survey that was generalized into a model based on real-
life best practices.
The Warwick Framework (named for the place a workshop was held in Warwick,
England) from 1996 probably represents the most complete and deliberate explanation of
a metadata architecture framework to date. The rational of the framework reads
“With the rapid increase in the number and variety of networked
resources, there is a growing need for an architecture for associating diverse types
of metadata with those resources” (Lagoze).
The framework model is based on the assumption fact that metadata, by its nature,
takes on a variety of forms; it can be either specialized or general (2); and the range of the
diversity of forms of metadata will continue to expand, especially as new tools are
developed to assign semantic meaning to information for retrieval (ibid). The framework
posits several practical axiomatic statements (in the sense that the rules they lay out are
reasonably applicable to information systems) to effectively deal with the ever expanding
scope of metadata. It recommends a container architecture approach to provide a
mechanism for aggregating logically related but discrete packages of metadata objects
(ibid). These containers may be persistent or transitory, based on the needs of the
business problem being solved. Authority, Rights, and Use were noteworthy key
components in this architecture both at the package and container levels. The
framework’s metadata packages and containers were thought ideal for a COBRA
However metadata is implemented in an information system, there is still a need
for practical guides and best practices to inform the architecture. A good way for an
architect to start would be to follow the suggested principles co-authored by Erik Duval,
Stuart Sutton (UW) and Stuart Weibel (Dublin Core) in Metadata Principles and
Practicalities. Essentially, they propose key questions that should be asked by the
architect, such as
• Implementation: How should metadata be integrated into the information system?
How should Registries be architected (Duval)?
• Authority: “How is it to be created? Who is the authority (ibid)?
• Extensibility: How should it be extended? How are elements refined?
• Modularity: How should it be used and exchanged? What elements are optional?
• Standardization: What standards should be followed? Should we mix standards?
This choice drives the interoperability level of the system.
• Namespaces: These play a critical role in metadata exchange. What is the policy
and structure to be?
• Multilingualism: In most large business information systems today, this is a big
and complex issue.
• Vocabularies: The question should not be ‘Do we need a taxonomy’ it should be
‘What audience, purpose, needs do we start with for the first taxonomy’.
Like Andy Powell’s abstract model, this resource lays out practical rules of thumb and
best practices heuristics from many implementation experiences.
Why care? What’s the business case?
Metadata is not just for use in library catalogs, academic researchers, or web sites.
Every digital object created today has some kind of metadata associate with it, even if it’s
just the lowly time stamp or location on a disk. The advent of Google, its rising
popularity, and it’s seemingly great ability to help us find things on the web may lead
business strategists to think we really need nothing more to manage information. But
search engines have limitations in that they can only index what’s been published in a
simple, brute force way. If you are a domain expert you may find using a search engine
as useful because you know the terminology of the domain; the weakness here lies in the
fact you must depend on others knowing that same terminology in the same way. This is
not always the case. In effect, you have to create a haystack to find that one sought-for
needle. Even if you find that needle, you might not even know it’s what you were looking
for in the first place.
Metadata in itself does not solve all of our information management and retrieval
problems. There is no perfect solution, no perfect metadata. However, the use of a model,
a framework, and an architectural approach in the design of a system that will use it
effectively, will lead us away from having to build haystacks and instead go to a garden
of information. There is proven value in the integration of information systems as it goes
along with the integration of the business processes they support. Also, software
applications themselves are changing to reflect the business needs toward integration,
interoperability, and seamless exchange and retrieval of information. One group of
authors from Giga Reasearch suggested in an article “by the end of 2004 many of today’s
applications will have begun the shift from being centered primarily upon the input and
maintenance of transactional data to a more content-integrate/content-centric paradigm”
(Gilpin). The first business case to ask decision makers, knowing the information world
and our access to it is changing, then what is the opportunity cost of not developing
First, a review of what the sample of literature this paper covered helped determine
what metadata architecture is:
• There is indeed a thing out there called ‘metadata architecture’; people are
practicing it, talking about it, evolving it.
• There may or may not be such things as ‘metadata architects’ (yet).
• Metadata itself can be a useful tool for information architects in their practice.
“Metadata”, said Bret Lider, “can get our site structure layout semantics out of
our heads and embedded in the system logic” (Lider 2003).
• Metadata’s importance to information systems design is considered by some to be
a “key part of the information infrastructure necessary to help create order in the
chaos of the Web” (Duval 10).
• An architecture of metadata should at least cover the Business Needs from the
Business Perspective, Technical Implementation, Authority, Extensibility,
Modularity, Standardization, Namespaces, Multilingualism,
• It is still a new skill set and domain; those who want to practice it should be
continually aware of what the more experienced professions are doing
• Metadata architecture likely to remain a component of a larger information
Table 1. How metadata architecture fits into a system of systems architecture
Architectural Architectural Facets Explanation
Scope (from Paul Miller
System of Systems Architecture
Implementation Technical - Do we have individual or
Plans and Architecture clusters of systems?
constraints - Interfaces
- Where do we put things?
Information Functional - Models that address the
Architecture Architecture functions that system(s) shall
- Can be System or User
Landscape - Bounds of the systems’
(Metadata - Metadata architecture
architecture) - Use Taxonomies to define
Next, where does metadata architecture fit into the other frameworks, such as
Zachman framework? Zachman wrote, “any model that is produced can be classified by
the Framework” (meaning his) (Zachman Year? 3). Taxonomies are a part of metadata
architecture. The process of discovery and building a taxonomy (or a more sophisticated
thesaurus structure) would contribute nicely to each cell in the first row. Data models will
almost always be necessary in most information systems architectures. The difference of
a metadata ‘data model’ is that what’s being modeled is volatile information about the
information in an enterprise data model. Thus, metadata architecture might contribute to
the Data cell of the second row (Business Model) --perhaps driving the same cell,
following row, the Logical Data model.
Zachman said that “(t)he Framework is simply a classification scheme . . . like the
periodic table, it hypothesizes the existence of all of the primitive elements” (Zachman
Year? 3). One thing the discovery and process of metadata architecture could also do is
make what Zachman called the ‘Enterprise primitive models’ explicit, known, and
documented. “Implicit in the operating Enterprise are all of the primitive models”, he
said, “it is only a question of whether you make them explicit of not. Making them
explicit enables you to remove the erroneous assumptions (defects), reconcile dissonant
perceptions (entropy) or engineer improvements (change)” (Zachman Year? 5). Modeling
how the organization shall exchange the meaning of its information will undoubtedly
raise such ‘primitive models’ to the foreground.
Whenever metadata must be exchanged from one system to other systems, a
metadata architecture might fit into row 3, in the cells ‘How’, ‘Where’, and even ‘Who’.
The above mention of the necessity to determine how to arrange and manage registries
and repositories (or the Warwick containers), the final two rows, four and five, all cells
could be potentially impacted by a metadata architecture (depending on the type of
system being architected: for a web site, where metadata might be driving things from
presentation services to transactional updates to data stores, then this might be the case;
other systems, that might be essentially mining metadata from distributed stores, then this
would be less the case).
Finally, back to Mary Lee Kennedy and her address to the 2003 DC conference.
She said that the buzz she hears in conferences like that one is that she hears less often
about information overload, but rather the expectation that information is being managed.
For those of us who work on and use information systems in large corporations, this is
almost shocking: many of us know that information is anything but managed. However,
most architecture approaches in this paper begin with simple questions that system
analysts always (should) ask, such as ‘What is the purpose of this company (or group/org/
institution)?’ ‘Why does it matter to us to do this particular thing (in which we need
information)?’ (If it doesn’t address a real business need, then it is likely not going to get
funded.) The imperative today is that there is less time and money to experiment with the
latest tools and ideas. Today’s information needs seem more critical; however, people
generally seem to find the information they’re after but often at a great cost of time and
money. Perhaps the work in metadata architecture will help.
Ariadne. “The Information Grid: Aridane reports on a one-day workshop on an
'interoperable environment to support research, learning and teaching' held at the e-
Science Institute in Edinburgh, April 30, 2002”. Ariadne Issue 32, July 8, 2002. 14 Oct.
Arms, William Y, Christophe Blanchi, Edward A. Overly. “An Architecture for
Information in Digital Libraries”. D-Lib Magazine, February 1997. 14 Oct. 2003
Berners-Lee, Tim. “Metadata Architecture”. January 6, 1997. 14 Oct. 2003
Dodds, David, et al. Professional XML Meta Data. Birmingham, UK: Wrox Press, Inc.,
Duval, Erik, Wayne Hodgins, Stuart Sutton, Stuart Weibel. “Metadata Principles and
Practicalities”. D-Lib Magazine, April 2003, Vol. 8, Number 4. Oct 22, 2003
e-Gif. “e-Government Interoperability Framework Part One: Framework Version 5.0”. 14
Oct. 2003. <<http://www.govtalk.gov.uk/schemasstandards/egif.asp>>.
Gilpin, Mark, Rober Markham, John Meyer, Connie Moore. “The Architecture of
Content-Centric Applications”. Giga Research, July 11, 2003.
Hert, Carol A. Convenor presentation. "The Computer and Information Architectures of
Metadata". Special Session: The Computer and Information Architectures of Metadata.
DC 2003 Dublin Core Conference, Seattle. 2 October 2003.
Hudgins-Bonafield, Christine. “Who Will Master Metadata?” Network Computing. 14
Oct. 2003 <http://www.networkcomputing.com/608/608business.html>>.
Hutchinson, Bill. “A Layman's Introduction to metadata”. 14 Oct. 2003.
Iannella, Renato. “Open Digital Rights Management: A Position Paper for the W3C
DRM Workshop” (Dec 2000). 18 Oct. 2003 <<http://www.w3.org/2000/12/drm-
Kennedy, Mary Lee. Plenary. DC 2003 Dublin Core Conference, Seattle. 29 September
Lagoze, Carl. “The Warwick Framework: A container Architecture for Diverse Sets of
Metadata.” D-Lib Magazine (July/August 1996). 14 Oct.
Lang, Michael, John Dodd, et al. “Business Integration Driven by Business Lines: A
perspective on the Data Reference Model as it relates to Cross Agency Challenges.
Standards Based Architecture to Support Federated Data Management (a white paper)”.
(May 28, 2003).
Lider, Brett Presentation. “Information Architecture and Metadata”. Special Session:
The Computer and Information Architectures of Metadata. DC 2003 Dublin Core
Conference, Seattle. 2 October 2003.
Maclaclan, Malcom. “Meta-Tagging May Improve Web Searches”. TechWeb (on-line
newsletter) (April 17, 1998). Oct 14, 2003
Miller, Paul. “Z39.50 for All”. Ariadne Issue 21 (September 20, 1999). 14 Oct. 2003
Miller, Paul. “Architects of the Information Age”. Ariadne Issue 29 (October 9, 2001). 14
Oct. 2003 <<www.ariadne.ac.uk/issue29/miller/intro.html>>.
Mosoiu, Anca, Brett Lider. Presentation. "Case study of Metadata Architecture –
Computer Architecture (implementation) and Information Architecture (user interface)".
Special Session: The Computer and Information Architectures of Metadata. DC 2003
Dublin Core Conference, Seattle. 2 October 2003.
Powell, Andy. “Dublin Core Abstract Model”. (2003-08-11). 14 Oct. 2003
Powell, Andy, Liz Lyon. “The JISC Information Environment and Web Services”.
Ariadne Issue 31 (April 25, 2002 ) 14 Oct. 2003
Rosenfeld, Lou, Peter Morville. “Information Architecture for the World Wide Web:
Designing Large-Scale Web Sites”, 2nd edition (August 15, 2002). O'ReillyAssociates.
Wyllys, R.E. “Information Architecture” (2000). 14 Oct. 2003
Youngs, R, D. Redmond-Pyle, et al. “A Standard for architecture description”. IBM
Systems Journal, Vol. 38, No 1 (1999).
Zachman, Johh A. “Zachman on the Framework”. ZIFA 09. 14 Oct. 2003