Patent Publication Number: US-7725454-B2

Title: Indexing and searching of information including handler chaining

Description:
RELATED APPLICATIONS 
   This application is related to U.S. patent application Ser. No. 11,880,331, filed Jul. 20, 2007, and entitled, “HETEROGENEOUS CONTENT INDEXING AND SEARCHING,” which is hereby incorporated by reference in its entirety. 
   COPYRIGHT NOTICE 
   A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or patent disclosure as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
   BACKGROUND 
   Computer users have different ways to locate files and other information that may be locally or remotely stored. For example, some operating systems include built-in search wizards that can be used to locate files using keywords and other user input. However, some existing built-in search wizards can be slow and time consuming when performing searches, which can ultimately result in an unsatisfactory user experience. A user may have to abort a search before obtaining any relevant search results adding further inefficiency and dissatisfaction. 
   Some searching applications use indexing methods to index certain files, using the indexed information when responding to search requests. Indexing is used in efforts to quickly and efficiently return search results. However, many of the current applications are not properly configured to handle cases in which new file types and formats are being created and added to a system. In some cases, a new add-on can be created and introduced to the system to operate with a certain file format. Unfortunately, the creation process can require a large amount of time and learning, and often needs to be repeated for each new file type or format being introduced to a computing environment. 
   SUMMARY 
   This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended as an aid in determining the scope of the claimed subject matter. 
   Embodiments are provided to manage information associated with a number of disparate information sources. In an embodiment, an extensible system is configured to use metadata and other information as part of an indexing operation. The system includes a handler that is configured to extract, filter, or otherwise assess metadata and other information that can be associated with a number of disparate information sources. In one embodiment, a number of handlers can be chained together to extract and return information according to a desired mode of operation. 
   These and other features and advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. It is to be understood that both the foregoing general description and the following detailed description are explanatory only and are not restrictive of the invention as claimed. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  depicts a block diagram of a system configured to manage information. 
       FIG. 2  depicts a block diagram of a system configured to manage information. 
       FIG. 3  is a flow diagram illustrating an indexing process. 
       FIG. 4  depicts a block diagram of a system configured to manage information. 
       FIG. 5  depicts a block diagram of a system configured to manage information. 
       FIG. 6  is a flow diagram illustrating an indexing process. 
       FIG. 7  is a block diagram illustrating a computing environment for implementation of various embodiments described herein. 
   

   DETAILED DESCRIPTION 
   Embodiments are provided to manage information associated with a number of disparate information sources. In an embodiment, an extensible system includes a handler configured to communicate metadata and other information as part of an indexing operation. The handler can operate to extract, filter, or otherwise assess metadata and other information associated with an information source which can be defined to include a uniform representation of metadata, but is not so limited. 
   In an embodiment, a system includes a metadata handler configured to extract metadata and free-form text from a data structure. The data structure can be configured to provide a uniform representation of metadata. The metadata and free-form text can be associated with underlying files or other information sources that can include varying formats, properties, and/or parameters. In one embodiment, a system includes a metadata handler that is configured to invoke a second handler as part of an indexing operation. The second handler can be associated with an underlying information source. The second handler can be used to extract metadata from the underlying information source and return the extracted metadata to the metadata handler. Thereafter, the metadata handler can return extracted metadata and/or free-form text based in part on a mode of operation setting. 
     FIG. 1  is a block diagram of a system  100  configured to manage information, under an embodiment. As described below, the system  100  includes indexing and searching functionality which includes the use of metadata and other information that is associated with a number of disparate information sources. For example, the system  100  can be used to manage a number of files, file locations, and other information. In one embodiment, the system  100  can be configured to monitor a number of file locations, such as areas of a hard disk for example, and index information associated with the file locations, including metadata and/or other content of the files associated therewith. For example, the system  100  can be configured as a search engine which can operate to index information associated with file locations, files, and other data. 
   As shown in  FIG. 1 , the system  100  includes an index component  102  that is configured to use metadata, content, and other information to provide an efficient indexing of information that may be associated with files, file content, virtual content, etc. In one embodiment, the index component  102  can be configured to provide indexing features as part of a search engine&#39;s functionality based in part on various intrinsic properties, such as file name, file path, metadata (e.g., creation date, modified date, author, etc.), and/or various extrinsic properties, such as comments and textual content of a file for example. 
   The index component  102  can use extracted information associated with a number of files or other informational sources to construct an indexed catalog to facilitate efficient and rapid searching. For example, the index component  102  can use text, property information, and metadata extracted from locally stored files and/or remotely networked files when indexing. In one embodiment, the index component  102  is configured to interact with a file system, virtual web, network, or other informational source when indexing according to a desired implementation. 
   In an embodiment, the index component  102  is configured to monitor certain folders, files, memory locations, or other information sources. Once a file, application, or other informational or data construct has been modified or created, the index component  102  can operate to ascertain identification information associated with the modified or created file, application, or other informational or data construct. For example, if a new file is shown to exist as part of the monitoring process, the index component  102  can operate to determine the new file&#39;s extension. According to one embodiment, if the extension is associated with a particular file (e.g., a metadata definition document (MDD) file), the index component  102  looks at its registry and uses a handler  104  (described below) to interact with the particular file. 
   Accordingly, the handler  104  can be registered with the system  100  for a particular file, such an MDD file for example, or for a number of files or other information sources. For example, a metadata IFilter can be registered with a desktop search engine for a particular file format. As described further below, an MDD file can be created based on an underlying or primary information source, such as a document file, image file, video, file, audio file, virtual information source, etc. That is, the MDD file can store information, including metadata, associated with an underlying information source. In one embodiment, an MDD file is configured to provide a uniform representation of metadata and/or full-text search (FTS) data for any type of file format, including non-file formats. 
   With continuing reference to  FIG. 1 , and as described briefly above, the system  100  includes a handler  104 . The handler  104  can be configured to interact with any type of metadata and is not limited to handling pre-defined types of metadata. In one embodiment, the handler  104  operates to interact with a file having an extensible markup language (XML) file format which identifies metadata using name-value pairs. Correspondingly, the handler  104  can use the name-value pair metadata descriptors as part of an indexing process. The handler  104  can be configured to extract metadata, content, properties, and/or other information associated with a number of file-based, non-file-based, or other information sources  106   a - 106   i  (where “i” is an integer). 
   The handler  104  is configured with filtering functionality and can operate to filter information associated with an information source. For example, the handler  104  can operate to extract metadata from a file or a secondary data stream (e.g., NTFS stream) associated with a file or other data source. In one embodiment, the handler  104  is configured as a metadata IFilter including the associated interface to extract information from a uniform data structure that includes metadata that is associated with an underlying information source  106   a - 106   i . The information sources  106   a - 106   i  can also include new files with new file formats and/or pre-existing files having known file formats. 
   The handler  104  can be configured to locate, assess, and extract metadata, content, and/or other information (depicted as blocks  108   a - 108   i  in  FIG. 1 ) associated with the number of files  106   a - 106   i . In one embodiment, the metadata, content, and/or other information (depicted as blocks  108   a - 108   i ) can be associated with a number of secondary files, referred to as MDD files herein. In an alternative embodiment, all, or select portions, of the extracted metadata, content, and/or other information (depicted as blocks  108   a - 108   i ) can be stored in a single container, file, or other data storage. 
   In one embodiment, the handler  104  can be included as part of the functionality of an assistance application, such as an indexing and searching system. For example, the handler  104  can be used when indexing information stored in a data storage medium, and the indexed information can then be used as part of rich searching operations. The handler  104  can be used to assess metadata associated with file content, non-file based content, virtual content, and other types of information. 
   For example, metadata may be added or associated with information, irrespective of the content-type. In one embodiment, the handler  104  can be included as part of the functionality of an assistance application, such as a desktop search engine for example, and can be used to examine a number of information sources, including a number of secondary data streams associated with a number of content-based files. The handler  104  can be configured to access the secondary stream and extract any associated metadata for use in indexing and searching operations. Multiple metadata streams can be used to describe different application and other associations. 
   As shown in  FIG. 1 , the system also includes a schema handler  110  in communication with the handler  104  and the index component  102 . The schema handler  110  includes mapping functionality to provide a mapping interface between the handler  104  and index component  102 , but is not so limited. In an alternative embodiment, the schema handler  110  can be included as part of the functionality of the handler  104 . In another alternative embodiment, the schema handler  110  can be included as part of the functionality of the index component  102 . In one embodiment, the schema handler  110  can be configured to map generic metadata to a metadata field that is understood by the index component  102  and/or associated search engine. Accordingly, the schema handler  110  can operate to map from a first metadata schema to a database metadata schema, generic metadata schema, application-specific metadata schema, or some other schema implementation. 
   For example, the schema handler  110  may be used with a pre-existing database where it may be cumbersome and inefficient to alter the database schema. As another example, an application may need changing or tweaking over time for various reasons and, as a result, a different schema may need to be introduced. As further example, the schema handler  110  can be used in situations where an application might use different “friendly” or language-specific names for metadata that it exposes to a user. A data-driven schema provides flexibility to change the schema and/or the mapping without changing code, thereby providing an extensible application. For example, name-value pairs can be used to define new metadata for different purposes, thereby providing extensible features to the system  100 . 
   As described above, the index component  102  can use the handler  104  to extract and/or return metadata, content, and/or other information for use by the index component  102  and/or other components. The handler  104  can operate with a unified representation of metadata, as described below. For example, the handler  104  can be configured to interact with one or more files having a particular file format that include metadata and associated parameters that are not constrained by the underlying content. The handler  104  can operate to track and return any metadata and/or content to a search engine, an indexing engine, and/or other desired component. 
   Correspondingly, the index component  102  can use the handler  104  to capture metadata, content, and/or other information associated with an informational source or sources. The index component  102  can use the metadata, content, and/or other information for indexing against the information source or sources, such as a number of disparate file types. Thereafter, the informational source or information associated therewith can be located upon searching on the metadata, content, and/or other information. Accordingly, the index component  102  can use the handler  104  as part of indexing and/or searching operations. In one embodiment, the handler  104  provides a mechanism to unify the representation of metadata for any file format, and provides the associated metadata for use in indexing and/or searching. 
   In one embodiment, an indexing service can use the handler  104 , in the form of a metadata IFilter for example, as an interface to interact with different types of files and/or other information sources (e.g., NFTS streams, etc.). The handler  104  can extract metadata, textual information, contextual information, properties, etc. for inclusion as part of an index associated with the indexing service. The index can be queried to locate desired information associated with the extracted metadata, textual information, contextual information, properties, etc. In another embodiment, the handler  104  can be configured as a dynamic-link library (DLL) that includes an implementation of a metadata IFilter for a specific class of files and/or data streams. 
     FIG. 2  is a block diagram depicting a system  200  that is configured to manage information, in accordance with an embodiment. As shown in  FIG. 2 , and for illustrative purposes, the schema handler  202  can operate to map a first schema type to a second schema type associated with a database component  204  or other storage component. For example, the schema handler  202  can be used to map application-specific metadata schema to a database metadata schema. Correspondingly, a metadata handler  206  (or data access layer) can use the schema handler  202  to map a first schema type to a second schema type associated with the database component  204 . For example, the schema handler  202  can be used as part of an Assistance Platform rich client and the WINDOWS Desktop Search (WDS) database. 
   According to this embodiment, the schema handler  202  uses an xml-mapping file  208  as part of a mapping process, to thereby provide a data-driven mapping functionality, to map the first schema metadata to the second schema metadata. In one embodiment, the xml-mapping file  208  is a configuration file which includes an array of elements which describe the mapping for certain metadata. For example, the mapping for particular metadata can consist of the following elements: a) a first schema metadata name (e.g., AP) which is a standardized or friendly name which needs to be mapped; b) a second metadata name (e.g., WDS, IS, etc.) which is the name of the metadata in the database (e.g., the database associated with WDS); and, c) the type of the metadata (e.g., string, integer, multi-valued, etc.). In addition to the above array of mapping elements, the xml-mapping file  208  can also include a “catchall” mapping element which is used to map an unspecified first schema metadata to a multi-valued metadata form in the database component  204 . 
   As an example, the schema handler  202  can be used when using the metadata handler  206  as part of a content-based indexing operation. During the content indexing process, the metadata handler  206  receives an MDD file as an input. The MDD file references names associated with first metadata schema. To ensure correct indexing of the associated content, the first metadata schema (e.g., AP schema metadata) can be mapped to the second metadata schema (e.g., WDS schema metadata). Accordingly, the metadata handler  206  (e.g., metadata IFilter) uses the schema handler  202  to map the AP schema metadata names found in the MDD file to the appropriate metadata names associated with the WDS. 
   As another example, the schema handler  202  can be used as part of a searching and content retrieval process. In order to perform a search query over the database component  204 , any metadata associated with the first schema query needs to be mapped to the metadata names of the second schema. Similarly, any metadata referenced in the search results need to be converted to the metadata names of the first schema. In order to obtain the correct metadata name, a data access layer or other component can use the schema handler  202  to perform the mapping operation. 
     FIG. 3  is a flow diagram illustrating a process of managing information, in accordance with an embodiment. Components of  FIG. 1  are used in the description of  FIG. 3 , but the embodiment is not so limited. At  300 , the index component  102  is monitoring an information source  106   i . For example, the index component  102  may be monitoring a local hard disk, file system, folder(s), database, remote information source, or other data source. At  302 , the index component  102  can operate to use the handler  104  to extract metadata, content, and/or other information from a select information source  106   i . The index component  102  can refer to a persistent handler or GUID when calling the handler  104 . For example, the index component  102  can call the handler  104  to extract metadata from a new or recently updated MDD file (described in detail below). 
   To simplify the discussion of  FIG. 3 , it is assumed that metadata has been extracted from an information source using the handler  104 . After using the handler  104  to extract metadata from the information source  1061 , the handler  104  invokes the schema handler  110  if there is a need to map the extracted metadata from a first metadata schema to a second metadata schema. For example, the schema handler  110  can be used to map from an application-specific metadata schema used by the information source  106   i , to a metadata schema as understood by the index component  102 . 
   If mapping is required at  304 , the schema handler  110  is used to map the metadata from a first metadata schema to a second metadata schema at  306  and the flow proceeds to  308 . If mapping is not required at  304 , the flow proceeds to  308  and the metadata is returned to the index component  102  for further processing. At  310 , the index component  102  operates to index the metadata as part of an indexing operation and associate this metadata with the information source  106   i . Thereafter, the indexed metadata can be used to locate information associated with information source  106   i  as part of a search. For example, the system  100  can operate to invoke a particular application based on the location, name, etc. of an underlying file or other information source that is associated with an MDD file. 
     FIG. 4  is a block diagram of a system  400  configured to manage information, in accordance with an embodiment. Components of the system  400  can be configured to provide a representation of metadata that can be used as part of a heterogeneous indexing and/or a searching functionality. As shown in  FIG. 4 , the system  400  includes an indexer  402  that is configured to use metadata, in part, to provide an efficient indexing of information, such as a files, file content, metadata, etc. 
   The indexer  402  can use metadata and other information associated with a number of files  404  and  406 , and other information source  408  to construct an indexed catalog to facilitate efficient and rapid searching. For example, the indexer  402  can use metadata extracted from locally stored files and/or remotely networked files when indexing. The embodiment is not so limited, but to provide an illustrative example of the functionality of the system  400 , the files  404  and  406 , and the information source  408  are depicted as particular types. However, the system  400  can interact with any number of files and/or other information sources. Moreover, the files and other information sources may be associated with another system, whether local or remote. 
   As described below, metadata can be associated with the files  404 - 406 , and the information source  408 , and stored according to a generic schema such that a single metadata handler can be used to interact with the associated metadata. As shown, block  404  corresponds with a document file (SAMPLE1.DOC). Block  410  depicts a corresponding MDD file (SAMPLE1.MDD) which includes the metadata and/or full-text associated with the document file. As described above, the metadata included in the MDD file is not constrained by the underlying format of the document file. Rather, each MDD file includes a data structure or format that enables the metadata handler  416  to extract or otherwise determine the metadata and other information associated therewith. Correspondingly, the metadata handler  416  can operate to indirectly interact with a number of associated information sources. 
   File  406  corresponds to a newly created file having a new type of format (SAMPLE2.FOO). Block  412  depicts a corresponding MDD file (SAMPLE2.MDD) which includes the metadata and/or full-text associated with the new file. Again, the metadata included in the MDD file is not constrained by the underlying format of the new file. Information source  408  corresponds with website URL (SAMPLE3.COM). Block  414  is a corresponding MDD file (SAMPLE3.MDD) which includes metadata associated with the website. Accordingly, the metadata included in the MDD file is not constrained by the fact that the underlying information source  408  is a website. 
   Due in part to the characteristics of the metadata handler  416 , such as a metadata IFilter for example, and the MDD files, metadata and/or other information associated with each MDD file can be extracted therefrom or otherwise accessed. The extracted metadata and/or other information can be communicated to the indexer  402  for indexing purposes against the blocks  410 ,  412 , and  414 , files  404 - 406 , and the information source  408 . In one embodiment, the metadata handler  416  can be configured as an IFilter interface for interacting with an MDD file and/or a data stream associated with an underlying content-based or other type of file. 
   In an embodiment, one or more of the MDD files can be stored with or as part of an associated content file. In another embodiment, the metadata, content, and other information can be stored in the same file, in different files, or in different file combinations. Each MDD file can include properties to identify the file or informational source that is associated with the metadata. For example, an MDD file can include keywords, file name, author, file type, path, location(s), creation/modification/review date(s), size, binary information, language, custom properties, read/write permissions, and/or other information. In one embodiment, an MDD file can be created by an application configured to create a file having a certain file format and characteristics according to a defined schema. 
   An MDD file can be used to represent any file format, including existing and new file formats, data structures, or other constructs. For example, an MDD file can be associated with an image file, a document, spreadsheet, blog, uniform resource locator (URL), hyperlink, website, etc. An authoring tool, publishing tool, general purpose creation tool, etc. can be used to create an MDD file. In one embodiment, an application can automatically create an MDD based on an underlying file or other information source. A desired tool can be used to extract metadata from an associated file, application, or other informational or data construct when creating the MDD file. 
   For example, a metadata extraction tool can be used to create MDD files for document files, spreadsheet files, image files, video files, etc. The tool can be configured to extract metadata, content, and/or other information and publish the same as part of an MDD file. The system  400  can also include functionality to automatically create MDD files by using a sampling tool to extract metadata, content, and/or other information from a file, application, etc. and publish the same as part of an MDD file. As shown below, in one embodiment, a schema can be used to create MDD files using an extensible markup language (XML). Once an MDD file has been identified and/or located, the metadata handler  408  is configured to assess the metadata, content, and/or other information associated therewith for further operations and/or implementations. 
   Correspondingly, MDD files can be created in various ways and are not intended to be limited to any particular creation mechanism. In one embodiment, an MDD file can be created based in part on an existing metadata-embedded file. To create an MDD file from an existing metadata-embedded file, an associated IFilter for the file can be used to extract the metadata from the existing metadata-embedded file. For instance, a document IFilter can be used to extract metadata from a document file (e.g., .doc, .docx, etc.) when creating an MDD file to be associated with the document file. Code can be written to invoke the document IFilter which extracts metadata and/or full-text search (FTS) data from the document. The code can then create the MDD file associated with the document file including any relevant metadata and FTS data. 
   In another embodiment, an MDD file can be created using an authoring and publishing system. Such an embodiment can be used to create MDD files when integrated with authoring and publishing systems. An authoring and publishing system is designed to publish an “asset” to an online server, such as a runtime server for example, where assets are aggregated for search and content retrieval. An MDD adapter can be configured to extract metadata from an asset and any FTS data from the asset&#39;s associated content when creating an MDD file. 
   In yet another embodiment, an MDD file can be authored by using an authoring or other tool. A user can author an MDD file when the associated content is non-file based content, such as for a website for example. For example, a user can create an MDD file that includes annotations, keywords, notes, etc. stored as metadata and associated with a .pdf file. The MDD file can be authored as an XML file which can be created with user-specified metadata using a text editor, such as notepad for example. The metadata handler  416  can then operate to extract the metadata from the MDD file for indexing and/or searching operations. 
   An example schema corresponding to an MDD file is shown below. As shown, the schema is configured to be independent of content-type (virtual, file-based, etc), and can be used to describe metadata for heterogeneous content-types. The schema can include the following: 
   
     
       
         
             
           
             
                 
             
           
          
             
                   &lt;?xml version=“1.0” encoding=“utf-16”?&gt; 
             
             
                   &lt;xs:schema         attributeFormDefault=“unqualified” 
             
             
               elementFormDefault=“qualified” xmlns:xs=“http://www.w3.org/2001/XMLSchema”&gt; 
             
             
                    &lt;xs:element name=“assetAttributes”&gt; 
             
             
                    &lt;xs:complexType&gt; 
             
             
                     &lt;xs:sequence&gt; 
             
             
                     &lt;xs:element name=“assetKey”&gt; 
             
             
                      &lt;xs:complexType&gt; 
             
             
                      &lt;xs:sequence&gt; 
             
             
                       &lt;xs:element name=“product” type=“xs:string” /&gt; 
             
             
                       &lt;xs:element name=“productRelease” type=“xs:string” /&gt; 
             
             
                       &lt;xs:element name=“culture” type=“xs:string” /&gt; 
             
             
                       &lt;xs:element name=“assetId” type=“xs:string” /&gt; 
             
             
                       &lt;xs:element name=“assetVersion” type=“xs:unsignedByte” /&gt; 
             
             
                      &lt;/xs:sequence&gt; 
             
             
                      &lt;/xs:complexType&gt; 
             
             
                     &lt;/xs:element&gt; 
             
             
                     &lt;xs:element name=“isTocAsset” type=“xs:unsignedByte” /&gt; 
             
             
                     &lt;xs:element name=“isRoot” type=“xs:unsignedByte” /&gt; 
             
             
                     &lt;xs:element name=“isCategory” type=“xs:unsignedByte” /&gt; 
             
             
                     &lt;xs:element name=“assetType” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“title” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“description” /&gt; 
             
             
                     &lt;xs:element name=“source” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“primaryProxyKey” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“principalAssetKey” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“contentType” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“contentName” type=“xs:string” /&gt; 
             
             
                     &lt;xs:element name=“isPackaged” type=“xs:unsignedByte” /&gt; 
             
             
                     &lt;xs:element name=“isPlaceHolder” type=“xs:unsignedByte” /&gt; 
             
             
                     &lt;xs:element name=“placeHolderId” /&gt; 
             
             
                     &lt;xs:element name=“collections” /&gt; 
             
             
                     &lt;xs:element name=“keywords” /&gt; 
             
             
                     &lt;xs:element name=“parents” /&gt; 
             
             
                     &lt;xs:element name=“properties” /&gt; 
             
             
                     &lt;/xs:sequence&gt; 
             
             
                    &lt;/xs:complexType&gt; 
             
             
                    &lt;/xs:element&gt; 
             
             
                   &lt;/xs:schema&gt; 
             
             
                 
             
          
         
       
     
   
   MDD files can be used for various assets. Each MDD file can include information to identify the associated content. The MDD file can also provide information about specialized applications for different metadata sets associated with the same content. For example, consider an information source which is a jpeg file. The jpeg file may have different applications depending on which context it is being used in. These applications could be a Picture Library, a web site, a backup utility, etc. The relevant metadata associated with the jpeg file for each of these applications could be different. Thus, there could be three different MDD files associated with the same content which is the jpeg file, wherein each MDD file describes the metadata for each of the aforementioned applications. 
   For example, an MDD file for table of content (TOC) assets can include the following: 
   
     
       
         
             
           
             
                 
             
           
          
             
                   &lt;?xml version=“1.0” encoding=“utf-16”?&gt; 
             
             
                   &lt;assetAttributes&gt; 
             
             
                    &lt;assetKey&gt; 
             
             
                    &lt;product&gt;ABC&lt;/product&gt; 
             
             
                    &lt;productRelease&gt;VS&lt;/productRelease&gt; 
             
             
                    &lt;culture&gt;en-US&lt;/culture&gt; 
             
             
                    &lt;assetId&gt;123456-1234-1234-1234-1234567890&lt;/assetId&gt; 
             
             
                    &lt;assetVersion&gt;1&lt;/assetVersion&gt; 
             
             
                    &lt;/assetKey&gt; 
             
             
                    &lt;isTocAsset&gt;1&lt;/isTocAsset&gt; 
             
             
                    &lt;assetType&gt;category&lt;/assetType&gt; 
             
             
                    &lt;title&gt;Sample toc MDD file&lt;/title&gt; 
             
             
                    &lt;description&gt;This is a sample toc MDD file&lt;/description&gt; 
             
             
                    &lt;source&gt;http://assistance.com&lt;/source&gt; 
             
             
                    &lt;principalAssetKey&gt;RealAssetsAssetKey&lt;/principalAssetKey&gt; 
             
             
                    &lt;isRoot&gt;1&lt;/isRoot&gt; 
             
             
                    &lt;isPlaceHolder&gt;1&lt;/isPlaceHolder&gt; 
             
             
                    &lt;placeHolderID&gt;C# content&lt;placeHolderID&gt; 
             
             
                    &lt;collections&gt; 
             
             
                    &lt;collection&gt;XYZ &lt;/collection&gt; 
             
             
                    &lt;/collections&gt; 
             
             
                    &lt;parents&gt; 
             
             
                    &lt;parent  order=“1” primaryParent=“1”&gt;SomeProduct#SomeRelease#en- 
             
             
               us#05eee553-6a90-456a-b9e5-fcb423390543#1&lt;/parent&gt; 
             
             
                    &lt;parent  order=“3” primaryParent=“0”&gt;SomeOtherProduct#Release1#en- 
             
             
               us#098765-1234-5678-9012-1234567890#1&lt;/parent&gt; 
             
             
                    &lt;parents&gt; 
             
             
                    &lt;properties&gt; 
             
             
                    &lt;property name=“PN0”&gt;PV0&lt;/property&gt; 
             
             
                    &lt;property name=“PN1”&gt;PV1&lt;/property&gt; 
             
             
                    &lt;/properties&gt; 
             
             
                   &lt;/assetAttributes&gt; 
             
             
                 
             
          
         
       
     
   
   Table 1 below includes a description of various elements included above. 
   
     
       
         
             
             
           
             
               TABLE 1 
             
             
                 
             
             
               Item 
               Description 
             
             
                 
             
           
          
             
               assetAttributes 
               This is the root element of the MDD file 
             
             
               assetKey 
               This describes the 5-part asset key for this 
             
             
                 
               asset. The 5 parts of the asset key can be 
             
             
                 
               stored in separate columns. Additionally, the 
             
             
                 
               ToString( ) version of the asset key can be 
             
             
                 
               stored in a separate column 
             
             
               isTocAsset 
               Value of 0 or 1 
             
             
               assetType 
               User-defined asset type 
             
             
               title 
               Title of the asset 
             
             
               Description 
               Summary/Description of the asset 
             
             
               Source 
               Online source for the asset. If updating assets 
             
             
                 
               in the background, use this URL to connect to 
             
             
                 
               the server 
             
             
               principalAssetKey 
               Asset key (ToString) of the real asset that this 
             
             
                 
               node links to 
             
             
               isRoot 
               Identifies if root node 
             
             
               isPlaceHolder 
               Identifies if place holder 
             
             
               placeHolderID 
               The place holder id of this node if it is a place 
             
             
                 
               holder. Ignored if it is not a place holder 
             
             
               collections 
               An asset can be part of multiple collections. 
             
             
                 
               This multi-value field would be used during 
             
             
                 
               filtering and scoping of content 
             
             
               Parents 
               The assetIds of the parents of this toc node. 
             
             
                 
               Also specifies the order within the parent. 
             
             
                 
               Order is sorted. So if order is 3 and there is no 
             
             
                 
               1 or 2 for this parent, then this node would be 
             
             
                 
               displayed as 1 st  child of the parent 
             
             
               primaryParent (attribute 
               The toc proxy asset of the primary parent of 
             
             
               on parent) 
               this node. Used for breadcrumbs 
             
             
               properties 
               This is a bag of properties that the author can 
             
             
                 
               specify. These properties can be used during 
             
             
                 
               filtering 
             
             
                 
             
          
         
       
     
   
   An example MDD file for non-table of content (non-TOC) assets can include the following: 
   
     
       
         
             
             
           
             
                 
                 
             
           
          
             
                 
               &lt;?xml version=“1.0” encoding=“utf-16”?&gt; 
             
             
                 
               &lt;assetAttributes&gt; 
             
             
                 
                &lt;assetKey&gt; 
             
             
                 
                 &lt;produc&gt;ABC&lt;/product&gt; 
             
             
                 
                 &lt;productRelease&gt;VS&lt;/productRelease&gt; 
             
             
                 
                 &lt;culture&gt;en-US&lt;/culture&gt; 
             
             
                 
                 &lt;assetId&gt;01fc4051-2995-4aa0-a19e-c5778153f165&lt;/assetId&gt; 
             
             
                 
                 &lt;assetVersion&gt;1&lt;/assetVersion&gt; 
             
             
                 
                &lt;/assetKey&gt; 
             
             
                 
                &lt;isTocAsset&gt;0&lt;/isTocAsset&gt; 
             
             
                 
                &lt;assetType&gt;topic&lt;/assetType&gt; 
             
             
                 
                &lt;title&gt;Sample MDD file&lt;/title&gt; 
             
             
                 
                &lt;description&gt;This is a sample MDD file&lt;/description&gt; 
             
             
                 
                &lt;source&gt;http://assistance.com&lt;/source&gt; 
             
             
                 
                &lt;primaryProxyKey&gt;VS#en-us#123456-6a90-456a-b9e5- 
             
          
         
         
             
          
             
               fcb423390543#1&lt;/primaryProxyKey&gt; 
             
          
         
         
             
             
          
             
                 
                &lt;contentType&gt;aml&lt;/contentType&gt; 
             
             
                 
                &lt;contentName&gt;sample.aml&lt;/contentName&gt; 
             
             
                 
                &lt;collections&gt; 
             
             
                 
                 &lt;collection&gt;XYZ&lt;/collection&gt; 
             
             
                 
                &lt;/collections&gt; 
             
             
                 
                &lt;keyWords&gt; 
             
             
                 
                 &lt;keyword&gt;sample&lt;/keyword&gt; 
             
             
                 
                 &lt;keyword&gt;example&lt;/keyword&gt; 
             
             
                 
                &lt;/keywords&gt; 
             
             
                 
                &lt;queries&gt; 
             
             
                 
                 &lt;query&gt;some query&lt;/query&gt; 
             
             
                 
                 &lt;query&gt;some query&lt;/query&gt; 
             
             
                 
                &lt;/queries&gt; 
             
             
                 
                &lt;bestBetQueries&gt; 
             
             
                 
                 &lt;bestBetQuery&gt;some best bet&lt;/bestBetQuery&gt; 
             
             
                 
                 &lt;bestBetQuery&gt;some best bet&lt;/bestBetQuery&gt; 
             
             
                 
                &lt;/bestBetQueries&gt; 
             
             
                 
                &lt;properties&gt; 
             
             
                 
                 &lt;property name=“PN0”&gt;PV0&lt;/property&gt; 
             
             
                 
                 &lt;property name=“PN1”&gt;PV1&lt;/property&gt; 
             
             
                 
                &lt;/properties&gt; 
             
             
                 
                 
             
          
         
       
     
   
   &lt;ftsData&gt; What are the risks of allowing programs through a firewall? When you create an exceptionView definition or open a portView definition in a firewall, you allow a particular program to send information to or from your computer through the firewall. Allowing a program to communicate through a firewall (sometimes called unblocking) is like opening a tiny door in the firewall. Each time you allow an exception or open a port for a program to communicate through a firewall, your computer becomes a bit less secure. The more exceptions or open ports your firewall has, the more opportunities there are for hackers or malicious software to use one of those openings to spread a worm, access your files, or use your computer to spread malicious software to others. It&#39;s generally safer to create exceptions than to open ports. If you open a port, it stays open until you close it, whether or not a program is using it. If you create an exception, the “door” is open only when needed for a particular communication. To help decrease your security risk: Only create an exception or open a port when you really need to, and remove exceptions or close ports that you no longer need. Never create an exception or open a port for a program that you do not recognize. See also Firewall: frequently asked questions What are network categories? 
   
     
       
         
             
             
           
             
                 
                 
             
           
          
             
                 
                &lt;/ftsData&gt; 
             
             
                 
               &lt;/assetAttributes&gt;+ 
             
             
                 
                 
             
          
         
       
     
   
   Table 2 below includes a description of various elements included above. 
   
     
       
         
             
             
             
           
             
                 
               TABLE 2 
             
             
                 
                 
             
             
                 
               Item 
               Description 
             
             
                 
                 
             
           
          
             
                 
               assetAttributes 
               This is the root element of the MDD file 
             
             
                 
               assetKey 
               This describes the 5-part asset key for this 
             
             
                 
                 
               asset. The 5 parts of the asset key can be 
             
             
                 
                 
               stored in separate columns. Additionally, the 
             
             
                 
                 
               ToString( ) version of the asset key can be 
             
             
                 
                 
               stored in a separate column 
             
             
                 
               isTocAsset 
               Value of 0 or 1 
             
             
                 
               assetType 
               User-defined asset type 
             
             
                 
               title 
               Title of the asset 
             
             
                 
               Description 
               Summary/Description of the asset 
             
             
                 
               Source 
               Online source for the asset. If updating assets 
             
             
                 
                 
               in the background, use this URL to connect to 
             
             
                 
                 
               the server 
             
             
                 
               primaryProxyKey 
               The toc proxy asset to sync to during TOC 
             
             
                 
                 
               sync 
             
             
                 
               contentType 
               Extension of the content file associated with 
             
             
                 
                 
               this asset. This can also be used for FTS data 
             
             
                 
                 
               when chaining. also useful for virtual, binary, 
             
             
                 
                 
               and other formats (e.g., URL, STTP, etc.) 
             
             
                 
               contentName 
               Name of the content file. This can also be 
             
             
                 
                 
               used during off-line content indexing and for 
             
             
                 
                 
               online-cached content indexing 
             
             
                 
               collections 
               An asset can be part of multiple collections. 
             
             
                 
                 
               This multi-value field would be used during 
             
             
                 
                 
               filtering and scoping of content 
             
             
                 
               keywords 
               A multi-value field specified the keywords 
             
             
                 
                 
               associated with this asset. This is used for 
             
             
                 
                 
               displayed keyword index 
             
             
                 
               properties 
               This is a bag of properties that the author can 
             
             
                 
                 
               specify. These properties can be used during 
             
             
                 
                 
               filtering 
             
             
                 
               queries 
               A multi-valued field for query to asset 
             
             
                 
                 
               mappings. In their original authored form 
             
             
                 
                 
               these distinct objects (not assets), but here 
             
             
                 
                 
               they can be mapped to become properties on 
             
             
                 
                 
               asset objects 
             
             
                 
               bestBetQueries 
               A multi-valued field for best bets 
             
             
                 
               ftsData 
               fts data for the content can be specified in this 
             
             
                 
                 
               field. In some cases, it may not be feasible to 
             
             
                 
                 
               specify fts data in the content file (such as for 
             
             
                 
                 
               image files, for example). If fts data is 
             
             
                 
                 
               specified here, then only this content would 
             
             
                 
                 
               be used for fts, and fts data may not be 
             
             
                 
                 
               retrieved from the content file 
             
             
                 
                 
             
          
         
       
     
   
   An additional example of an MDD file is shown below and includes: 
   
     
       
         
             
           
             
                 
             
           
          
             
                   &lt;assetAttributes&gt; 
             
             
                    &lt;assetKey&gt; 
             
             
                    &lt;assetId&gt;00e69dca-3820-4215-96aa-4fc7ade34aec&lt;/assetId&gt; 
             
             
                    &lt;assetVersion&gt;4&lt;/assetVersion&gt; 
             
             
                    &lt;culture&gt;en-US&lt;/culture&gt; 
             
             
                    &lt;product&gt;ddaf8136-402d-4a02-aa43-c384f26796ea&lt;/product&gt; 
             
             
                    &lt;productRelease&gt;CCB2&lt;/productRelease&gt; 
             
             
                   &lt;/assetKey&gt; 
             
             
                   &lt;isTocAsset&gt;0&lt;/isTocAsset&gt; 
             
             
                   &lt;assetType&gt;Topic&lt;/assetType&gt; 
             
             
                   &lt;title&gt;Accessibility Products and Services from Microsoft 
             
             
                   &lt;/title&gt; 
             
             
                   &lt;description&gt; 
             
             
                   &lt;/description&gt; 
             
             
                   &lt;source&gt;local&lt;/source&gt; 
             
             
                   &lt;primaryProxyKey&gt;####&lt;/primaryProxyKey&gt; 
             
             
                   &lt;contentType&gt;aml&lt;/contentType&gt; 
             
             
                   &lt;contentName&gt;00e69dca-3820-4215-96aa-4fc7ade34aec#en- 
             
             
               US#ddaf8136-402d-4a02-aa43-c384f26796ea#CCB2#4&lt;/contentName&gt; 
             
             
                   &lt;isPackaged&gt;0&lt;/isPackaged&gt; 
             
             
                   &lt;collections /&gt; 
             
             
                   &lt;keywords /&gt; 
             
             
                   &lt;queries /&gt; 
             
             
                   &lt;bestBetQueries /&gt; 
             
             
                   &lt;properties&gt; 
             
             
                    &lt;property name=“TocTitle”&gt; 
             
             
                    &lt;/property&gt; 
             
             
                   &lt;/properties&gt; 
             
             
                 
             
          
         
       
     
   
   &lt;ftsData&gt; Accessibility Products and Services is committed to making its products and services easier for everyone to use. The following topics provide information about the features, products, and services that provide better access for people with disabilities: 1) Accessibility features in alternative formats; 2) Customer service for people with hearing impairments. You can contact your subsidiary to find out whether the type of products and services described in this section are available in your area. The operating system has many built-in accessibility features that are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or who are deaf or hard-of-hearing. The features are installed during Setup. Free step-by-step tutorials provide detailed procedures for adjusting the accessibility options and settings on your computer. This information is presented in a side-by-side format so that you can learn how to use the mouse, the keyboard, or a combination of both. Documentation in alternative formats is available for users who have difficulty reading or handling printed materials. &lt;/ftsData&gt; 
   &lt;/assetAttributes&gt; 
     FIG. 5  is a block diagram of a system  500  configured to manage information, in accordance with an embodiment. The system  500  can be configured to associate information including metadata and/or full-text search data (FTSData) with various information types, such as a number of disparate file types for example. In one embodiment, FTSData can include free-form text data or full-text-search data and can be included as part of an MDD file (see Table 2 and the MDD file example above). Correspondingly, a user or application can search against the text using full-text-search capabilities. 
   As described below, text and other information that is specified in an MDD file as FTSData can be returned to the indexer  102  (and/or search engine) as free-form text. A user can create an MDD file to include the FTSData which can provide additional information about an underlying information source. Moreover, the user can include FTSData in the MDD file to describe aspects of the MDD file. The system  500  can use metadata and/or FTSData as part of indexing and/or searching operations. For example, the system  500  can be configured to extract metadata and/or FTSData from an MDD file for use in indexing and searching operations. As described above, FTSData can be included as part of an MDD file, wherein the MDD file can be associated with any type of file, content, or other data construct. 
   As shown in  FIG. 5 , the system  500  includes an indexer  502  that is configured to use metadata, in part, to provide an efficient indexing of information, such as for files, file content, metadata, FTSData, etc. The indexer  502  can use metadata, FTSData, and other information to construct an indexed catalog or data structure to facilitate efficient and rapid searching. For example, the indexer  502  can use metadata extracted from locally stored files, remotely networked files, and/or other information sources when indexing information associated therewith. 
   To provide an illustrative example of the functionality of the system  500 , a number of files are depicted to include a type  1  file  504 , a type  2  file  506 , and a type x file  508 . Accordingly, the system  500  can include or be associated with any number of files of disparate types. For example, the type  1  file  504  may be a .pdf type file. A user may want to overcome certain limitations associated with a .pdf type file by using an associated MDD file (shown as type  1 .mdd in  FIG. 5 ) to associate a number of annotations and additional metadata (e.g., Category) with the .pdf file. A user can use components of the system  500  to eliminate a distinction between data and metadata that is part of the .pdf file by using metadata and FTSData that can be added to an associated MDD file. As described below, the indexer  502  can use the annotations in the form of FTSData and additional metadata of an associated MDD file to index against the .pdf file. 
   Continuing with the illustrative example, the type  2  file  506  may be an image file (e.g., .jpg). Again, a user may want to overcome certain limitations associated with the image file by using an associated MDD file (shown as type  2 .mdd in  FIG. 5 ). For example, the user may want to associate blog text with the image file. The indexer  502  can use the blog text in the form of FTSData and/or additional metadata of the associated MDD file to index against the image file. As described herein, MDD files can be associated with any type of file or other data construct, including information sources yet to be defined. Thus, the type x file  508  can refer to any type of file or data construct. Moreover, while the files  504 - 508  are shown as part of the system  500 , the files  504 - 508  may be associated with other systems, networks, etc. The system  500  can also be used to interact with other files and information sources which may be associated with some other system, whether local or remote. 
   As shown in  FIG. 5 , the system  500  includes a type 1 handler  510  that can be used to extract metadata and other information from the type 1 file. For example, the type 1 handler  510  can be implemented as a .pdf IFilter for an associated .pdf file and can extract metadata and other .pdf data from the .pdf file. The system  500  also includes a type 2 handler  512  that can be used to extract metadata and other information from the type 2 file. For example, the type 2 handler  512  can be implemented as a .jpg IFilter for an associated .jpg file and can extract metadata and other .jpg data from the .jpg file. A type x handler  514  is associated with the type x file  508  and can be configured to extract metadata and other information from the type x file  508 . The type x handler  514  illustrates that the system  500  can include various handlers for different file types, such as a number of IFilters. 
   The system  500  also includes a metadata handler  516  that is configured to extract metadata and other information, FTSData for example, from an associated file type, such as an MDD file, or data stream. As shown in  FIG. 5 , an MDD file (type  1 .MDD, type  2 .MDD, and type x.MDD) is associated with an associated file type (type 1 file  504 , type 2 file  506 , and type x file  508  respectively). Each MDD file can include code and other properties to identify the file or informational source that is associated with the metadata and/or FTSData. As described above, metadata and other information can be included with the MDD files according to a schema such that the metadata handler  516  can be used to interact with the associated metadata and other information. 
   Thus, a user can add metadata and FTSdata to an associated MDD file which can be used by the metadata handler  516  as part of an indexing operation associated with disparate file types (e.g., type 1 file, type 2 file, etc.) Moreover, the metadata included in the MDD file is not constrained by the underlying format of the associated file type. Correspondingly, each MDD file includes a data structure or format that enables the metadata handler  516  to extract or otherwise determine the metadata and other information, such as FTSData for example, associated therewith. An MDD file can be used to represent any file format, including existing and new file formats, data structures, or other constructs. For example, an MDD file can be associated with an image file, a document, spreadsheet, blog, uniform resource locator (URL), hyperlink, website, etc. An authoring tool, publishing tool, general purpose creation tool, etc. can be used to create an MDD file. In one embodiment, an application can automatically create an MDD file based on an underlying file or other information source. 
   Due in part to the characteristics of the metadata handler  516 , such as a metadata IFilter for example, and the MDD files, metadata and/or other information associated with each MDD file can be extracted therefrom or otherwise accessed. For example, extracted metadata and/or FTSData can be communicated to the indexer  502  for indexing and searching purposes against a number of disparate file or information types. In one embodiment, the metadata handler  516  can be configured as an IFilter interface for interacting with an MDD file and/or a data stream associated with an underlying content-based or other type of file or data construct. 
   In one embodiment, the metadata handler  516  can operate to request metadata and/or other information (e.g., FTSData) from the various types of handlers, also referred to as “chaining.” The metadata handler  516  can also extract metadata and other information from a number of information sources, such as one or more MDD files for example. For example, the metadata handler  516  can extract metadata from an MDD file that is associated with an underlying information source or as a stand-alone data source (e.g., TOC MDD file). As shown, the metadata handler  516  is operating as an intermediate handler and is requesting: type 1 metadata and FTSData from the type 1 handler  510 ; type 2 metadata and FTSData from the type 2 handler  512 ; and, type x metadata and FTSData from the type x handler  514 . 
   Accordingly, the metadata handler  516  can operate as a gatekeeper or intermediary between any registered handlers and the indexer  502 . Since each handler  510   514  (e.g., IFilters) can be configured to extract metadata and other information from an associated file type or other information source, the metadata handler  516  can call or chain one or more of the handlers  510 - 514  when requesting metadata and other information, thereby creating a chain of handlers (e.g., a chain of IFilters). Correspondingly, each handler  510 - 514  can return metadata and/or FTSData from an associated underlying file or data construct based in part on the metadata handler  516  request. 
   Moreover, the metadata handler  516  can operate to extract metadata and/or FTSData from an associated MDD file (see Table 2 and the associated schema above). By including FTSData in an MDD file, a user is able to add annotations, comments, and other text that would not normally be associated with the underlying information source due to a certain predetermined or unmanageable format. Correspondingly, indexing and searching components can use the FTSData to provide full-text-search capabilities including metadata search capabilities. In one embodiment, the metadata handler  516  can be configured to contemporaneously or alternately extract metadata and/or FTSData from a number of MDD files. In another embodiment, multiple metadata handlers can be linked with other handlers to extract information from an underlying information source. 
   The metadata handler  516  can use metadata and/or FTSData as provided by another handler that operates to extract metadata and/or FTSData from an associated file or other information source (e.g., .pdf, .jpg, .doc, .wav, yet to be defined, etc.). For example, the metadata handler  516  can use a number of disparate IFilters to extract metadata and/or FTSData from a number of associated files. In an embodiment, the metadata handler  516  can operate to combine and/or communicate metadata and/or FTSData from the disparate handlers with the corresponding metadata and/or FTSData from a number of MDD files. The metadata handler  516  can be controlled to operate (e.g., mode of operation setting) in a desired way so that metadata and/or FTSData can be returned to the indexer  502  or other component according to a defined mode. Thus, the metadata handler  516  can return the metadata and/or FTSData, combined according to the mode of operation, to the indexer  502  as if it were part of an MDD file. 
   A user can associate FTSData with a file or other information source by using the capability provided by the inclusion of an FTSData element to an MDD schema. In one embodiment, the FTSData element includes a free-form text value, and can be communicated (e.g., pushed) to the indexer  502  and/or search engine as FTSData for an associated MDD file. By associating the MDD file with the linked content, the FTSData can be visualized as if it is part of the linked content and thereby providing additional information that an indexing or searching application can use for indexing and searching operations. Moreover, a user can associate additional information with a file or other information source, enabling a broader range of identification functionality to the user. 
   As described above, a number of handlers can operate together (e.g., handler chaining) to collaboratively return metadata and/or FTSData from associated files or information sources. Since an MDD file can include information about the content-type of an associated file or other information source, the metadata handler  516  can look up and use a registered handler (e.g., IFilter) in a similar fashion as to how the indexer  502  can use registered handlers. Correspondingly, when the indexer  502  invokes the metadata handler  516  and requests metadata and/or FTSData from an MDD file, the metadata handler  516  in turn invokes the associated handler for the specified content-type; requesting metadata and/or FTSData from the underlying information source, such as an associated or linked content file or other data construct for example. Thereafter, the metadata handler  516  can communicate a desired combination of the metadata and/or FTSData to the indexer  502  as if the information is actually part of the MDD file. The same or similar sequence can be used when a search engine or application requests FTSData from an MDD file. 
   In an embodiment, the metadata handler  516  includes functionality to operate according to a number of different modes of operation. A number of settings (e.g., global settings, settings specified per MDD file, settings specified per indexing and/or searching scenario, etc.) can be used to control the operational mode of the metadata handler  516 . In one embodiment, the metadata handler  516  can be configured to operate according to the following modes, but is not so limited: 
   1. Append with MDD Priority: 
   a. FTSData from a MDD file (if any) is appended to FTSData from an information source associated with a MDD file (if any) and returned to the indexer  502 . 
   b. Single-valued metadata types (e.g. Title): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, the corresponding metadata from the content is ignored. 
   c. Multi-valued metadata types (e.g. keywords): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, a union of the values from the content and MDD file is returned to the indexer  502 . 
   For example, the following describes a sequence of operations associated with the append with MDD priority mode: 
   First, the indexer  502  sees a new file “MyVacationPicture.mdd.”MyVacationPicture.mdd is the MDD file that is associated with and linked to a picture file “MyVacationPicture.jpeg.” The indexer  502  can then call on and load the metadata handler  516  which requests metadata and/or FTSData from the MDD file. Since the metadata handler  516  knows that the associated content is a jpeg file, it can load a handler (e.g., handler  510 ) associated with the jpeg file (e.g., jpeg IFilter) and requests metadata from the jpeg file. The jpeg handler extracts metadata, but since there is no FTSData, the jpeg handler will only return the extracted metadata. 
   The metadata handler  516  operates to combine the metadata from the jpeg file with the metadata from the MDD file according to the specified mode. The MDD file includes an FTSData specification which includes blog text that is associated with the picture. Then, the metadata handler  516  returns the metadata and FTSData to the indexer  502 . Thereafter, the indexer  502 , even if unaware of the underlying information source (jpeg file) or the handler  510  for jpeg files (e.g., jpeg IFilter), indexes this metadata and FTSData as if belonging to the MDD file. A user is now able to search against the metadata and the FTSData emitted by the metadata handler  516 . 
   2. Append with Content Priority: 
   a. FTSData from the MDD file (if any) is appended to FTSData from content (if any) and returned to the indexer  502 . 
   b. Single-valued metadata types (e.g. Title): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, the corresponding metadata from the MDD file is ignored. 
   c. Multi-valued metadata types (e.g. keywords): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, a union of the values from the content and MDDfile is returned to the indexer  502 . 
   3. Overwrite with MDD Priority: 
   a. If any FTSData is specified in MDD file, FTSData (if any) from content is ignored, else FTSData (if any) from content is returned to the indexer  502 . 
   b. Single-valued metadata types (e.g. Title): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, the corresponding metadata from the content is ignored. 
   c. Multi-valued metadata types (e.g. keywords): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, the corresponding metadata from the content is ignored. 
   4. Overwrite with Content Priority: 
   a. If any FTSData is specified in content, FTSData (if any) from MDD file is ignored, else FTSData (if any) from the MDD file is returned to the indexer  502 . 
   b. Single-valued metadata types (e.g. Title): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, the corresponding metadata from the MDD file is ignored. 
   c. Multi-valued metadata types (e.g. keywords): a union of metadata from the MDD file and content is returned to the indexer  502 . If there is a metadata name conflict, the corresponding metadata from the MDD file is ignored. 
   5. Chain for FTSData Only: 
   a. If any FTSData is specified in the MDD file, FTSData (if any) from content is ignored, else FTSData (if any) from content is returned to the indexer  502 . 
   b. All metadata comes from the MDD file. Metadata from content is ignored. 
   6. Fine-Granularity Chaining: 
   a. In this mode, each metadata element in the MDD file specifies which metadata-value will take priority in case of a conflict between MDD file and content. If the MDD file does not specify anything, global settings can be used to disambiguate. 
     FIG. 6  is a flow diagram illustrating a process of managing information, in accordance with an embodiment. Components of  FIG. 5  are used in the description of  FIG. 6 , but the embodiment is not so limited. At  600 , the index component  502  sees a new file or information source, such as an MDD file for example, and requests information therefrom. For example, the indexer  502  may be monitoring a local hard disk, file system, folder(s), database, remote information source, or other data source. As part of the request, the indexer  502  can call on the metadata handler  516  to extract metadata and/or FTSData from the information source. At  602 , the metadata handler  516  can operate to call on one or more handlers to return information associated with any linked content that is associated with the information source. 
   At  604 , one or, more handlers can return metadata and/or FTSData from any linked content. At  606 , the metadata handler  516  operates to extract metadata and/or FTSData from the new information source. At  608 , the metadata handler  516  can operate to return the metadata and/or FTSData returned by the one or more handlers with the metadata and/or FTSData extracted from the information source based in part on a desired setting (e.g., see mode settings above). At  610 , the indexer  502  can operate to index the returned metadata and/or FTSData. Thereafter, the indexed metadata and/or FTSData can be used to locate information as part of a search. For example, the system  500  can operate to invoke an application based in part on the location, name, etc. of an information source that is associated with an MDD file. 
   In one embodiment, a metadata handler, such as a metadata IFilter for example, can be configured as a software application, including executable instructions, having a number of modules that are configured as follows. 
   The metadata handler can include an amlProcessor.h module which corresponds with a header file used for processing AML files and includes: 
   
     
       
         
             
           
             
                 
             
           
          
             
                   #pragma once 
             
             
                   #include “stdafx.h” 
             
             
                   // CAmlProcessor code derived from APV1 compiler. 
             
             
                   class amlProcessor 
             
             
                   { 
             
             
                   public: 
             
             
                    amlProcessor( ) {}; 
             
             
                    ~amlProcessor( ) {}; 
             
             
                    void ExtractBody(const CString &amp; amlFile, CComBSTR &amp;bstrBody) 
             
             
                    { 
             
             
                     HRESULT hr = S_OK; 
             
             
                     // Create XML DOM From URL. 
             
             
                     CComPtr   &lt;IXMLDOMDocument2&gt;  pXmlDoc   = 
             
             
               XmlUtil::CreateXmlDomFromUrl(CComBSTR(amlFile)); 
             
             
                     if (!pXmlDoc) 
             
             
                     { 
             
             
                      bstrBody = L“”; 
             
             
                      return; 
             
             
                     } 
             
             
                     // Set the MAML namespace as the namespace to be 
             
             
                     // used in XPath expressions. 
             
             
                     CComVariant varValue (GetMamlNamespace( )); 
             
             
                     if  (FAILED  (hr  = pXmlDoc-&gt;setProperty(L“SelectionNamespaces”, 
             
             
               varValue))) 
             
             
                     { 
             
             
                      bstrBody = L“”; 
             
             
                      return; 
             
             
                     } 
             
             
                      CComBSTR bstrXsl(500); 
             
             
                     InitializeXSL(bstrXsl); 
             
             
                     // Create XSL Doc from BSTR 
             
             
                     CComPtr&lt;IXMLDOMDocument2&gt;    pXslDoc     = 
             
             
               XmlUtil::CreateXmlDom(bstrXsl); 
             
             
                     if (!pXslDoc) 
             
             
                     { 
             
             
                      bstrBody = L“”; 
             
             
                      return; 
             
             
                     } 
             
             
                      // Use the above xsl transform to extract the body 
             
             
                     if(FAILED (hr = pXmlDoc-&gt;transformNode(pXslDoc, &amp;bstrBody))) 
             
             
                     { 
             
             
                      bstrBody = L“”; 
             
             
                      return; 
             
             
                     } 
             
             
                    } 
             
             
                   private: 
             
             
                    WCHAR *GetamlNamespace( ) 
             
             
                    { 
             
             
                     return L“xmlns:maml=‘http://schemas.microsoft.com/maml/2004/10’”; 
             
             
                    } 
             
             
                    void InitializeXSL(CComBSTR &amp;bstrXsl) 
             
             
                    { 
             
             
                     bstrXsl = L“&lt;?xml version=\“1.0\” encoding=\“UTF-8\” ?&gt;\r\n”; 
             
             
                     bstrXsl.Append(“&lt;xsl:stylesheet             version=\“1.0\” 
             
             
               xmlns:xsl=\“http://www.w3.org/1999/XSL/Transform\” ”); 
             
             
                     bstrXsl.Append(GetMamlNamespace( )); 
             
             
                     bstrXsl.Append(“ xml:space=\“default\” &gt; \r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:output method=\“text\” indent=\“no\” /&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:template match=\“Λ”&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:apply-templates /&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;/xsl:template&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:template match=\“text( )\”&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:text&gt; &lt;/xsl:text&gt;&lt;xsl:value-of select=\“.\” /&gt;&lt;xsl:text 
             
             
               xml:space=\“preserve\”&gt; &lt;/xsl:text&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;/xsl:template&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:template 
             
             
               match=\“/maml:task[@contentType=‘ACWProcedure’]//maml:taskExecutionBlock\”&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;/xsl:template&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:template match=\“//maml:title\”&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;/xsl:template&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;xsl:template match=\“//maml:reusableContent\”&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;/xsl:template&gt;\r\n”); 
             
             
                     bstrXsl.Append(“&lt;/xsl:stylesheet&gt;”); 
             
             
                    } 
             
             
                   }; 
             
             
                 
             
          
         
       
     
   
   The metadata handler can include a dll.cpp module which is standard ATL attributed stub code that can be used to generate common DLL exports and includes: 
   
     
       
         
             
           
             
                 
             
           
          
             
                   // APMetaDataFilter.cpp : Implementation of DLL Exports. 
             
             
                   #include “stdafx.h” 
             
             
                   #include “hxutil.h” 
             
             
                   #include “resource.h” 
             
             
                   //  The  module  attribute  causes  DllMain, 
             
             
               DllRegisterServer  and DllUnregisterServer to be automatically 
             
             
               implemented 
             
             
                   [ module(dll, uuid = “{94727D5F-9450-4160-8B42- 
             
             
                   E7E55B910D0B}”, 
             
             
                     name = “MDDFilter”, 
             
             
                     helpstring = “Ap MDD IFilter 1.0 Type Library”, 
             
             
                     resource_name = “IDR_MDDFILT”) ] ; 
             
             
                 
             
          
         
       
     
   
   The metadata handler can include a mddfilt.cpp module which implements the IFilter COM interface. An index component can operate to call the mddfilt.cpp module after encountering a file, such as an MDD file for example, or information associated therewith, to thereby request the associated metadata and/or full-text data. The mddfilt.cpp includes the following: 

 
   Various embodiments described herein can be included with the functionality of an assistance platform rich client. Users can execute searches using the assistance platform rich client which can operate to issue a search for MDD files to a desktop search engine. The MDD files can be interacted with, due in part to the XML file format, to ascertain an actual location and name of a particular file that is represented in part by metadata. The desktop search can operate to return the content, link, or other user-friendly information to the user based on an introspection of the MDD file. 
   The embodiments and examples described herein are not intended to be limiting and other embodiments are available. For example, the functionality described herein can be used as part of an xcopy based installation through self-describing content. Content can be installed that have relationships to other installed content, by describing the relationships through metadata. This enables simple xcopy-based installation without the need to modify registry or create custom files that encapsulate the relationships. 
   As another example, the functionality described herein can be used to provide a uniform representation of metadata across different media formats (wma, mp3, jpeg, png, etc.). Metadata files can be used to provide a uniform representation for all metadata for various media formats. Since the format is flexible and extensible, any metadata can be captured in the MDD file. For example, the uniform representation can be used when a media player needs to process metadata from a WMA file, an mp3 file, a wav file or other formats. Instead of learning the format for each file-type (current and future formats), a reliance can be placed on the MDD file for a uniform representation of any associated metadata. 
   As further example, the functionality described herein can be used to provide an instant shortcut mechanism to create “shortcuts” or “hot words”. A shortcut is a word or phrase, which, when typed or otherwise communicated, launches an application or performs some other task. For instance, typing “notepad” in a search box can operate to launch a notepad application. Since the metadata handler functionality is not restricted to file-based content, a “shortcut” can be represented using an MDD file. In such a case, the title would be the name of the shortcut, the “content type” in the MDD file would be “shortcut”, and the associated content name would be the path to the application to be launched along with any parameters. A user is able define a shortcut for any application by creating such an MDD file. The shortcut can then be indexed as described above using a metadata handler. When a user types “notepad” in the “start search” box, the operating system (OS) can perform a lookup to determine if there is anything indexed with title “notepad” and content type “shortcut”. If it finds one, the OS can launch the associated application pointed to by content name. 
   The functionality described herein can be applied to associate different sets of metadata for the same content targeting different applications. The functionality can also be applied to newly created or foreign file formats. The functionality allows users to provide tailored metadata for various files as part of a uniform metadata representation. Moreover, the functionality can be used to associate metadata with non-file-based content, such as a virtual content, etc., and allows for searching over file-based, virtual, and other content simultaneously and seamlessly. That is, as described above, an abstraction layer for metadata is provided for access that can be configured to be independent of content-type. The functionality described herein can be used to operate with binary formats, such as image files, etc. For example, a user may be writing a blog or some kind of a description about a particular innovation picture captured as an image file. Accordingly, an MDD file can be used to associate the blog and image file. 
   The systems and components described above can be implemented as part of networked, distributed, or other computer-implemented environment. The systems and components can communicate via a wired, wireless, and/or a combination of communication networks. In an alternative embodiment, the handler  104  can be included with the index component  102  as a single component for providing functionality for indexing and searching for information associated with a number of files or other data representations. In another embodiment, the handler  104  can be included as part of the functionality of an OS. A system can also include a number of handler components, wherein each handler component can include particular functionality associated with one or more file types. For example, a handler, such as a document IFilter, can be configured to read metadata, content, and/or other information associated with a document file. 
   A number of client computing devices, including desktop computers, laptops, handhelds, or other smart devices can interact with and/or be included as part of the system  100 . In alternative embodiments, the various components can be combined and/or configured according to a desired implementation. Other embodiments and configurations are available. 
   Exemplary Operating Environment 
   Referring now to  FIG. 7 , the following discussion is intended to provide a brief, general description of a suitable computing environment in which embodiments of the invention may be implemented. While the invention will be described in the general context of program modules that execute in conjunction with program modules that run on an operating system on a personal computer, those skilled in the art will recognize that the invention may also be implemented in combination with other types of computer systems and program modules. 
   Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. 
   Referring now to  FIG. 7 , an illustrative operating environment for embodiments of the invention will be described. As shown in  FIG. 7 , computer  2  comprises a general purpose desktop, laptop, handheld, or other type of computer capable of executing one or more application programs. The computer  2  includes at least one central processing unit  8  (“CPU”), a system memory  12 , including a random access memory  18  (“RAM”) and a read-only memory (“ROM”)  20 , and a system bus  10  that couples the memory to the CPU  8 . A basic input/output system containing the basic routines that help to transfer information between elements within the computer, such as during startup, is stored in the ROM  20 . The computer  2  further includes a mass storage device  14  for storing an operating system  32 , application programs, and other program modules. 
   The mass storage device  14  is connected to the CPU  8  through a mass storage controller (not shown) connected to the bus  10 . The mass storage device  14  and its associated computer-readable media provide non-volatile storage for the computer  2 . Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed or utilized by the computer  2 . 
   By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, 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, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical 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 be accessed by the computer  2 . 
   According to various embodiments of the invention, the computer  2  may operate in a networked environment using logical connections to remote computers through a network  4 , such as a local network, the Internet, etc. for example. The computer  2  may connect to the network  4  through a network interface unit  16  connected to the bus  10 . It should be appreciated that the network interface unit  16  may also be utilized to connect to other types of networks and remote computing systems. The computer  2  may also include an input/output controller  22  for receiving and processing input from a number of other devices, including a keyboard, mouse, etc. (not shown). Similarly, an input/output controller  22  may provide output to a display screen, a printer, or other type of output device. 
   As mentioned briefly above, a number of program modules and data files may be stored in the mass storage device  14  and RAM  18  of the computer  2 , including an operating system  32  suitable for controlling the operation of a networked personal computer, such as the WINDOWS operating systems from MICROSOFT CORPORATION of Redmond, Wash. The mass storage device  14  and RAM  18  may also store one or more program modules. In particular, the mass storage device  14  and the RAM  18  may store application programs, such as a word processing application  28 , a spreadsheet application  30 , e-mail application  34 , drawing application, etc. 
   It should be appreciated that various embodiments of the present invention can be implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, logical operations including related algorithms can be referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, firmware, special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims set forth herein. 
   Although the invention has been described in connection with various exemplary embodiments, those of ordinary skill in the art will understand that many modifications can be made thereto within the scope of the claims that follow. Accordingly, it is not intended that the scope of the invention in any way be limited by the above description, but instead be determined entirely by reference to the claims that follow.