System and method for XML based content management

FIELD OF THE INVENTION

0001The present invention relates generally to the field of computing. More particularly, the invention relates to a system and method for content management.

BACKGROUND OF THE INVENTION

0002In the digital realm, content includes any type of digital information that is used to populate a document, a document page, a web page, etc. The digital data can be text, images, graphics, video, sound etc. Content management systems (CMS) have been developed that provide the controls to effectively manage this digital content. Content management systems provides for the management of the content, by combining rules, process and/or workflows in such a way that decentralized authors/editors can create, edit, manage and publish all the content of a document or web pages.

0003The concept of content differs from that of a document. Prior to the development of content management systems, much effort was focused on document management systems (DMS) that provided companies with the ability to gain control over the ever increasing amount of information that they were producing using products like Word, Lotus123, Excel, etc. Companies recognized the need to internally organize documents such as word files, spreadsheets, PowerPoint presentations etc. The need to organize documents resulted in the development of DMS's.

0004With the onslaught of the web and the need to manipulate content at a more granular level than a document provides, many have recognized the need for a variation of the basic DMS. Both CMS's and DMS's enable information to be managed according to rules, processes and workflows, the main differentiation between the two products becomes the granularity of management of the digital information a CMS offers when compared to a DMS. A DMS generally deals with a document as a whole and the information that the document contains is essentially irrelevant. On the other hand, a CMS effectively manages at a micro level the individual units of information that go to making up a document or web page.

0005The Internet is redefining the way organizations create and publish corporate information and documents. Intra-, inter- and extra-nets are replacing the document approach to the storage of information with online, up-to-date web based information. The result of this shift is that companies are more interested in managing information at the more granular content level rather than the less granular document level.

0006XML is rapidly becoming the vehicle of choice as a definition language for the description of content-related structures. XML provides great flexibility and universality because XML provides a grammar that can express nearly any content. On the Internet in particular, the standardized representation of content structures fosters the development of previously unrecognized applications.

0007In addition to the rise of structured content like XML, relational databases have long been the bulwark of the information infrastructure of countless businesses. Relational databases provide a primary tool for business to maintain, access, and analyze data. Such database technologies have evolved over many years so that they are optimized for accessing and manipulating large information bases. Many businesses store the majority of their critical information in relational databases. Moreover, many Internet sites manage their content using relational database technology. The database approach to content management also makes it possible to develop database search engines for sifting through the large volumes of information that “live” on the Internet.

0008The disconnect between XML and relational databases is that one is hierarchically structured and the other is relationally structured to provide efficient management of large amounts of data. The combination of database technology with self-describing structure of hierarchical languages such as XML opens an interesting perspective for CMS's. One vexing issue is presented when ensuring that seemingly inapposite theoretical constructs between the two data representations are harmonized.

SUMMARY OF THE INVENTION

0009The invention provides a system and method for representing content graphs in a relational database manager for physical instantiation by defining the nodes and relationships as entities in the database. The Dublin core forms the base group of data model entity attribution. This forms a quick physical index scheme for content search and use. The Dublin Core Metadata Initiative serves as the definition of commonly used meta data and forms the core meta data of the CMS Store. This repository is a forest of node-labeled trees in a Dublin core attributed graph store with C# assemblies exposed as Web Service with Content one-level abstracted from structure.

0010The invention facilitates the creation of consumable content, based on an expandable razor/blade approach; content is targeted for multiple consumption methods with targeting editorial voice based upon target platform and audience. Different devices such as digital phones, tablets and PC's require different presentation due to device limits and constraints. Services can be targeted using SOAP for application consumption. Audiences can be targeted with separate navigation, editorial voice and content.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of preferred embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary constructions of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic diagram of a content management system in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> is an example of a computer network wherein aspects of the present invention may be employed;

<figref idref="DRAWINGS">FIG. 3</figref> is a sample of a web page illustrating the content layout and structure provided by a content management system;

<figref idref="DRAWINGS">FIG. 4</figref> is an illustration of the mapping of hierarchical content data into a relational node and edge tables;

<figref idref="DRAWINGS">FIGS. 5A-5G</figref> illustrate the mapping of hierarchical content data into relation tables where the hierarchical structure is represented by a relational model based on nodes and edges;

<figref idref="DRAWINGS">FIG. 6</figref> is an illustration of a database schema derived from an entity relationship model that represents hierarchical content in a relational model; and

<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram of an exemplary computing environment in which aspects of the invention may be implemented.

DETAILED DESCRIPTION OF THE INVENTION

0000Overview

0019The foundation of the content store in accordance with aspects of the invention is based on three basic graphs: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0020">1) Content—Subject</li><li id="ul0002-0002" num="0021">2) Structure</li><li id="ul0002-0003" num="0022">3) Organization</li></ul></li></ul>

0023The graphs are converted into a SQL database manager for physical instantiation by moving into set theory and defining the nodes and relationships as entities. The Dublin core forms the base group of data model entity attribution. This forms a quick physical index scheme for content search and use. The Dublin Core Metadata Initiative serves as the definition of commonly used meta data and forms the core meta data of the CMS Store.

