Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
  • G06F16/83—Querying
  • G06F16/835—Query processing
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually

Definitions

• Data hierarchy schemes such as tree structures, are important tools for representing, organizing, and retrieving data.
• the typical scheme starts by establishing definitions that classify the types of data involved.
• each data type may be associated with a reference mechanism (e.g., a pointer, a link, or a physical memory address) that refers to the data represented by the hierarchy scheme. Additionally, the reference mechanisms may negatively impact performance in traversing the hierarchy and in processing query requests.
• Current practices rely on the basic tree structure and apply various programming languages to fit its needs. Using FIG. 1 as an illustration, a taxonomy structure 100 is a basic example of organizing hardware data within a device.
• a hardware node 102 is classified as a parent node for all other nodes because it is at the top of the hierarchy.
• the hardware node 102 has one or more children and one of them is an interface node 104.
• the hardware node 102 thus includes a pointer or a reference referring to its child node, the interface node 104 in this example.
• the interface node 104 is also a parent to its children nodes.
• the interface node 104 has a pointer referring to its parent, the hardware node 102, and a pointer referring to its children nodes, in this case COMl and COM2.
• Embodiments of the invention overcome the shortfalls of existing practices by defining objects according to a taxonomy structure that supports data having references to related objects. Using these references, which contain information about related objects and references to the actual entities represented by these related objects, aspects of the invention establish a robust classification or taxonomy structure.
• mechanisms and conventions embodying aspects of the invention use extensible markup language (XML) or unified modeling language (UML).
• XML extensible markup language
• UML unified modeling language
• FIG. 1 is a block diagram illustrating an exiting typical representation of a hierarchical structure.
• FIGS. 2 A and 2B are block diagrams illustrating a basic representation of a taxonomy structure according to an embodiment of the invention.
• FIGS. 3 A and 3B are block diagrams illustrating an exemplary data structure embodying elements of the taxonomy structure according to an embodiment of the invention.
• FIG. 4 is a block diagram illustrating a system for using the taxonomy structure according to an embodiment of the invention.
• FIG. 5 is a flow chart illustrating operations of representing a plurality of objects to form a taxonomy structure according to an embodiment of the invention.
• FIG. 6 is a block diagram illustrating a specific implementation of a containment taxonomy according to an embodiment of the invention.
• Corresponding reference characters indicate corresponding parts throughout the drawings. DETAILED DESCRIPTION
• Embodiments of the invention provide a standardized and an efficient mechanism for defining hierarchical structures used to represent physical objects, such as a containment taxonomy or terminology trees.
• the containment taxonomy may represent physical hardware, such as network cards or adapter cards coupled to a chassis of a computing device, located at a data center, or the like.
• the containment taxonomy may also include references to files (e.g., file structure systems in a computing device), or locations (e.g., data centers or workspaces in buildings in regions).
• the terminology taxonomy may include defining a status, sub-status, symptom, or the like.
• aspects of the invention relate the taxonomy structure to the "real world" data in a single design while maintaining flexibility of the structure and provide efficient traversal, searching, and retrieval.
• FIGS. 2A and 2B block diagrams illustrate a basic representation 200 of a taxonomy structure according to an embodiment of the invention.
• the representation 200 illustrates a containment structure of a hardware chassis setup for a computing system.
• a plurality of taxonomy types is defined for this containment structure.
• the plurality of taxonomy types identifies the classification for identifying entities that the classification represents.
• the classification may wish to represent a collection of entities in the hardware chassis and taxonomy types assist in better organizing and representing each of the entities.
• the plurality of taxonomy types may include "Hardware,” “Interface,” “COMl,” Network Card”, etc. It is to be understood that other taxonomy types may be defined based on the structure depending on a particular usage without departing from the scope of the invention. It is also understood that other taxonomy types for a terminology taxonomy or other classification may be applied without departing from the scope of the invention. [0016] Referring to FIG. 2A, an object 202 having a taxonomy type "Hardware" identifies a parent for the structure.
• the object 202 has one or more related objects in this structure.
• Embodiments of the invention enable the object 202 to include a tag definition 204 identifying the related objects based on the relationship of the other objects in the hierarchical structure.
• the tag definition 204 identifies one or more objects that are in a lower hierarchy level than the object 202.
• a structure embodying aspects of the invention need not assign a pointer referring to each of the objects in lower levels of the object 202 and need not include additional information as shown in FIG. 1.
• an object 206 defines another taxonomy type "COMl.” This object 206 identifies related objects using definition tags 210 and 212. Referring to FIG.
• the object 206 includes the "parent tag” 210 which includes a first data set identifying a set of one or more objects which is positioned higher (i.e., parent level(s)) in the hierarchical structure.
• the definition tag "parent tag” 210 shows a list of the parent objects of the object 206.
• the definition tag 210 shows that a taxonomy type "Interface” is the parent of the object 206 or is in a higher position in the hierarchical structure than the object 206.
• the tag 210 also includes information associated with a parent of the taxonomy type "Interface," which is the object 202, "Hardware.”
• the list may be an ordered list.
• the first data set also includes one or more data fields for storing information or reference associated with each of the identified taxonomy type.
• the parent tag 210 includes a reference to or information to an entity represented by the taxonomy type "Interface,” which is "Broadcom.”
• the first data set also includes a reference to or information of an entity represented by the taxonomy type "Hardware,” which is "Mboard.”
• the reference may be a link, a path, or a data value referring to the entity.
• the definition tag 212 includes a second data set identifying a set of one or more objects which are positioned lower (i.e., child level) in the hierarchical structure.
• the definition tag 212 shows that the second data set includes a reference to a taxonomy type "Network Card,” and a taxonomy type “Wireless.”
• the second data set also includes a reference to an entity represented by the taxonomy type "Network Card,” “generic Ethernet card” and a reference to an entity represented by the taxonomy type “Wireless,” “WirelessA.”
• embodiments of the invention define a plurality of taxonomy types and classify an object according to at least one of the taxonomy types based on the relationship of the classified object to one or more other objects related thereto.
• the taxonomy type of the classified object is associated with a first reference identifying an actual entity represented by the classified object.
• the "Hardware" taxonomy type includes the first reference identifying "Mboard" as the actual entity represented by the object 202.
• the data structure 302 includes a first data field 304 associated with a taxonomy type.
• the taxonomy type in the first data field 304 may include an interface connection, a network card adapter, or the like for a hardware containment taxonomy.
• Another taxonomy type may be a status, a sub-status, or the like for a terminology taxonomy.
• the data structure 302 also includes a second data field 306 being associated with a first reference to a model instance, where the model instance identifies an entity represented by the first reference 306.
• the data structure 302 includes a third data field 308 storing a data set having data stored in the second data field 306, and the data set identifies a set of one or more objects relative to the classified object in a hierarchical structure.
• the third data field 308 includes a fourth data field 310 identifying a set of one or more objects related to the classified object positioned higher in the hierarchical structure.
• the third data field 308 includes a fifth data field 312 identifying a set of one or more objects related to the classified object positioned lower in the hierarchical structure.
• the third data field 308 may include one or more objects related to the classified object positioned in the same level in the hierarchical structure. It is to be understood that the naming of the first data field 304, the second data field 306, the third data field 308, the fourth data field 310, and the fifth data field 312 is for illustration purposes only and does not restrict or limit the ordering of these data fields in the data structure 302.
• FIG. 3B is a diagram illustrating one implementation of the invention described in FIGS. 2 A and 3 A.
• the first data field 304' shows the taxonomy type "Hardware.”
• the second data field 306 is associated with a first reference to an entity represented by the taxonomy type identified in the first data field 304'.
• the second data field 306' shows "S/N 98234k; manufacture id: 1002,” which identifies a physical instance of a hardware entity represented by the "Hardware" taxonomy type.
• the third data field 308' identifies a set of one or more objects relative to the classified object (e.g., "Hardware") in the hierarchical structure.
• the fourth data field 310' includes one or more objects related to the classified object positioned higher in the hierarchical structure than the classified object. In this instance, the fourth data field 310' in FIG.
• the third data field 308 may include one or more related objects positioned in the same level as the classified object in the hierarchical structure.
• each of the taxonomy types includes rich information associated with the related objects in the hierarchical structure such that a user may obtain information about the structure in one instance.
• embodiments of the invention instantiate or create a single instance of the taxonomy type of the classified object including the information of the classified object and the information represented in the first data set and the second data set.
• XML schema types may be defined as described below:
• FIG. 4 is a block diagram illustrating a system 400 for using the taxonomy structure according to an embodiment of the invention.
• the system 400 includes a memory area 402 for storing data associated with a plurality of taxonomy types 404 (e.g., taxonomy types 202 in FIG. 2A).
• a processor 404 is configured to execute computer-executable instructions for defining the plurality of taxonomy types.
• the processor 406 classifies an object according to at least one of the taxonomy types based on the relationship of the classified object to one or more other objects related thereto. [0035]
• the processor 406 also stores information associated with the classified object in the memory area.
• a first reference is associated with the taxonomy type of the classified object and the first reference identifies an actual entity represented by the classified object.
• the processor 404 also generates a first data set (e.g., data included in the definition tag 210) in the taxonomy type of the classified object.
• the first data set identifies a set of the one or more related objects positioned higher in a hierarchical structure than the classified object.
• the processor 406 generates a second data set in the taxonomy type of the classified object, and the second data set identifies a set of the one or more related objects positioned lower in the hierarchical structure than the classified object.
• the system 400 includes an interface 410 for creating a single instance of the taxonomy type of the classified object including the information of the classified object and the information represented in the first data set and the second data set.
• a user 412 enters a query for traversing the taxonomy to retrieve information associated with the classified objects.
• the processor 406 identifies information in response to the query by identifying the classified object in the taxonomy type and the first data set and the data set in the taxonomy type (e.g., instead of traversing the entire structure as shown in FIG. 1 at 108).
• first data set represented by the third data field 310
• second data set represented by the fourth data field 312
• embodiments of the invention eliminate the need to traverse completely to the end of the structure to respond to the query.
• similar constructs may be defined to store and navigate terminology taxonomies (for example, defining a status, sub-status, symptom hierarchy).
• terminology taxonomy or a containment taxonomy embodiments of the invention define a framework that is useful in other instances, such as file structure representations, business entity representations, business model classifications, or other classification implementations.
• aspects of the invention provide a mechanism for tying the "real world" data (as illustrated in FIG. 6 within the "entity" bracket).
• UML classes or XML schema types are used to associate the "real world" data or entity with the taxonomy type, and embodiments of the invention optimize retrieval of the taxonomy type and the taxonomy hierarchy in a single instance retrieval.
• alternative embodiments of the invention are flexible to enable extension by partners or customers using the same structure illustrated in FIGS. 2A and 3A.
• embodiments of the invention can properly represent all relevant data, such as all hardware vendors may extend the implementation of the hardware taxonomy types to cover their internal inventory systems by classifying objects based on the framework described above.
• embodiments overcome one of the implementation problems involved in referencing related objects in a hierarchical structure.
• taxonomies are typically described in UML or XML schema using direct references to an immediate parent and sometimes, to child references. This is done, for example, where a computer contains its devices, and a device references its containing computer.
• this approach is inefficient - since a programmer has to de-reference or modify the reference of the immediate parent, determine the data item that holds the parent's "parent" (if one is defined at all) and then dereference to get the parent's parent data, ad infmitum.
• FIG. 5 a flow chart illustrates exemplary operations of representing a plurality of objects to form a taxonomy structure according to an embodiment of the invention.
• a plurality of taxonomy types is defined within a taxonomy.
• the taxonomy classifies the plurality of taxonomy types to represent the plurality of objects.
• an object is classified according to at least one of the taxonomy types based on the relationship of the classified object to one or more other objects related thereto.
• a first reference is associated with the taxonomy type of the classified object and this first reference identifies an actual entity represented by the classified object at 506.
• a first data set in the taxonomy type of the classified object is generated, and the first data set identifies a set of the one or more related objects positioned higher in a hierarchical structure than the classified object at 508.
• the parent tag 210 may include the generated first data set.
• FIG. 6 illustrates an exemplary physical containment environment, such as a chassis in a rack in a data center.
• the physical containment example is as follows: A company would like to track the explicit location of its chassis in racks in data centers in buildings in regions (going up to a multi-national region definition).
• the XML Schema definition embodying aspects of the invention provides the details of each of the business/mgmt entities:
• Chassis Serial number, number of slots available/used, any warranty data , ...
• Region - Name e.g., city or country name
• Each of the business or management entities includes a reference to its taxonomy instance or type. And the taxonomy instance or type references back to the business or management entities, and all parents/children, such as shown in
• FIG. 6 For example, a "MyChassisl” is an entity, which is referenced back to a
• the specific taxonomy instance for "MyRack” includes the following data: [0049] 1. Reference to the Rack instance, "MyRack"
• Ordered parents e.g., first data set
• Alternative embodiments of the invention are optimized if an XML processing infrastructure natively understands and participates in supporting "taxonomies.” For example, one mechanism may support alternate names or alternative containment paths for an instance. In this way, the "real world" instance or entity would not have to reference a specific taxonomy instance - but would instead define alternate names/paths that specify the containment hierarchy.
• One example includes a convention for naming of the instances would be required in order to have full functionality.
• the alternative name or alternative containment paths for "COMl" in FIG. 2A may be "DSL card.”
• a "naming convention" using XML enables an easy retrieval of parent/peer data is to deconstruct the name/path to create the substring preceding the last "/” and add the ".xml" string suffix to obtain the parent reference, or the "/" suffix to obtain all peers.
• Embodiments of the invention may be implemented with computer- executable instructions.
• the computer-executable instructions may be organized into one or more computer-executable components or modules.
• Aspects of the invention may be implemented with any number and organization of such components or modules.
• aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein.
• Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
• the articles "a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Databases & Information Systems (AREA)
• Data Mining & Analysis (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Library & Information Science (AREA)
• Document Processing Apparatus (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=39595178

Family Applications (1)

Country Status (6)

Families Citing this family (8)

Citations (4)

Family Cites Families (40)

• 2007
  • 2007-01-10 US US11/621,961 patent/US7689625B2/en not_active Expired - Fee Related
  • 2007-12-31 WO PCT/US2007/089240 patent/WO2008085803A1/en not_active Ceased
  • 2007-12-31 JP JP2009545561A patent/JP4746698B2/ja not_active Expired - Fee Related
  • 2007-12-31 EP EP07866143A patent/EP2118740A4/en not_active Ceased
  • 2007-12-31 CN CN2007800495996A patent/CN101578579B/zh not_active Expired - Fee Related
• 2008
  • 2008-01-08 TW TW097100738A patent/TW200839550A/zh unknown

Patent Citations (4)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events