Duane McCollum
Information Systems Design Paper
IMT 548, Fall 2003
October 24, 2003
         This paper was inspired by a special workshop session at the 2003 Dublin Core
Conference held in Sea...
There are various ways to associate metadata with an information resource. For
example, there is embedded metadata, which ...
represented some of his earliest thinking on what he and the W3C would call the
‘semantic web’. The paper can be seen as a...
One presenter at that session, Carol A. Hert, Syracuse University, said that
information architectures must address “what ...
sample of people and institutions that used some kind of metadata architecture, or where
metadata was architected as a com...
further be the relationships of information resources to each other, to external collections,
or by the relationships reso...
The JISC Information Environment (United Kingdom) architecture showed how
the implementation of multiple resource searchin...
Working Group in proposed a draft abstract model this year (Powell 2003). It was
presented at the 2003 convention in Seatt...
•   Namespaces: These play a critical role in metadata exchange. What is the policy
       and structure to be?
   •   Mul...
•                          There is indeed a thing out there called ‘metadata architecture’; people are
architecture. The process of discovery and building a taxonomy (or a more sophisticated
thesaurus structure) would contrib...

Ariadne. “The Information Grid: Aridane reports on a one-day workshop on an
'interoperable environment to su...
Lagoze, Carl. “The Warwick Framework: A container Architecture for Diverse Sets of
Metadata.” D-Lib Magazine (July/August ...
Upcoming SlideShare
Loading in …5



Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Duane McCollum Information Systems Design Paper IMT 548, Fall 2003 October 24, 2003 djm4@u.washington.edu duane.j.mccollum@boeing.com [not the final version that I submitted to Roger.] Title: A survey of the terminology and the activity of metadata architecture Abstract: 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. 1
  2. 2. Introduction 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 architecture. 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). 2
  3. 3. 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 3
  4. 4. 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 built? 4
  5. 5. 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” system (ibid). 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 5
  6. 6. 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 project. 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 6
  7. 7. 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 2000:10). 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). 7
  8. 8. 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 8
  9. 9. 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 implementation (6). 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. 9
  10. 10. • 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 metadata architecture? Conclusion First, a review of what the sample of literature this paper covered helped determine what metadata architecture is: 10
  11. 11. • 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, Vocabularies/taxonomies (Duval). • 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 architecture. Table 1. How metadata architecture fits into a system of systems architecture Architectural Architectural Facets Explanation Scope (from Paul Miller 2001) 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 fulfill - Can be System or User focused perspective Landscape - Bounds of the systems’ Architecture possibilities (Metadata - Metadata architecture architecture) - Use Taxonomies to define those boundaries! 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 11
  12. 12. 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. 12
  13. 13. Bibliography 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. 2003 <<http://www.ariadne.ac.uk/issue32/information-grid/intro.html>> Arms, William Y, Christophe Blanchi, Edward A. Overly. “An Architecture for Information in Digital Libraries”. D-Lib Magazine, February 1997. 14 Oct. 2003 <<www.dlib.org/dlib/february97/cnri/02arms1.html>>. Berners-Lee, Tim. “Metadata Architecture”. January 6, 1997. 14 Oct. 2003 <<http://www.w3.org/DesignIssues/Metadata.html>>. Dodds, David, et al. Professional XML Meta Data. Birmingham, UK: Wrox Press, Inc., July 2001. Duval, Erik, Wayne Hodgins, Stuart Sutton, Stuart Weibel. “Metadata Principles and Practicalities”. D-Lib Magazine, April 2003, Vol. 8, Number 4. Oct 22, 2003 <<www.dlib.org/dlib/april02/weibel/04weibel.html>>. 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. <<http://www.govtalk.gov.uk/interoperability/metadata.asp?order=title>> 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- ws/pp/iprsystms-iannella.html>>. Kennedy, Mary Lee. Plenary. DC 2003 Dublin Core Conference, Seattle. 29 September 2003. 13
  14. 14. Lagoze, Carl. “The Warwick Framework: A container Architecture for Diverse Sets of Metadata.” D-Lib Magazine (July/August 1996). 14 Oct. 2003<<www.dlib.org/dlib/july96/lagoze/07/lagoze.html>>. 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 <<http://www.techweb.com/wire/story/TWB19980417S0018>>. Miller, Paul. “Z39.50 for All”. Ariadne Issue 21 (September 20, 1999). 14 Oct. 2003 <<www.ariadne.ac.uk/issue21/z3950/>>. 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 <<http://www.ukoln.ac.uk/metadata/dcmi/abstract-model/>>. Powell, Andy, Liz Lyon. “The JISC Information Environment and Web Services”. Ariadne Issue 31 (April 25, 2002 ) 14 Oct. 2003 <<www.ariadne.ac.uk/issue31/information-environments/intro.html>>. 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 <<www.gslis.utexas.edu/~13861dw/readings/InfoArchitecture.html>>. 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 <<http://www.zifa.com>> 14