0024The invention facilitates the creation of consumable content, based on an expandable razor/blade approach; content is targeted for multiple consumption methods with targeting editorial voice based upon target platform and audience. Different devices such as digital phones, tablets and PC's require different presentation due to device limits and constraints. Services can be targeted using SOAP for application consumption. Audiences can be targeted with separate navigation, editorial voice and content.

0025The following definitions are useful guides in understanding the present invention. Note, however, that the definitions below are known to those of ordinary skill in the art and are presented here for convenience of the reader.

XML

0027XML stands for eXtensible Markup Language. It is not a language per se but rather a meta language for creating languages. XML provides structure to a document by using tags. XML is a markup language for creating other markup languages. XML was designed to be extensible and simple to implement and is based on SGML. A document that follows XML rules is said to be well-formed. A document can be invalid, but still be well-formed. A valid XML document conforms to a DTD or XML-Schema.

0028Since XML is text-based data type, it is a lightweight and small, making it an efficient transport protocol for dynamic and consumable content. XML allows the efficient exchange of data between applications making it useful for distributed applications. XML schemas are an agreed upon industry-wide initiative to share common application languages based upon XML. The Organization for the Advancement of Structured Information Standards sponsors the ww.xml.org site. The site hosts industry group schemas.

XSL

0030XSL stands for eXtensible Style sheet Language. It is a language for expressing stylesheets and provides display semantics for XML. SXL maps XML elements into HTML or any other formatting language. It is similar in functionality to Cascading Style Sheets (CSS).

0031XML-Schema

