Method and System for Defining a Heirarchical Structure

Abstract

A hierarchical structure is provided. The hierarchical structure includes object items (301-306) for objects (101-106) located in the hierarchical structure, each object item (301-306) having a name and a link (321-326). The hierarchical structure also includes node items (311-314) each having a name of a hierarchical path name. A node item (311-314) is provided for each unique path name in the hierarchical structure and the link (321-326) of an object item (301-306) links to a single node item (311-314) having the hierarchical path name of the object (101-106).

Description

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described, by way of examples only, with reference to the accompanying drawings in which:

FIG. 1A is a representation of a simple hierarchy as known in the prior art;

FIG. 1B is a representation of the hierarchy of FIG. 1A with each node having references to its parent and child nodes;

FIG. 1C is a representation of the hierarchy of FIG. 1A with each node having an attribute of its path name;

FIG. 2A is a block diagram of a first embodiment of a system in accordance with the present invention;

FIG. 2B is a block diagram of a second embodiment of a system in accordance with the present invention;

FIG. 3 is representation of the items represented in the system of FIGS. 2A and 28 in accordance with the present invention: and

FIGS. 4A to 4E are flow diagrams of methods in accordance with the present invention.

DETAILED DESCRIPTION

A system is provided for representing objects such as folders or directories and documents or files in a hierarchical structure. The system may be implemented in a content management system, a file system, a database system, an asset management systems, a document management systems, or any other system in which a hierarchical representation of objects requires searching and manipulation.

Referring to FIG. 2A, a first embodiment of a system 200 is shown having a data storage means 201, a management system 202 for managing content stored in the data storage means 201, and a user interface 203 for a user to interact with the management system 202.

As an example., the management system 202 may be a content management system for organizing and facilitating collaborative creation of documents and other content. In one embodiment, a content management system may be a web application used for managing web sites and web content. In another embodiment, a content management system may be used for storage and sourcing of documentation for an organization.

As another example, the management system 202 may be a disk file system managing the storage of files in disk storage.

The data storage means 201 may be a database including flat file databases, relational databases, object oriented databases, or an XML-based data repository, or a files storage system such as disk storage.

The data storage means 201 may be local to the management system 202, or it may be remote to the management system 202 with communication via a network.

The management system 202 uses items 205 to structure and manage stored information. An item 205 is anything storable on the management system 202. To enable items 205 to be subsequently located and manipulated meta-data is associated with each item stored. Meta-data in this sense is a set of properties each having a name and value. A programmer provides an “item type” or template for the kinds of items 205 they want to store, which defines the names and data-types of those meta-data properties. When actual instances of those “item types” (ices the items themselves) are stored, values are assigned to properties associated with that item.

Various types of properties are possible but the two types used here are “string” (free form text) and “link” (a double-ended pointer from one item to another). String properties are very common and so generally fairly simple and efficient in their underlying implementation, particularly for searching. Searching strings based on pattern matching is a common idiom and generally easy to understand.

Items 205 may take different forms. Items may represent objects either with or without content.

A first type of item 220, 221, 222 may be a document or file that has text content. An item 220, 221, 222 is created to represent the document in the management system 202 and has properties defining meta-data of the document. The item 220, 221, 222 may store the content itself or may connect the item 220, 221, 222 to the document content 210, 211, 212 stored elsewhere, for example, as stored in a data storage means 201.

A second type of item 223, 224 may be a folder or directory that maintains a structure, such as a hierarchy structure, and enables other documents or folders to be nested within it. This second type of item 223., 224 has properties defining meta-data of the folder, but does not have stored content.

In the described system, a further type of item 230, 231, 232 referred to as a node item is defined, which represents and maintains the hierarchical structure that has been defined. Each node item 230, 231, 232 has an property of a path name through the hierarchy.

Items 220-224 of the first and second type for documents and folders each have a property in the form of a link 240 to a node item 230, 231, 232.

Node items 230, 231, 232 have sets of links 250 for the items 220-224 which have the name of the node item as its path in the hierarchy. Optionally, the node items 230, 231, 232 have sets of links to other node items that are parent or child nodes of the node item.

The three items types may be defined as follows with meta-data properties including:

DocumentItem

• • Name: String
  • Node: Link

FolderItem