0032XML-Schema, a current proposal, is a replacement for DTD. DTD, Document Type Declaration, was designed for legacy text and is not XML compliant. DTD does not support data type validation and supports only one document. A Schema working Group was established to propose the standard to the W3C (see http://www.w3.org/1999/05/06-xmlschema-1/). Schemas support XML syntax and data typing. It is an open content model that supports inheritance, constraints and namespaces. Namespaces are a way to share data between organizations and are a way to avoid element definition collision.

0033Schemas are built in XML and can be used via DOM in Visual Basic or VBScript in ASP. Schemas provide datatypes such as float, currencies as well as relationships between elements. Schemas are extensible and allow for user defined data types.

SOAP

0035SOAP stands for Simple Object Access Protocol (sometimes seen as XOAP). SOAP is an XML-based programming interface that is machine and language independent. It will travel through firewalls. It is extensible and loosely coupled. SOAP uses XML for remote invocation of object methods and can interact with COM, CORBA or EJB. SOAP's goals are to create a standard object invocation protocol built on Internet standards, XML and HTTP that is extensible with an evolving payload format.

0036Dublin Core Metadata Initiative

0037A recognized external standards initiative built around Library sciences, the Dublin Core specifies the following fifteen (15) tags for building card catalogs and meta data. These tags could form the basis for classifying and tagging: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0038">Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, Rights. <br /> Details of the Dublin Core can be found at the following web address: </li><li id="ul0004-0002" num="0039">http://purl.org/dc/documents/rec-dces-19990702.htm <br /> The Dublin Core tags are defined as briefly follows: </li></ul></li></ul>

0040<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Element: Title</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Title</entry></row><row><entry>Identifier:</entry><entry>Title</entry></row><row><entry>Definition:</entry><entry>A name given to the resource.</entry></row><row><entry>Comment:</entry><entry>Typically, a Title will be a name by which the resource is</entry></row><row><entry /><entry>formally known.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Creator</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Creator</entry></row><row><entry>Identifier:</entry><entry>Creator</entry></row><row><entry>Definition:</entry><entry>An entity primarily responsible for making the content of</entry></row><row><entry /><entry>the resource.</entry></row><row><entry>Comment:</entry><entry>Examples of a Creator include a person, an organization,</entry></row><row><entry /><entry>or a service.</entry></row><row><entry /><entry>Typically, the name of a Creator should be used to</entry></row><row><entry /><entry>indicate the entity.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Subject</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Subject and Keywords</entry></row><row><entry>Identifier:</entry><entry>Subject</entry></row><row><entry>Definition:</entry><entry>The topic of the content of the resource.</entry></row><row><entry>Comment:</entry><entry>Typically, a Subject will be expressed as keywords,</entry></row><row><entry /><entry>key phrases or classification codes that describe a topic</entry></row><row><entry /><entry>of the resource.</entry></row><row><entry /><entry>Recommended best practice is to select a value from a</entry></row><row><entry /><entry>controlled vocabulary or formal classification scheme.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Description</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Description</entry></row><row><entry>Identifier:</entry><entry>Description</entry></row><row><entry>Definition:</entry><entry>An account of the content of the resource.</entry></row><row><entry>Comment:</entry><entry>Description may include but is not limited to: an abstract,</entry></row><row><entry /><entry>table of contents, reference to a graphical representation</entry></row><row><entry /><entry>of content or a free-text account of the content.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Publisher</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry> Name:</entry><entry>Publisher</entry></row><row><entry>Identifier:</entry><entry>Publisher</entry></row><row><entry>Definition:</entry><entry>An entity responsible for making the resource available</entry></row><row><entry>Comment:</entry><entry>Examples of a Publisher include a person, an organization,</entry></row><row><entry /><entry>or a service.</entry></row><row><entry /><entry>Typically, the name of a Publisher should be used to</entry></row><row><entry /><entry>indicate the entity.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Contributor</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Contributor</entry></row><row><entry>Identifier:</entry><entry>Contributor</entry></row><row><entry>Definition:</entry><entry>An entity responsible for making contributions to the</entry></row><row><entry /><entry>content of the resource.</entry></row><row><entry>Comment:</entry><entry>Examples of a Contributor include a person, an</entry></row><row><entry /><entry>organization, or a service.</entry></row><row><entry /><entry>Typically, the name of a Contributor should be used to</entry></row><row><entry /><entry>indicate the entity.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Date</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Date</entry></row><row><entry>Identifier:</entry><entry>Date</entry></row><row><entry>Definition:</entry><entry>A date associated with an event in the life cycle of the</entry></row><row><entry /><entry>resource.</entry></row><row><entry>Comment:</entry><entry>Typically, Date will be associated with the creation or</entry></row><row><entry /><entry>availability of the resource. Recommended best practice</entry></row><row><entry /><entry>for encoding the date value is defined in a profile of</entry></row><row><entry /><entry>ISO 8601 and follows the YYYY-MM-DD format.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Type</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Resource Type</entry></row><row><entry>Identifier:</entry><entry>Type</entry></row><row><entry>Definition:</entry><entry>The nature or genre of the content of the resource.</entry></row><row><entry>Comment:</entry><entry>Type includes terms describing general categories,</entry></row><row><entry /><entry>functions, genres, or aggregation levels for content.</entry></row><row><entry /><entry>Recommended best practice is to select a value from a</entry></row><row><entry /><entry>controlled vocabulary (for example, the working draft list</entry></row><row><entry /><entry>of Dublin Core Types).</entry></row><row><entry /><entry>To describe the physical or digital manifestation</entry></row><row><entry /><entry>of the resource, use the FORMAT element.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Format</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry> Name:</entry><entry>Format</entry></row><row><entry>Identifier:</entry><entry>Format</entry></row><row><entry>Definition:</entry><entry>The physical or digital manifestation of the resource.</entry></row><row><entry>Comment:</entry><entry>Typically, Format may include the media-type or</entry></row><row><entry /><entry>dimensions of the resource. Format may be used to</entry></row><row><entry /><entry>determine the software, hardware or other equipment</entry></row><row><entry /><entry>needed to display or operate the resource. Examples of</entry></row><row><entry /><entry>dimensions include size and duration.</entry></row><row><entry /><entry>Recommended best practice is to select a value from a</entry></row><row><entry /><entry>controlled vocabulary (for example, the list of Internet</entry></row><row><entry /><entry>Media Types defining computer media formats).</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Identifier</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Resource Identifier</entry></row><row><entry>Identifier:</entry><entry>Identifier</entry></row><row><entry>Definition:</entry><entry>An unambiguous reference to the resource within a given</entry></row><row><entry /><entry>context.</entry></row><row><entry>Comment:</entry><entry>Recommended best practice is to identify the resource by</entry></row><row><entry /><entry>means of a string or number conforming to a formal</entry></row><row><entry /><entry>identification system.</entry></row><row><entry /><entry>Example formal identification systems include the Uniform</entry></row><row><entry /><entry>Resource Identifier (URI) (including the Uniform Resource</entry></row><row><entry /><entry>Locator (URL)), the Digital Object Identifier (DOI) and the</entry></row><row><entry /><entry>International Standard Book Number (ISBN).</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Source</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Source</entry></row><row><entry>Identifier:</entry><entry>Source</entry></row><row><entry>Definition:</entry><entry>A Reference to a resource from which the present resource</entry></row><row><entry /><entry>is derived.</entry></row><row><entry>Comment:</entry><entry>The present resource may be derived from the Source</entry></row><row><entry /><entry>resource in whole or in part.</entry></row><row><entry /><entry>Recommended best practice is to reference the resource by</entry></row><row><entry /><entry>means of a string or number conforming to a formal</entry></row><row><entry /><entry>identification system.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Language</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Language</entry></row><row><entry>Identifier:</entry><entry>Language</entry></row><row><entry>Definition:</entry><entry>A language of the intellectual content of the resource.</entry></row><row><entry>Comment:</entry><entry>Recommended best practice for the values of the Language</entry></row><row><entry /><entry>element is defined by RFC 1766 which includes</entry></row><row><entry /><entry>a two-letter Language Code (taken from the ISO 639</entry></row><row><entry /><entry>standard), followed optionally, by a two-letter</entry></row><row><entry /><entry>Country Code (taken from the ISO 3166 standard).</entry></row><row><entry /><entry>For example, ‘en’ for English, ‘fr’ for French, or</entry></row><row><entry /><entry>‘en-uk’ for English used in the United Kingdom.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Relation</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry> Name:</entry><entry>Relation</entry></row><row><entry>Identifier:</entry><entry>Relation</entry></row><row><entry>Definition:</entry><entry>A reference to a related resource.</entry></row><row><entry>Comment:</entry><entry>Recommended best practice is to reference the resource by</entry></row><row><entry /><entry>means of a string or number conforming to a formal</entry></row><row><entry /><entry>identification system.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Coverage</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry> Name:</entry><entry>Coverage</entry></row><row><entry>Identifier:</entry><entry>Coverage</entry></row><row><entry>Definition:</entry><entry>The extent or scope of the content of the resource.</entry></row><row><entry>Comment:</entry><entry>Coverage will typically include spatial location (a place</entry></row><row><entry /><entry>name or geographic coordinates), temporal period (a period</entry></row><row><entry /><entry>label, date, or date range) or jurisdiction (such as a named</entry></row><row><entry /><entry>administrative entity).</entry></row><row><entry /><entry>Recommended best practice is to select a value from a</entry></row><row><entry /><entry>controlled vocabulary (for example, the Thesaurus of</entry></row><row><entry /><entry>Geographic Names [TGN]) and that, where appropriate,</entry></row><row><entry /><entry>named places or time periods be used in preference to</entry></row><row><entry /><entry>numeric identifiers such as sets of coordinates or date</entry></row><row><entry /><entry>ranges.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> Element: Rights</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="175pt" align="left" /><tbody valign="top"><row><entry>Name:</entry><entry>Rights Management</entry></row><row><entry>Identifier:</entry><entry>Rights</entry></row><row><entry>Definition:</entry><entry>Information about rights held in and over the resource.</entry></row><row><entry>Comment:</entry><entry>Typically, a Rights element will contain a rights</entry></row><row><entry /><entry>management statement for the resource, or reference</entry></row><row><entry /><entry>a service providing such information. Rights information</entry></row><row><entry /><entry>often encompasses Intellectual Property Rights (IPR),</entry></row><row><entry /><entry>Copyright, and various Property Rights.</entry></row><row><entry /><entry>If the Rights element is absent, no assumptions can be</entry></row><row><entry /><entry>made about the status of these and other rights with respect</entry></row><row><entry /><entry>to the resource.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0041<figref idref="DRAWINGS">FIG. 1</figref> illustrates an overview of the architecture of CMS <b>10</b> in accordance with an aspect of the system. CMS <b>10</b> provides an application program interface (API) <b>10</b><i>a </i>whereby a user uses a CMS Tool UI <b>14</b> on a client computer <b>20</b><i>b </i>to interface with CMS <b>10</b>. The user may have an application that keep operates on content in Application DB <b>13</b>. The user may use a web based interface <b>16</b> to access content maintained by CMS <b>10</b>. Build process <b>18</b> generates content from CMS <b>10</b> to generate a document, web page, etc. for storage in Application DB <b>13</b>. The build process then outputs web pages <b>11</b>, etc. Stored procedures <b>17</b> store and retrieve content in Relational DB Management System <b>12</b><i>a </i>which manages the structured of the content in accordance with aspects of the invention. NTFS <b>15</b> stores various portions of content accessible to the CMS <b>10</b>.

0000Illustrative Computer Network Environment

0042<figref idref="DRAWINGS">FIG. 2</figref> illustrates how the system of <figref idref="DRAWINGS">FIG. 1</figref> may be configured to communicate in a network environment. Here computers <b>20</b><i>a-</i><b>20</b><i>c </i>and <b>21</b><i>a-</i><b>21</b><i>b </i>may host various databases such as databases used in CMS <b>10</b> and Application DB <b>13</b> in accordance with aspects of the present invention. Although the physical environment shows the connected devices as computers, such illustration is merely exemplary and may comprise various digital devices such as PDAs, network appliances, notebook computers, etc.

0043There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wireline or wireless systems, by local networks or widely distributed networks. Currently, many of the networks are coupled to the Internet which provides the infrastructure for widely distributed computing and encompasses many different networks.

0044The Internet commonly refers to the collection of networks and gateways that utilize the TCP/IP suite of protocols, which are well-known in the art of computer networking. TCP/IP is an acronym for “Transport Control Protocol/Interface Program.” The Internet can be described as a system of geographically distributed remote computer networks interconnected by computers executing networking protocols that allow users to interact and share information over the networks. Because of such wide-spread information sharing, remote networks such as the Internet have thus far generally evolved into an “open” system for which developers can design software applications for performing specialized operations or services, essentially without restriction.

0045The network infrastructure enables a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. Thus, in computing, a client is a process (i.e., roughly a set of instructions or tasks) that requests a service provided by another program. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer (i.e., a server). In the example of <figref idref="DRAWINGS">FIG. 2</figref>, computers <b>20</b><i>a-</i><b>20</b><i>c </i>can be thought of as clients and computers <b>21</b><i>a</i>, <b>21</b><i>b </i>can be thought of as servers where server <b>21</b><i>a </i>maintains the data that is then exported for use by the client computer <b>20</b>.

0046A server is typically a remote computer system accessible over a remote network such as the Internet. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.

0047Client and server communicate with one another utilizing the functionality provided by a protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW) or, simply, the “Web.” Typically, a computer network address such as a Universal Resource Locator (URL) or an Internet Protocol (IP) address is used to identify the server or client computers to each other. The network address can be referred to as a Universal Resource Locator address. For example, communication can be provided over a communications medium. In particular, the client and server may be coupled to one another via TCP/IP connections for high-capacity communication.

0048In general, the computer network may comprise both server devices and client devices deployed in a network environment (in a peer-to-peer environment devices may be both clients and servers). <figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary network environment, with server computers in communication with client computers via a network, in which the present invention may be employed. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, a number of servers <b>21</b><i>a</i>, <b>21</b><i>b</i>, etc., are interconnected via a communications network <b>160</b> (which may be a LAN, WAN, intranet or the Internet, or a combination of any of these) with a number of client computers <b>20</b><i>a</i>, <b>20</b><i>b</i>, <b>20</b><i>c</i>, etc. Moreover, communication network <b>160</b> may comprise wireless, wireline, or combination wireless and wireline connections.

0049Thus, the present invention can be utilized in a computer network environment having client computers for accessing and interacting with the network and a server computer for interacting with client computers. However, the systems and methods of the present invention can be implemented with a variety of network-based architectures, and thus should not be limited to the example shown. The present invention will now be described in more detail with reference to an illustrative implementation.

0050<figref idref="DRAWINGS">FIG. 3</figref> illustrates how the content management system applies content units to build various web pages. Web page <b>30</b> comprises a variety of content units that may be reassembled from CMS <b>10</b> in a variety of ways to create web pages for different applications. Web page <b>30</b>, for example, comprises a table of contents <b>302</b>, subtitles and abstracts <b>304</b>, news titles <b>306</b>, and graphics <b>308</b>.