• • Name: String
  • Node: Link

NodeItem

• • Path: String
  • Contents: Set of Links

Items of type “NodeItem” are created to represent and maintain the hierarchical structure that has been defined. The “path” property of these is a text string containing the full path name of this node's position in the hierarchical tree. In this implementation a “/” character is used to separate the names of the nodes that form the path.

Items of type “DocumentItem” or “FolderItem” are created to represent the actual folders or documents defined. The “name” property of these is a text string containing just the document or folder name. The “node” property is a link to the “NodeItem” that represents this document or folder's position in the hierarchy. To correspond with this the “contents” property on the “NodeItem” is a set of links which will include a link back to the document or folder item.

Referring to FIG. 28, a second embodiment of a system 250 is shown having a data storage means in the form of a relational database 251, a database management system 252 for managing content stored in the database 251, and a user interface 253 for a user to interact with the management system 252.

The database management system 252 includes four tables, one to represent documents 261, one to represent folders 262 one to represent nodes 263, and one to represent links 264 (from documents/folders to/from nodes).

There is one row in the document table 261 for each document one row in the folder table 262 for each folder, one row in the node table 263 for each node and one row in the links table 264 for each link. The rows in the documents and folders tables 261262 have a column containing a unique “key” for each document/folder and a column for the document/folder name. The tables also have any other columns needed.

The rows in the nodes table 263 have a column containing a unique “key” for each node and a column for the path name. Since the path names are themselves unique, the path name column itself may be used as the key.

Each row in the links table 264 has a column for each end of the link. These are foreign-key relations to the keys in the document/folder tables 261, 262 and the node table 263.

Many operations can be reduced to simple text pattern matching against the names columns in the database tables. This is usually very efficient in a typical relational database system.

Referring to FIG. 3, the hierarchical structure 100 of FIG. 1A is shown as items. The items are representations of objects, for example, content management system items, or database table entries, which are used to define the hierarchical structure.

Each item shows quotes representing the value of a name of each of the items. The name may be, for example, an attribute of the item or a name associated with a database table entry. The arrows between the items represent links of the items. The links may be, for example, provided as an attribute of an item or as a link defined in a database table of links between database table entries.

The items 301-306 on the left include the items 301-303 representing the three folders (folders 101, 103, 104 of FIG. 1A) and the items 304-306 representing the three documents (102, 105, 106 of FIG. 1A). The additional items 311-314 (shown with curved corners) are node items having a value of a data path. Item 311 has a of value “/”, item 312 has a of value “/FO”, item 313 has a of value “/FO/F1”, and item 314 has a of value “/FO/F2’.

Each of the items 301-306 representing an object (a folder or document in this case) has a link 321-326 to the one of the node items 311-314 which provides the object's data path.

Folder F0 is the root node and therefore item 301 is linked 321 to the node item 311 for data path “/”. Items 302-304 for folder F1, folder F2 and document D1 are each linked 322-324 to the node item 312 for the data path “/F0”. Items 305, 306 for documents D2 and D3 are each linked 325, 326 to the node item 314 for the data path “/F0/F2”. The node item 313 for the data path “/FO/F1” does not have a link to it from an item representing an object as there are no objects in the hierarchy with this data path.

The node items 311-314 representing the data paths enable quick and efficient query, search and manipulation of the hierarchy for most typical operations.

The following example operations are described using the items representing the objects and data paths:

• • Obtaining the full path name for a document.

This operation requires following one link from the item representing the document. The attribute or name value of the item representing the document and the attribute or name value of the node item representing the data path are concatenated to obtain the full data path name for the document.

FIG. 4A shows a flow diagram 410 of this operation. Start 411 at the item representing the object for which a full path name is required, Record 412 the name value of the item. Follow 413 the link to the node item. Record 414 the name value of the node item. Concatenate 415 the record 412 of the name value of the starting item and the record 414 of the name value of the node item to obtain the full data path for the object.

For example, in FIG. 3, the full path name for document D2 is obtained by starting at item 305 for document D2, following the link 325 to item 314 which has the name value “/F0/F2”. Concatenating the name values of item 305 (“D2”) and item 314 (“/F0/F2”) to give the full path name of “/F0/F2/D2”.

• • Moving a document to a new folder.