0000Data Model

0051Content normally is expressed mathematically following Named Edge Graph Theory (e.g., title, chapter, paragraph, and so on). Graph Theory is used to express XML and has corollaries to directory structures and content objects—the directory tree for storing content in computers. Graph Theory is much more extensible, allowing more than hierarchical relationships called polyhierarchy, but the allegory is easily grasped.

0052Relational databases such as SQL is based on Set Theory (Unions, Intersections, etc.). SQL is a great scalable storage and retrieval mechanism for set based information. Graph Theory can be expressed in Set Theory by modeling Graph Theory nodes as collections and elements and Graph Theory edges as relationships (relations between collections, relations between elements and relations between collections and elements). The edges (relationships) between nodes (collections and elements) are named. Thus we have named relationships between elements and elements (such as synonym), collections with collections (related vocabularies), and collections and elements (is member). This is also known as a labeled-edge graph.

0053In accordance with an aspect of the invention, a distinction is made between leaf nodes containing content and collections containing only structure. CMS <b>10</b> is implemented with separate entities for content containing elements and structure collections. This is done primary for performance. Preferably, the edge relationships are named but not enumerated.

0054<figref idref="DRAWINGS">FIG. 4</figref> Illustrates how the present invention converts a graph structure library, book, or document, e.g., represented by table of contents <b>45</b>, into relational tables, e.g., <b>41</b>, <b>42</b>. The table of contents <b>45</b> can be represented by graph <b>48</b>. Graph <b>48</b> is represented by a collection of nodes, e.g., <b>48</b><i>a</i>, <b>48</b><i>b</i>, etc. The nodes, e.g., <b>48</b><i>a</i>, <b>48</b><i>b </i>correspond to content and structure in from the structured table of contents <b>45</b>. Here, root node <b>45</b> corresponds to MSDN Library in table of contents <b>45</b>. Other titles in the table of contents <b>45</b> will also be represented by nodes in graph <b>48</b>. The relationship of titles in the table of contents <b>45</b> can be represented by edges in graph <b>48</b>, e.g., edges <b>47</b><i>a</i>, <b>47</b><i>b. </i>

0000Simple Content Subject Graph

0055<figref idref="DRAWINGS">FIG. 5A</figref> presents a simple subject graph <b>502</b> that further illustrates aspects of the invention. Rendered in XML this Simple Subject graph is:

0056<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><productoverview></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="28pt" align="left" /><colspec colname="1" colwidth="189pt" align="left" /><tbody valign="top"><row><entry /><entry> <title></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="14pt" align="left" /><colspec colname="1" colwidth="203pt" align="left" /><tbody valign="top"><row><entry /><entry>The Windows 2000 Implementation Strategy for the United Kingdom</entry></row><row><entry /><entry></title></entry></row><row><entry /><entry><author></entry></row><row><entry /><entry>John Smith</entry></row><row><entry /><entry></author></entry></row><row><entry /><entry><product></entry></row><row><entry /><entry>Windows 2000</entry></row><row><entry /><entry></product></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> </productoverview></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0057Well formed XML has matching markups and follows the rules of XML creation. A valid XML has an XML-Schema (XSD) and conforms to that XML-Schema (XSD). The XML-Schema for the example is:

0058<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><thead><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry></entry></row><row><entry><Schema name=“productoverview”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry>xmlns=“urn:schemas-microsoft-com:xml-data”</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="182pt" align="left" /><tbody valign="top"><row><entry /><entry>xmlns:dt=“urn:schemas-microsoft-</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry>com:datatypes”></entry></row><row><entry> <!−− . . . −−></entry></row><row><entry><ElementType name= “productoverview” content=“eltOnly”></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry> <element type=“title”/></entry></row><row><entry /><entry><element type= “author”/></entry></row><row><entry /><entry><element type= “product”/></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> </ElementType></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry> <ElementType name= “title” content=‘textOnly’ order=“one”/></entry></row><row><entry /><entry><ElementType name= “author” content=‘textOnly’</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> order=“one”/></entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="offset" colwidth="21pt" align="left" /><colspec colname="1" colwidth="196pt" align="left" /><tbody valign="top"><row><entry /><entry> <ElementType name= “product” content=‘textOnly’</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="left" /><tbody valign="top"><row><entry> order=“one”/></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0059XML attributes of an XML element can be expressed as either XML elements or XML attributes of the elements. The decision on which to use is made on the concept of future node use. It is easier to break down elements into future element structures than it is to change XML element attributes into XML elements. If no further breakdown is anticipated then attribution is acceptable. XML element definition can be used exclusively and is potentially more flexible in the future.

0060Expressing the XML graph in a relational data model maps the XML attributes as data model attributes (or sometimes called properties—physically modeled as the columns in the SQL table) of the data model entities (set theory).

0061CMS <b>10</b> is preferably implemented with a distinction between leaf nodes containing information and structure nodes (collections).

0062Container/Leaf Structure <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0063">The container/leaf structure and the actual chunking structure (separate data files) are parallel but orthogonal.</li><li id="ul0006-0002" num="0064">All chunks are containers or leafs, but not all containers or leafs are chunks (chunks contain sub-trees possibly).</li><li id="ul0006-0003" num="0065">Chunks are checked-in/out and versioned, nodes are shared and referenced by version.</li><li id="ul0006-0004" num="0066">Each chunk must be branch-versioned or at least linearly versioned.</li><li id="ul0006-0005" num="0067">Each container can contain:</li><li id="ul0006-0006" num="0068">Children who are distinct chunks (i.e., they are separate files):</li><li id="ul0006-0007" num="0069">As un-sequenced, un-positioned sibling chunks (like a file system or VSS does, where everyone seems like an equal-level child).</li><li id="ul0006-0008" num="0070">As sequenced, un-positioned sibling chunks (order is indicated and preserved presumably by the CMS internal per-container children list).</li><li id="ul0006-0009" num="0071">Children who are not distinct chunks (i.e., they are part of the same chunk as the parent container node).</li><li id="ul0006-0010" num="0072">As sequenced, positioned sibling nodes (order and position is indicated and preserved within the container's content).</li><li id="ul0006-0011" num="0073">Node-to-node referential integrity and counts are preferably tracked and maintained by CMS <b>10</b>.</li><li id="ul0006-0012" num="0074">Chunks of structured elements (say, XML files) may only expose particular container or leaf elements as addressable for CMS purposes.</li><li id="ul0006-0013" num="0075">Any CMS-aware node (whether it begins a chunk or is itself inside of a chunk) have a CMS-aware ID unique in the namespace of its container node.</li><li id="ul0006-0014" num="0076">The children of a container have unique IDs relative to the container's namespace.</li><li id="ul0006-0015" num="0077">Uniquely addressing a node and desired version from an ancestor scope can always be expressed (preferably by using all the ancestor IDs in some way).</li></ul></li></ul>

0078As illustrated in <figref idref="DRAWINGS">FIG. 5B</figref>, content <b>504</b> is attributed with various terms to indicate content subject <b>506</b>. Content carries metadata and relationships as well as key values pairs <b>508</b> for attribution. As shown in the entity relationship diagram of <figref idref="DRAWINGS">FIG. 5C</figref>, the content or resource instance is attributed by converting the resource graph into set theory by placing the resource instance (DR_Content) <b>52</b> and attribute instance (DR_Attribute) <b>56</b> into SQL tables. The labeled edge becomes a many to many relationship table (DR_ContentAttribute) <b>54</b>. The content associations can be extended to include tree structure that forms the basis of the Table of Contents (TOC). The structure or tree (root, node and leaf) is represented in CMS <b>10</b> as separate and distinct tables from the content entity. The tree structure begins with a root element and constructs labeled edge relationships with nodes. The end node or leaf is a relationship to content. Entities can be thought of as “files” and Structure can be thought of as “directories”. Structure can also occur within documents—with introductory paragraph, body paragraph etc. The structure node is typed with a “document” to note the leaf node of the TOC navigation structure and the “root” node of the document structure. This makes explicit the distinction between bounded “internal” structure and unbounded “external” structure.

0000Structure Entity Relationship Model

0079As shown in <figref idref="DRAWINGS">FIG. 5D</figref>, the tree structure graph nodes are represented as Nodes. The labeled edge forms a many to many relationship entity (DR_Branch) <b>51</b> and is labeled with a Branch Type <b>53</b>. Note that the Node entity is used twice <b>50</b><i>a</i>, <b>50</b><i>b</i>, and thus collapses into a single entity used twice in the relationship (Branch) as shown in FIG. <b>5</b>E. The Node entity is used for both nodes of the graph.

0000Content Ownership

0080Content also has a notion of ownership. The ownership of content can be represented in graph form as shown in FIG. <b>5</b>F. For example, certain content in the directed graph <b>550</b> including TechNet <b>556</b>, MSDN <b>554</b>, and BDM <b>552</b> is owned by slevy <b>546</b>, amyi <b>544</b>, and tpetras <b>542</b>. All of this is owned by RPU <b>532</b>, which is in turn owned by kimsau <b>522</b>.

0000Entity Relationship Model

0081The three graphs: Owner, Structure and Content have different properties. The owner entity does not carry the Dublin core properties. Structure and Content have different relationships and some properties not in common. Content carries a relationship to content data, format and status that structure does not. All three graphs can be represented by a single ER model as shown in <figref idref="DRAWINGS">FIG. 5G.0</figref>

0082Attributes (DR_Attributes) <b>56</b> are grouped in sets (DR_AttributeSet) <b>562</b> and sets are grouped in Attribute groups (DR_AttributeGroup) <b>564</b>.

0083The content entity is extended by recognizing content versions. The actual content data is related to the content version. A content type is extended and relates to structure as well. A status is applied to version.

0084The Content Entity (DR_Content) <b>52</b> is related to an Owner (DR_Owner) <b>533</b> and the status (Dr_ContentStatus).

0000Entity Model Glossary

0085The entities and relationships of the ER diagram of <figref idref="DRAWINGS">FIG. 5G</figref> is further described below:

0086Resource Instance Cluster

0087Resource: An resource is a unit of Knowledge Management, a content item. Download Overviews, KB Articles and Book Overviews all represent objects.

0088DR_Content <b>52</b><ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0089">The instance of a content objects metadata.</li><li id="ul0008-0002" num="0090">A resource has a GUID or ID.</li><li id="ul0008-0003" num="0091">Resource Instance, two states: a resource URI—images, streaming media, etc., or a piece of ACCII text. As a metaphor consider that node makes up the card in a library card catalog, the content entity is like the ISBN of the book.</li><li id="ul0008-0004" num="0092">When content can be instantiated as text, the content is stored in the Content column. Otherwise, for binary, graphics, and unstructured content the content is stored in HTFS files and referenced by URI.</li></ul></li></ul>

0093Resource Attribution Cluster <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0094">In bound attributes are exposed, unbound attributes are not exposed. Bound attributes are expressed in the form of: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0095"><Key group=“VSIA” name=“devlang” value=“C#”/></li></ul></li></ul></li></ul>

0096DR_Attributes <b>56</b><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0000"><ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0097">The attribute entity is the subject associations of related content and node entities. It is a key value pair name space token. Key space is global such as source name. This would exclude things like ratings since they are not content. Attributes are vocabulary terms; the individual elements in a vocabulary. An individual word or phrase in a vocabulary can be related to other terms, i.e. WINDOWS 2000, SQL SERVER 2000, OFFICE 10, EXCHANGE 2000, Powerpoint 2000.</li></ul></li></ul>

0098DR_AttributeSet <b>562</b><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0000"><ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0099">The vocabulary or set of attribute values comprise a collection of words or phrases in a list. These can be arranged and explained or defined as a hierarchy. A vocabulary may be controlled or not. A vocabulary represents the set of attribute values that make up an enumerated list.</li></ul></li></ul>

0100DR_AttributeGroup <b>564</b><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0000"><ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0101">The group or “Owner” of vocabulary set. For example, VSIA, MSDN act as a domain boundary which allows multiple taxonomies to be used.</li></ul></li></ul>

0102DR_ContentAttribute <b>54</b><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0000"><ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0103">The relationships between the Content Entity (Subject) and Attributes.</li></ul></li></ul>

0104DR_NodeAttribute <b>512</b><ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0000"><ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0105">The relationships between Node Entity (Structure) and attributes.</li></ul></li></ul>

0106Resource Tree Structure Cluster

0107DR_Node <b>50</b><ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0000"><ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0108">A structure graph node is used as the collection node and leaf node: like the file system, the directory, a collection. It is separated from the content entity for ease of use. Structure never has content. Different kinds of structure exist. A structure leaf is related to a Content Entity. A leaf node, as different from a collection or branch node which are Structural Entities.</li></ul></li></ul>

0109DR_Branch <b>51</b><ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0000"><ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0110">The parent child relationship between nodes forming a structure tree.</li></ul></li></ul>

0111DR_BranchType <b>53</b><ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0000"><ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0112">This entity represents the kind of structure, or hierarchy—like a tree presentation. It represents the label of the edge and indicated dependencies between nodes.</li></ul></li></ul>

0113DR_NodeNode <b>505</b><ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0000"><ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0114">This entity forms the relationship between nodes, and is not part of a structure tree. This allows branch to allow attribute inheritance. NodeNode relation allows attribution that is not inherited or bubbled up to the root.</li></ul></li></ul>

0115DR_NodeContent <b>510</b><ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0000"><ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0116">This entity represents the relationship between a node and content.</li></ul></li></ul>

0117Resource Owner Cluster

0118DR_Owner <b>533</b><ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0000"><ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0119">This entity represents the organization graph node of the organization tree. It is used as a collection or leaf node. It is used as the owner of content and structure trees.</li></ul></li></ul>