This requires changing one link between the document item and the matching node item.

FIG. 48 shows a flow diagram 420 of this operation. Starting 421 at the item representing the document to be moved, remove 422 the link to the current node item. Add 423 a link between the document item and the new node item representing the new location of the document.

For example, in FIG. 3, document D2 can be moved from folder F2 to folder F1. The link 325 from item 305 to node item 314 is removed. A new link is added from item 305 to node item 313 which has the attribute of value “/FO/F1”.

• • Searching for all documents within a folder.

This requires following a single level of links from the node item for the folder back to the child documents items.

FIG. 4C shows a flow diagram 430 of this operation. Start 431 by following the link from the folder item to the node item. Construct the full path name 432 by concatenating the node item path name and the folder item name. Search 433 for the node item with a path name matching the full path name. Follow a link 434 from the node item to a document item and record the document name. Determine 435 if there is another link. If so, loop 436 and repeat step 434. If there are no more links, report 437 the recorded document names.

For example, in FIG. 3, a search may be required for all documents within folder F2. Starting at the folder item 303 for F2, the link 323 is followed to node item 312 for data path “/F0”. The full path name for folder F2 can now be constructed by concatenating the node path and folder name to give “/F0/F2”. A search is done for the node item with a path name that exactly matches “/F0/F2” and item 314 is found. The links 325, 326 are followed back to document items 305, 306 and the document names “D2” and “D3” are recorded.

• • Searching for all documents in folders with names matching a pattern

This is a two step process: first find the collection of node items whose name attributes include the required pattern, and secondly, follow the links from each node item to all document items and record the document names.

FIG. 4D shows a flow diagram 440 of this operation. A search 441 is carried out for all node item names including a name pattern. For a node item located 442, follow a link 443 to a document item and record the document name. Determine if there are any more links 444 from the node item and, if so, loop 445 to repeat step 443 for the next sink. If there are no more sink items for the node item, determine 446 if there is a next node item including the name pattern. If so, loop 447 to repeat from step 442 for the next node item. If not, report 448 all recorded document names.

For example, in FIG. 3, a search may be made for all documents in folders with the name “F . . . ”. The first step performs a search against the node items to find all node items whose path name matches a text pattern “%/F%”, where “%” represents any sequence of zero or more characters. This locates the three node items 312, 313 and 314. From these three node items, follow the links back to document items 324, 325 and 326 to find documents 304, 305, 306. Document names “D1”, “D2” and “D3” are recorded.

• • Renaming a folder

This is a slightly more complex operation which involves renaming the folder item itself and updating the path name attribute in the node items for all items at and below that folder in the hierarchy.

This will typically involve updating several node items which will require locks over those items; however the number of folders is expected to be small compared with the number of documents and these locks are expected to only be required for a short time.

FIG. 4E shows a flow diagram 450 of this operation. The folder item is renamed 451 and the link to the node item is followed 452 to construct the full path name of the folder. Search 453 for all node items whose path name includes the full path name of the folder. For a node item located, change 454 the path name to the new name. Determine if there is a next node item 455 and, if so, loop 456 to repeat step 454. If not end the process 457.

For example, if folder “FO” is to be renamed “F”, folder 301 is renamed “F” and link 321 is followed to construct the original full path name for the folder, i.e. “/F0”. A search of the node items is done to find all node items whose path name matches the pattern “/F0/%”, where “%” represents and sequence of zero or more characters. This locates three node items 312, 313 and 314. The path names of all these node items are changed by replacing the initial “/FO” text with “/F”.

• • Moving a folder within the hierarchy

This is a variation on renaming a folder.

The described method and system provide a technique for imposing a hierarchical structure on objects. The objects may not themselves be stored in a hierarchical form. The hierarchical structure enables the efficient processing of the objects by using string matching techniques.

The invention can take the form of an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

The invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus or device.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk read only memory (CD-ROM), compact disk read/write (CD-RAN), and DVD.

Improvements and modifications can be made to the foregoing without departing from the scope of the present invention.

Claims

1. A method for defining a hierarchical structure, comprising: providing object items (301-306) for objects represented in the hierarchical structure (100), each object item (301-306) having a name and a link (321-326);providing a node item (311-314) having a name in the form of a hierarchical path name, wherein a node item (311-314) is provided for each unique path name in the hierarchical structure (100);wherein the link (321-326) for an object item (301-306) links to a single node item (311-314) having the hierarchical path name of the object.