0120DR_OwnerOwner <b>523</b><ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0000"><ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0121">This entity represents the parent child relationship between owner nodes forming an organization tree.</li></ul></li></ul>

0122<figref idref="DRAWINGS">FIG. 6</figref> further illustrates the data model in accordance with the present invention by providing a database schema wherein content in the form of a graph structure in converted into and stored as a relational model wherein it can be accessed, searched and manipulated by a database management system.

0123With reference to <figref idref="DRAWINGS">FIG. 7</figref>, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer <b>110</b> that could form a portion of client computer <b>20</b><i>a-</i><b>20</b><i>c </i>or server computers <b>21</b><i>a</i>, <b>21</b><i>b </i>(see FIG. <b>1</b>). Components of computer <b>110</b> may include, but are not limited to, a processing unit <b>120</b>, a system memory <b>130</b>, and a system bus <b>121</b> that couples various system components including the system memory to the processing unit <b>120</b>. The system bus <b>121</b> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as Mezzanine bus).

0124Computer <b>110</b> typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer <b>110</b> and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by computer <b>110</b>. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

0125The system memory <b>130</b> includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) <b>131</b> and random access memory (RAM) <b>132</b>. A basic input/output system <b>133</b> (BIOS), containing the basic routines that help to transfer information between elements within computer <b>110</b>, such as during start-up, is typically stored in ROM <b>131</b>. RAM <b>132</b> typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit <b>120</b>. By way of example, and not limitation, <figref idref="DRAWINGS">FIG. 7</figref> illustrates operating system <b>134</b>, application programs <b>135</b>, other program modules <b>136</b>, and program data <b>137</b>.

0126Computer <b>110</b> may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, <figref idref="DRAWINGS">FIG. 7</figref> illustrates a hard disk drive <b>141</b> that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive <b>151</b> that reads from or writes to a removable, nonvolatile magnetic disk <b>152</b>, and an optical disk drive <b>155</b> that reads from or writes to a removable, nonvolatile optical disk <b>156</b>, such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive <b>141</b> is typically connected to the system bus <b>121</b> through an non-removable memory interface such as interface <b>140</b>, and magnetic disk drive <b>151</b> and optical disk drive <b>155</b> are typically connected to the system bus <b>121</b> by a removable memory interface, such as interface <b>150</b>.

0127The drives and their associated computer storage media discussed above and illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, provide storage of computer readable instructions, data structures, program modules and other data for the computer <b>110</b>. In <figref idref="DRAWINGS">FIG. 7</figref>, for example, hard disk drive <b>141</b> is illustrated as storing operating system <b>144</b>, application programs <b>145</b>, other program modules <b>146</b>, and program data <b>147</b>. Note that these components can either be the same as or different from operating system <b>134</b>, application programs <b>135</b>, other program modules <b>136</b>, and program data <b>137</b>. Operating system <b>144</b>, application programs <b>145</b>, other program modules <b>146</b>, and program data <b>147</b> are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer <b>110</b> through input devices such as a keyboard <b>162</b> and pointing device <b>161</b>, commonly referred to as a mouse, trackball or touch pad. Other input devices may include a microphone <b>163</b>, joystick, game pad, satellite dish, scanner, or the like (not shown). These and other input devices are often connected to the processing unit <b>120</b> through a user input interface <b>160</b> that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor <b>191</b> or other type of display device is also connected to the system bus <b>121</b> via an interface, such as a video interface <b>190</b>. In addition to the monitor, computers may also include other peripheral output devices such as speakers <b>197</b> and printer <b>196</b>, which may be connected through an output peripheral interface <b>195</b>.

0128The computer <b>110</b> may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer <b>180</b>. The remote computer <b>180</b> may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <b>110</b>, although only a memory storage device <b>181</b> has been illustrated in FIG. <b>7</b>. The logical connections depicted in <figref idref="DRAWINGS">FIG. 7</figref> include a local area network (LAN) <b>171</b> and a wide area network (WAN) <b>173</b>, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

0129When used in a LAN networking environment, the computer <b>110</b> is connected to the LAN <b>171</b> through a network interface or adapter <b>170</b>. When used in a WAN networking environment, the computer <b>110</b> typically includes a modem <b>172</b> or other means for establishing communications over the WAN <b>173</b>, such as the Internet. The modem <b>172</b>, which may be internal or external, may be connected to the system bus <b>121</b> via the user input interface <b>160</b>, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer <b>110</b>, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, <figref idref="DRAWINGS">FIG. 7</figref> illustrates remote application programs <b>185</b> as residing on memory device <b>181</b>. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

0130The various techniques described herein may be implemented with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. In the case of program code execution on programmable computers, the computer will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs are preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

0131The methods and apparatus of the present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, a video recorder or the like, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to perform the indexing functionality of the present invention.

0132While the present invention has been described in connection with the preferred embodiments of the various figures, it is to be understood that other similar embodiments may be used or modifications and additions may be made to the described embodiment for performing the same function of the present invention without deviating there from. Therefore, the present invention should not be limited to any single embodiment, but rather construed in breadth and scope in accordance with the appended claims.