2. A method as claimed in claim 1, wherein each node item (311-314) has a link (321-326) to one or more object items (301-306).

3. A method as claimed in claim 1, wherein the object items (301-306) and node items (311-314) have properties, wherein the names and links are provided as properties.

4. A method as claimed in claim 1, wherein the object items (301-306) and node items (311-314) are entries in a table (261-263), the entries having a name, and the links (321-326) are provided in a table (264) defining the start and end of the link.

5. A method as claimed in claim 4, wherein an object item (301-303) represents an object that defines the structure and contains nested objects.

6. A method as claimed in claim 4, wherein an object item (304-306) represents an object that has an associated content (210-212).

7. A method as claimed in claim 2, including following the link (321-326) from an object item (301-306) to determine the path name of an object.

8. A method as claimed in claim 2, including searching objects in the hierarchical structure (100) by following links (321-326) between object items (301-306) and node items (311-314).

9. A method as claimed claim 2, including manipulating objects in the hierarchical structure (100) by changing links (321-326) between object items (301-306) and node items (311-314).

10. A method as claimed in claim 2, including searching objects in the hierarchical structure (100) by pattern matching of object item (301-306) and node item (311-314) names.

11. A computer containing a stored hierarchical data structure, comprising: a plurality of object items (301-306) for objects represented in the hierarchical structure (100), each object item having a name and a link (321-326);a plurality of node items (311-314), each having a name in the form of a hierarchical path name, wherein a node item (311-314) is provided for each unique path name in the hierarchical structure (100);wherein the ink (321-326) of an object item (301-306) links to a single node item (311-314) having the hierarchical path name of the object.

12. A computer as claimed in claim 11, wherein each node item (311-314) has a ink (321-326) to one or more object items (301-306).

13. A computer as claimed in claim 11, wherein the object items (301-306) and node items (311-314) have properties, wherein the names and links are provided as properties.

14. A computer as claimed in claim 12, wherein the object items (301-306) and node items (311-314) are entries in a table (261-263), the entries having a name, and the links (321-326) are provided in a table (264) defining the start and end of the link.

15. A computer as claimed in claim 12, wherein an object item (301-303) represents an object that defines the structure and has nested objects within it.

16. A computer as claimed in claim 12, wherein the object item (304-306) represents an object that has an associated content (210-212).

17. A storage medium containing program instructions which when executed by a computer cause the computer to perform a method for defining a hierarchical structure, comprising: instructions for providing object items (301-306) for objects represented in the hierarchical structure (100), each object item (301-306) having a name and a link (321-326);instructions for providing a node item (311-314) having a name in the form of a hierarchical path name, wherein a node item (311-314) is provided for each unique path name in the hierarchical structure (100);wherein the link (321-326) for an object item (301-306) links to a single node item (311-314) having the hierarchical path name of the object.

18. A storage medium as claimed in claim 17 wherein each node item (311-314) has a link (321-326) to one or more object items (301-306).

19. A storage medium as claimed in claim 17, wherein the object items (301-306) and node items (311-314) have properties, wherein the names and links are provided as properties.

20. A storage medium as claimed in claim 18, wherein the object items (301-306) and node items (311-314) are entries in a table (261-263), the entries having a name, and the links (321-326) are provided in a table (264) defining the start and end of the link.

21. A storage medium as claimed in claim 18, wherein an object item (301-303) represents an object that defines the structure and contains nested objects.

22. A storage medium as claimed in claim 18, wherein an object item (304-306) represents an object that has an associated content (210-212).

23. A storage medium as claimed in claim 18, including following the link (321-326) from an object item (301-306) to determine the path name of an object.

24. A storage medium as claimed in claim 18, including searching objects in the hierarchical structure (100) by following links (321-326) between object items (301-306) and node items (311-314).

25. A storage medium as claimed claim 18, including manipulating objects in the hierarchical structure (100) by changing links (321-326) between object items (301-306) and node items (311-314).

26. A storage medium as claimed in claim 18, including searching objects in the hierarchical structure (100) by pattern matching of object item (301-306) and node item (311-314) names.