WO2004079484A2

WO2004079484A2 - Non-hierarchical database

Info

Publication number: WO2004079484A2
Application number: PCT/GB2004/000947
Authority: WO
Inventors: Daniel Hook
Original assignee: Imperial College Innovations Ltd
Priority date: 2003-03-06
Filing date: 2004-03-05
Publication date: 2004-09-16
Also published as: GB0305131D0; WO2004079484A3

Abstract

A content management and storage system provides a manager for storing data relating to pages of information, such as web pages, separately from one another. The manager manages a non-hierarchical structure for the data relating to the pages of information.

Description

NON-HIERARCHICAL DATABASE

The present invention relates to developments in the structure of content management and database systems (hereinafter generally referred to as CMS). More specifically, the invention relates to the manner in which relations between data stored in the CMS may be handled and how complex hierarchy structures may be managed.

For purposes of this document definition of CMS systems will extend to other file storage systems such as databases, spreadsheets and other file storage systems.

Various content management and storage systems, or database systems are available in a wide variety of formats for the purposes of, for example, web site management and management of data to be presented by the web site. Many of these offer quite powerful processing tools in the management and presentation of complex data. Typically, the type of information which might be presented for a web site page include: text files, graphics files, animations (for example GIF animations), Java applets, audio and video information. These systems are usually sufficient for managing and handling such data in relatively simple site structures, for example of a "file tree" type. A typical structure (which is generally referred to by reference numeral 10) of a known CMS is shown in Figure 1. In this particular example a university faculty (the Faculty of Medicine) is modelled. The faculty itself is generally designated by reference 12. As can be seen, the faculty comprises several departments 14. In the CMS system, the Faculty of Medicine 12 and the departments 14 correspond to folders or channels. The web page objects 16 are web pages or postings which may be browsed and otherwise manipulated by the web browser, or computer of a user. From this, we see that web pages 16 are fundamentally different objects to channels 12, 14; a single web page object can exist inside many folder/channel type objects, i.e. it can be accessed from a number of folders/channels 14. Web pages and channels are analogous to, for example, files in directories in the directory tree structure of a computer; a directory is analogous to a channel and a file is analogous to a web page. In a typical directory tree structure, a directory may contain a plurality of files and other directories, but the file would not contain a directory.

It will be understood that the channels 12, 14 themselves might also manifest themselves as web pages in a user's browser. As can be seen, web pages may exist inside many folder/channel type objects. This does not mean that the web page object is "copied" to each channel but that each channel points to the page in question; there is a link from the channel/folder to the page. Such an arrangement has an advantage that updates to a multiply-linked page are simultaneously available through whichever route a user would choose to navigate to that page.

It has been found, however, that known systems have no capability for handling or modelling data which requires a complex hierarchy structure.

The invention is set out in the claims.

The arrangement of the invention offers numerous advantages; for example, channels may be multiply-linked with one another. In embodiments of the invention, the manager is operable to simulate a hierarchy by forming links between data related to respective pages which are related to one another. It has been found that it is possible to link between pages which are related to one another for example, from research groups 34 to web pages 36 by forming links between the relevant portions of data.

In embodiments of the invention, said links are two-way links. Such an arrangement allows the additional benefit of a user being able to navigate around a web site by following links between portions of data relating to one another and being able to navigate back up and down the simulated hierarchy.

In embodiments of the invention, said system is operable to store data in respective entries of a table, and is operable to define links between entries of said table. This allows the data to be conveniently stored in the cells of a table, for which, many tools are readily available to the skilled person.

In embodiments of the invention, said system is operable to define data relating to a page as being related to a respective node, and to define each node in relation to another node to which it is related as being a parent or a child of said other node. This allows the means for defining the structure of the simulated hierarchy; by defining a parent and/or child of a node, a sense of direction from that node (that is, what is "up" or "down" in the simulated hierarchy from that node) may be determined. In the current example, a node could be any of a web page or a channel/folder as used in the preceding examples. The node may also be defined as being a sibling of another node; that is, the nodes have a common parent. Also, the node may be defined as being related to a user and can, for example, contain portions of data which is administered by the user and/or is related to the user (such^" as the user's personal web page).

In embodiments of the invention, said system is operable to render data for a node as a page of information on a display, and to identify links to all nodes related to said node on the display.

Some nodes may have many parents. When the information relating to a node is rendered upon a user's browser mechanism, links to all parents may be displayed on that particular node page. This affords an advantage over traditional methods of browsing such as using hyper links; a hyper link allows travel in one direction only, and when using a web browser, to go back to the parent of a node, a user must click on the browser "back" button. This allows travel only back in the direction through which the user came. Under the present invention, a user may navigate back up the simulated hierarchy to any of the parents of a particular node.

In embodiments of the invention, said system is operable to define a node as having no parents. In such a non-hierarchical file structure, there is a difficulty in obtaining an overall sense of "up" and "down" in the structure, over and above the sense of direction from any particular node. By forcing one or more nodes to have no parents these can be defined to be at the top of the structure; all direction within the structure is therefore taken relatively from these nodes.

In embodiments of the invention, said system is operable to define a set of rights for a node. In a preferred embodiment of the present invention there is offered a distributed rights system, that is, one in which various rights in the management of the system are distributed through the system itself. For example various approval rights may be allocated by, for example, the web site administrator at different levels through the simulated hierarchy.

In embodiments of the invention, said definition of rights includes an application of a filtered view to said node. As an example, it may be that administrators do not wish users at levels lower in the simulated structure than they are at to view any or a part of pages available on the system; for example, sensitive and/or confidential information. Pages containing such information may be specified as being off-limits to users at lower levels or they may be only able to view certain parts of these pages.

In embodiments of the invention, said system is operable to create a node having a parent and a child in a simulated hierarchy and, when a node is created, allowing said created node to have the set of rights of a parent of said created node by default.

In embodiments of the invention, said system is operable to allow a node to define the set of rights for a child of said node.

In this example, when a node is created it inherits the various levels of site administrators from its parent node. When an existing node is associated in a child position to another existing node (i.e. it is moved in the simulated hierarchy so that it has a new parent or parents), levels of site administrators from the new parent node are also inherited to the node and the children of the node; the "owner" of the parent node then has the option to reduce or diminish the rights of the user of the created or moved node as they see fit. The child node assuming the rights of the parent node can be set to occur as a default position or can be set by the parent at a later time. In a preferred embodiment of the invention, the various levels of administrator include the levels of administrator, channel manager and moderator, but is not limited to these levels.

In embodiments of the invention, said system is operable to notify a node when data related to a node which is defined as a child of said node has been updated. When a user at a particular node updates his web page(s), a preferred feature of the invention offered is that, when he saves his data (by whatever means, for example by clicking on an "update" button), notification is sent to the parent of that node that the page has been updated. Such notification may take the form of an e-mail or a network broadcast message or other such means as will be readily recognisable to users skilled in the art.

In embodiments of the invention, a node is responsible for approving said updated data related to a node which is a child of said node. In a preferred embodiment of the present invention it will be necessary for the user at a parent node to approve the content of the updated web page prior to the updated web page going "live" and being visible to other users.

In embodiments of the invention, when a node is created in the simulated hierarchy, said system is operable to check nodes which are potential parents of said node to ensure that it is not defined as a parent of itself. Loops can otherwise occur in the structure which are unresolvable and lead to a significant drop in performance of the system. In embodiments of the invention, said system is operable to move a node in the simulated hierarchy and, when this happens, to check nodes which are or were children of said node to ensure that they are not then defined as being their own parent.

In embodiments of the invention, the system is operable to store data in extensible Mark-up Language (XML) which ensures that the system is readily expandable as XML separates the content of data from the way in which it is presented. This may be seen as offering "future-proofing" of the system, as XML can interface with many different types of data. It also allows for the data to be output in multiple formats, for example, by translation in extensible Stylesheet Language (XSL).

In embodiments of the invention, data are stored in a node related to other nodes as parent or child; on creation of a node with a defined parent and a child node, a check is carried out to establish whether the child node or any child in a subsequent generation that is, a child of the child and so forth, comprises the defined node in which case the child node is excised.

In embodiments of the invention, said system is operable to communicate with other databases or file storage systems and to extract data from said other databases or file storage systems. For example, a user when compiling his own web page may refer to other databases which will be available at his institution; for example, the personnel database holding his personal details such as home address, personal interests, and as a further example he may interface with the institution's security database to retrieve other details such as personal photograph etc. It will be appreciated that features of one aspect of the invention may be applied to features of another aspect of the invention.

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

Figure 1 is a block diagram showing the structure of a typical content storage system; Figure 2 is a block diagram showing the structure of a complex hierarchy structure;

Figure 3 is a block diagram showing the manner in which implementation of the present invention allows a simulated hierarchy structure;

Figure 4 shows the data stored in tabular format with various lengths between related portions of data;

Figure 5 shows a channel node as it might look when rendered on a display device of a user's web browser;

Figure 6 is a block diagram showing the directions of propagation of rights and requests for approval through the simulated structure hierarchy; Figure 7 is a block diagram showing a method of avoiding loops in the structure;

Figure 8 is a flow diagram of the algorithm used to avoid loops in the simulated hierarchy;

Figure 9 shows a user's web page; and Figure 10 is a block diagram showing the manner in which access to resources cascades through a hierarchy. In overview the invention allows management of a complex structure in a CMS. An example of a complex structure may be found in any business or academic institution where, taking the business institution as an example, there may be many layers of management and reporting between workers at lower level and upper management, such as a managing director or CEO. If an institution's web site is supposed to reflect this hierarchical structure, known CMS systems are often inadequate to model these structures. The complex hierarchy structure is shown in Figure 2. Again the example given models the faculty within the university 20. However, this time the faculty 20 may be seen to comprise a separate Divisional 22 section and Research Themes 24 section. Under the divisional structure 22 there are further sub-structural departments 26, 28 which break down further into various research groups 34. The Research Themes 24 as shown, might also consist of various sub-themes 30, 32, which link into various research groups 34 as shown. As can be seen between the departments and sub-themes 26, 28, 30, 32 there are numerous complex links with the various research groups 34. Known CMSs may not be able to handle such complex hierarchy structures; the research groups 34 are channels of the CMS; and the CMS may have difficulty in managing multiply linked channels as required by the example of Figure 2. A further complexity lies in the fact that at web page level 36, we may think of each web page as being associated with the person, each person may, of course, be a member of a number of different research groups and possibly departments and sub-themes. Hence, there is the requirement for a complex multiply-linked structure at a number of levels including the facility for a folder/channel to have many parents.

Referring now to Figure 3a, we can see portions of data 50 to 58 stored in a flat or non-hierarchical structure. Links 30 are shown and these are the means by which structure in the database is defined. The arrangement of Figure 3a is considered the equivalent of that of tree structure of Figure 3b where data portion 50 is at the "top" of the structure and links 30 then define the tree structure.

Referring back to Figure 3a, there is another structural link 34 which might cause difficulty were it to be implemented in the typical directory tree structure of Figure 3b.

Referring now to Figure 4, a preferred embodiment of the present invention is illustrated in that data items 60-76 are stored in the cells of a table 200. Such tables are readily available to those skilled in the art for data storage and manipulation. The hierarchy structure is simulated by the implementation of links 72 as shown. A user browsing through the structure is presented with the web page related to the information contained in cell 60 rendered for viewing on the user's browser. He has the option of following links to any of the other related cells of data 62, 68, 70, in this present example. From 62 he will be able to navigate to 64 or 66. Again, another link 74 is shown to indicate that 60 is also related to the data portion 66. In an embodiment of the present invention, a user when presented with the web page of the data in cell 66 when rendered is able to navigate back up the simulated hierarchy as he is presented with the links for navigating back to either cell 60 or cell 64. It will therefore be seen that the links of the present invention are two-way links, offering navigation in both directions to and from pages which are joined by such links. This offers a distinct advantage over, for example, hyper links which are uni-directional only. Users of a standard web browser utilising hyperlinks would, in the example used, have the option of moving from page 60 to either of pages 64 and 66. If, for example, he chose to go to 66 he would only be able to navigate back up through the simulated structure by clicking on the "back" button of his user browser which would then take him back to page 62. In the present invention he would additionally have the option of going back to page 60.

Referring now to Figures 5a and 5b, a channel of the content management storage system of the present invention is shown when rendered as a web page. Again in this example we are using the Faculty of Medicine of the University as being viewed. In this case, the channel which is viewed is that of "Infectious Disease" the title which is shown at 76. Parents and children of this channel are shown at 78 and 80 respectively. A user when viewing this web page is able to refer back to either of the parents (in this case two parents are shown) of the strategic Research Theme Epidemiology or the Division of the London Campus. Various children 80 are also listed including, highlighted as an example, the mathematical biology research group 82 shown in the list of children 80 and also at 84 in the simulated tree structure 86 on the left hand side of the browser window.

Referring now to Figure 5b, we can view the Mathematical Biology channel web page. This shows the members of the research group on the web page itself at 88 and listed on the simulated tree structure on the left hand side of the window at 90. Clicking any of the links at 88 or at 90 takes the user to the individual web pages of the members of the Mathematical Biology research group, which is discussed below. Again, the parent of this web page is shown at 91 which in this case is the Infectious Disease channel, the web page for which is shown in Figure 5a. The link between the web pages of Figure 5a and 5b is effected by a two-way link as described above. Referring now to Figure 6, the manner in which the distributed rights system is implemented and in which requests for approval of work are made is discussed. The system governs rights such as who is authorised for approving, updating or deleting the relevant pages on the web site or simulated structure. The simulated hierarchy is shown as the analogous tree structure of Figure 3b for the sake of simplicity. It will, of course, be appreciated that this is implemented as the non-hierarchical structure of the present invention.

Rights propagate from data portion 50 down through the tree structure. In this example, the user at node 50 has created pages 52 and 54. On creation of these web pages, the rights associated with the nodes 52 and 54 as default, assume the rights of node 50. As discussed above, this may be done in a manner of ways which includes nodes 52 and 54 assuming the rights of node 50 as a default or the user at 50 setting the rights at these nodes 52, 54 at a later time. The user at node 50 then, of course, may down-grade, diminish or otherwise amend the rights at 52 and 54 as and when he sees fit, or on application from a user associated with the page. A similar process is applicable for the user at node 54 who has created the notes 56 and 58. In general, a node in the structure network will derive its rights largely from its position in the network and in knowing which nodes are its parents. If a node has more than one parent it will, in embodiments of the invention, assume the rights of both parent nodes. Additionally, some extra rights/approvals may be defined on any node. However, such action may potentially affect the children of such a node.

Similarly when, for example, data is updated at node 58, the user at node 58 will save the data. This action may take a number of formats which may, for example, comprise the user clicking on an "update" button. The system then sends a request to the user (who may be an administrator, channel manager or moderator or other pre-defined level of administrator) at node 58 for him to approve the content of the updated web page at 58. This may take a number of formats, for example die system may send the user 54 an e-mail informing of the necessity for him to check the updated content of node 58 or he may be sent a network broadcast message, or other such suitable means. Depending on the user's 54 rights, he is then able to approve the content of the web page 58 before the web page 58 is allowed to go "live" which essentially means that it will be viewable by other users on the system or users accessing the data through the Internet. If the user 54 does not have sufficient rights to approve the content of the web page 58 the notification will be sent to the user at node 50, and so on up through the layer of parents in the simulated hierarchy (if the hierarchy extends above 50) until approval is obtained. Should the user 54 or above not approve of the content of the web page 58, he withholds approval of the web page such that it is not allowed to go "live".

The need for avoiding loops in the simulated structure will now be discussed with reference to Figure 7. This problem could arise where, for example, a node is connected to another, directly or indirectly, as both parent and child in which case rights may propagate around the direct or indirect loop correspondingly.

One node, the root node 150, in the simulated hierarchy is marked out as having no parent node; this node is the entry point to the web site and the base node to which all other relationships can ultimately be considered relative. It is this property of tlie network which allows resolution of any looping problems as this gives "direction" to the network. Without this property, there would be no means of determination of "up" and "down" in the overall hierarchy.

To avoid loops in the structure, it may be decided that links between nodes may not be added to the network system in such a way that closed loops may be formed. A closed loop is one in which, by recursing the tree or simulated hierarchy, the node to be added finds itself as its own parent. Hence the configuration of Figure 7a which, whilst it may look closed, is allowable in the system of the present invention; that is child 152 is a child of root node 150 and so is child 154. However, child 154 is also a child of node 152.

However, the configuration of Figure 7b is not allowable because child 3 162 of child 2 160 is also its parent 156, setting up a loop as shown by dotted line 165.

The structure of Figure 7c is simply a logical extension of the example of Figure 7a and hence is resolvable and therefore allowable in the present system.

With reference to Figure 8, the algorithm for checking for loops in the non- hierarchical data structures will be discussed.

The algorithm which allows us to loop test and consequently ensure that loops will not be formed when channels are added, moved or removed from the simulated hierarchy is the amalgam of two instances of a recursive function. The checking algorithm is invoked when a node is copied, moved, added or removed in/from the simulated hierarchy and the action stopped if the formation of a loop in the simulated hierarchy is detected. In the case where two nodes (having a parent/child relationship) are to be joined by a link, the following checks are made. Figure 8 illustrates a recursive function for the finding all the children of the node. The checking function commences at process step 500 as shown. The child node is retrieved at process step 500. At process step 504 the algorithm checks to see whether or not this potential child node has any children itself. If the answer to this question is yes, that child node is retrieved at process step 506. A further check to see if that child node itself has any further children at process step 508 is then made. If further children are found, then those nodes are also retrieved at process step 510, on a one-by-one basis and added to an output, for example a table. The algorithm loops around process steps 506, 508 and 510 through each successive generation until no further child nodes are found. Each child of the child node to be linked is then checked to determine whether or not it has any sibling nodes and children emanating from them. First, a check is made at process step 514 to see if there are any sibling nodes (that is more children of the child node). If the answer to this question is yes, the process reverts back to the recursive loop of process steps 506, 508 and 510 until all children, siblings and children of siblings have been found and added to the output.

The process itself ends at process step 520.

The recursive function for finding all parents of the parent node to be linked is of similar form, and similarly, the parent nodes of that node are also added to an output.

The SQL code for these two functions is as follows: CREATE PROCEDURE sy_Recurse_Do n

(

©StructureGUID uniqueidentifier

)

AS

DECLARE @ID1 uniqueidentifier, @ID2 uniqueidentifier

DECLARE cur CURSOR LOCAL FOR

SELECT StructureGUID, ParentGUID FROM NSTRUCT_tblParents WHERE

ParentGUID=@StructureGUID

OPEN cur

FETCH NEXT FROM cur INTO @ID1, @ID2

WHILE @@FETCH_STATUS =0

BEGIN

INSERT INTO #CHILD (StructureGUID, ParentGUID) Values (@ID1, @ID2)

EXEC sγ_Recurse_Down ΘID1

FETCH NEXT FROM cur INTO @ID1 , @ID2

END

CLOSE cur DEALLOCATE cur GO

CREATE PROCEDURE sy_Recurse_Up (

ΘStructureGUID uniqueidentifier )

AS

DECLARE SID1 uniqueidentifier, @ID2 uniqueidentifier DECLARE cur CURSOR LOCAL FOR

SELECT StructureGUID, ParentGUID FROM NSTRUCT_tblParents WHERE StructureGUID=@StructureGUID OPEN curO

FETCH NEXT FROM cur INTO @ID1 , @ID2

WHILE @@FETCH_STATUS =0

BEGIN

INSERT INTO #PARENT (StructureGUID, ParentGUID) Values (@ID1, ΘID2)

EXEC sy_Recurse_UP ΘID2

FETCH NEXT FROM cur INTO @ID1 , @ID2

END

CLOSE cur DEALLOCATE cur GO

For the purposes of loop checking, the structure "underneath" the child node to be linked has been explored to find all children of that node. Assuming that the workflow is aheady non-looping, the sy_Recurse_Down function will return a list containing all the nodes which sit below the node in the hierarchy. The sy_Recurse_Up to find the whole structure "above" the parent node to be linked has been explored. Performing a SQL JOIN function (sy_LoopCheck as shown below) to run a comparison between the results of the outputs of these two functions will cause a null response in the case that there are no potential loops and will return some number of results if loops were to be formed by making the link between parent and child, that is, it will detect nodes which are named as both parents of the parent node, and children of the child node. This cannot be allowed, and hence the link may be prevented from being made. Once detected, alternative methods of loop-avoidance may also be made.

The SQL JOIN function for the "syJLoopCheck function is as follows:

CREATE PROCEDURE Sy_LoopChec (

@NewParent uniqueidentifier,

ΘNewChild uniqueidentifier,

@0UT int OUTPUT ) AS

CREATE TABLE #PARENT (StructureGUID uniqueidentifier, ParentGUID uniqueidentifier)

Exec sy_Recurse_Up ΘNewParent

CREATE TABLE #CHILD (StructureGUID uniqueidentifier, ParentGUID uniqueidentifier)

Exec sy_Recurse_Down @NewChild

SELECT

( * ) FROM #PARENT JOIN #CHILD ON #PARENT. StructureGUID=#Child. StructureGUID

JOIN NSTRUCT_tblStruct ON #CHILD.StructureGUID=NSTRUCT_tblStruct .GUID WHERE NSTRUCT_tblStruct . ype_ID=l GO

Referring now to Figures 9a and 9b, a user's web page and the way in which it is presented and interfaces with other available databases will now be discussed. The user's web page 100 as shown in Figure 9a contains a variety of information. In the present example, the user is a member of the Mathematical Biology research group. Other members of the research theme group are also shown on the left hand side of the browser window 122 in the simulated tree structure. In embodiments of the present invention the content store and management system communicates with other databases available to the user; for example, in the case as shown, and referring to Figure 8b, table 200 of data (comprising nodes 60 to 76 of data which further comprise cells of information) is shown. Also shown in Figure 8b are the institution's personnel database 300 and security database 400. The user or web site administrator may configure the user's web page to communicate with these other databases. In the present example, the user may populate the cells 102 - 118 of his web page with information from the personnel database 300; and in the present example his name is shown in cell 102. In frame 118 the user's picture is be shown. The CMS system table 200 communicates with the security database 400 in order to retrieve the user's photograph from the security database 400 to populate the cell 118 with the user's picture 120.

Referring now to figure 10, the manner in which access to resources such as text, graphics and animations etc. are made available through the structure is discussed. Please note this aspect may be implemented in a preferred embodiment of the invention, but may also be used in other structures such as prior-defined tree structures.

The simulated hierarchy is shown as an analogous tree structure, similar to that of figure 3b for the sake of simplicity. It will, of course, be appreciated that this may be implemented as the non-hierarchical structure of the present invention.

Parent node 600 in Figure 10 is shown as having child nodes 602 and 604. The parent node 600 may have one or more, (or indeed a set of) resources available to it, the resources being denoted by reference number 610. The resources may comprise any of a number of different formats of data, such as graphics, font formatting functions, animations and other files. Many of these resources are the tools and building blocks which a user uses to enhance the appearance of his web page In this aspect of the invention, access to resources 610 propagates or cascades down through the system to the nodes 602, 604, 606 and 608 as shown by the lines 611; the users at these nodes may then access the resources 610 as required for use in constructing their respective web pages (not shown).

An advantage of such an arrangement is that if a change is made to one of these resources, the user at node 600 need only change it once at 610; the change then cascades down the system as shown. A change to a common resource is then automatically updated on the web pages of users at nodes 602, 604, 606 and 608.

The users at the nodes lower down the hierarchy access and utilise the resources by utilising a "find resource" function in the authoring tool (not shown) utilised for the web page creation. Upon calling the "find resource" function the user is presented with a pop-up window which contains the resources available to him 610 for adding to his web page. A web site administrator, say the user at node 600, defines the basic outline or format of the web pages that the users at node 602, 604, 606 and 608 will have in order that the all web pages over which he has administrative rights have a uniform or semi-uniform appearance. The users at these nodes 602, 604, 606 and 608, then supplement or stylise their web pages based on this basic outline.

As further illustrated in Figure 10, node 604 also has a parent node 612 as shown. Node 612 has resources available to it, the resources being denoted by 614. In a similar manner as described above, nodes 604, 606 and 608 also obtain access to resources 614. The lines of association showing the manner in which access to this set of resources cascades down through the system are omitted for the sake of clarity, but propagate in a similar manner as is illustrated by line 611.

In preferred embodiments, the child node assumes access to the set of resources of the parent node as a default, say on creation of the child node. It is then also possible for the parent node to further define, add, restrict or otherwise amend the resources available to the child node.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Each feature disclosed in the description, and the claims and drawings may be provided independently or in any appropriate combination.

Claims

Claims:

1. A content management and storage system for storing data relating to a plurality of pages of information comprising: a store for storing data relating to individual pages separately from one another; and a manager for managing a non-hierarchical structure for said data.

2. A content management and storage system according to claim 1, wherein said manager is operable to simulate a hierarchy by forming links between data related to respective pages which are related to one another.

3. A content management and storage system according to claim 2, wherein said links are two-way links.

4. A content management and storage system according to claim 2 or claim 3, wherein said store is operable to store data in respective entries of a table, and is operable to define links between entries of said table.

5. A content management and storage system according to any preceding claim, in which said manager is operable to define data relating to a page as being related to a respective node, and to define each node in relation to an other node to which it is related as being a parent or a child.

6. A content management and storage system according to claim 5, in which said system is operable to render data for a node as a page of information on a display, and to identify links to all nodes related to said node on the display.

7. A content management and storage system according to claim 5 or claim 6, in which said system is operable to define a predetermined node as having no parents.

8. A content management and storage system according to any preceding claim, in which said system is operable to define a set of rights for a node.

9. A content management and storage system for storing data related to a plurality of pages of information, said system being operable to: store data; define data as being related to a respective node; and define a set of rights for a node.

10. A content management and storage system according to claim 9, wherein said definition of rights includes an application of a filtered view to said node.

11. A content management and storage system according to claim 9 or claim 10, in which said system is operable to create a node having a parent and child in a simulated hierarchy and, when a node is created, allowing said created node to have the set of rights of a parent of said created node by default.

12. A content management and storage system according to any of claims 9 to 11, in which said system is operable to allow a node to define the set of rights for a child of said node.

13. A content management and storage system according to any of claims 9 to 12, in which said system is operable to notify a node when data related to a node which is defined as a child of said node has been updated.

14. A content management and storage system according to claim 13, in which said system is operable such that a node is responsible for approving said updated data related to a node which is a child of said node.

15. A content management and storage system according to any of claims 9 to 14, in which, when a node is created in the simulated hierarchy, said system is operable to check nodes which are potential parents of said node to ensure that it is not defined as a parent of itself.

16. A content management and storage system according to any of claims 9 to 15, in which said system is operable to move a node in the simulated hierarchy and, when this happens, to check nodes which are or were children of said node to ensure that they are not then defined as being their own parent.

17. A content management and storage system according to any preceding claim, in which the system is operable to store data in XML, or in which said system is operable to communicate with other databases or file storage systems and to extract data from said other databases or file storage systems.

18. A content management and storage system operable to store data in a node related to other nodes in a data structure as parent or child and, prior to creation of a link between a parent and a child node, carry out a check to establish whether the forming of said link would create a loop in said structure.

19. A content management and storage system according to claim 18, operable, in order to carry out said check, to make a comparison between a first set of nodes comprising parents of the parent node and a second set of nodes comprising children of the child node and, to identify whether a node appears in both of said first and second sets.

20. A content management and storage system according to claim 18 or claim 19, operable to prevent said link being made if the forming of said link would create a loop.

21. A content management and storage system for storing data related to a plurality of pages of information, said system being operable to: manage a structure for said data; define one or more resources for a first node in said structure; and make said resources available to a second node associated with said first node in said structure.

22. A content management and storage system according to claim 21, wherein first node is hierarchically higher in said structure than said first node.

23. A content management and storage system according to claim 21 or claim 22, in which said system is operable to create a second node having a parent tlie first node and, when the second node is created to make the resources of the first node available to the second node by default.

24. A content management and storage system according to any of claims 21 to 23, in which said system is operable to allow a first node to define the resources available to a node hierarchically higher node.

25. A method of storing and managing data relating to a plurality of pages of information comprising: storing data relating to individual pages separately from one another; and managing a non-hierarchical structure for said data.

26. A method according to claim 25, further comprising storing said data and managing the stimulation of a hierarchy by forming links between data related to respective pages which are related to one another.

27. A method according to claim 26, wherein said links are two-way links.

28. A method according to claim 26 or claim 27, further comprising storing said data in respective entries of a table and defining links between entries of said table.

29. A method according to any of claims 25 to 28, further comprising defining data relating to a page as being related to a respective node, and defining each node in relation to an other node to which it is related to as being a parent or a child.

30. A method according to claim 29, further comprising rendering data for a node as a page of information on a display, and identifying links to all nodes related to said node on the display.

31. A method according to claim 29 or claim 30, further comprising defining a predetermined node as having no parents.

32. A method according to any of claims 25 to 31, further comprising defining a set of rights for a node.

33. A method of storing and managing data related to a plurality of pages of information comprising: storing data; defining data as being related to a respective node; and defining a set of rights for a node.

34. A method according to claim 33, wherein the step of defining rights for a node includes applying a filtered view to said node.

35. A method according to claim 33 or claim 34, further comprising creating a node having a parent and a child in a simulated hierarchy and, when such a node has been created, allowing said created node to have the set of rights of a parent of said created node by default.

36. A method according to any of claim 34 or claim 35, further comprising allowing a node to define the set of rights for a child of said node.

37. A method according to any of claims 34 to 36, further comprising notifying a node when data related to a node which is defined as a child of said node has been updated.

38. A method according to claim 37, further comprising making a node responsible for approving said updated data related to a node which is a child of said node.

39. A method according to any of claims 33 to 38, further comprising, when a node is created, checking nodes which are potential parents of said node to ensure that it is not defined as a parent of itself.

40. A method according to any of claims 33 to 39, further comprising moving a node in the simulated hierarchy and checking nodes which are or were children of said node to ensure that they are not then defined as being their own parent.

41. A method according to any of claims 25 to 40, in which data is stored in XML.

42. A method according to any of claims 25 to 41, further comprising communicating with other databases or file storage systems and extracting data from said other databases or file storage systems.

43. A method of storing data in a node related to other nodes in a data structure as parent or child comprising, prior to creation of a link between a parent and a child node, carrying out a check to establish whether the forming of said link would create a loop in said structure.

44. A method according to claim 43 , further comprising, in order to carry out said check, making a comparison between a first set of nodes comprising parents of the parent node and a second set of nodes comprising children of the child node and identifying whether a node appears in both of said first and second sets.

45. A method according to claim 43 or claim 44, further comprising preventing said link from being made if the forming of said link would create a loop.

46. A method of storing and managing data related to a plurality of pages of information comprising: managing a structure for said data; defining one or more resources for a first node in said structure; and making said resources available to a second node associated with said first node in said structure.

47. A method according to claim 46, wherein said first node is hierarchically higher in said structure than said second node.

48. A method according to claim 46 or claim 47, further comprising creating a node having as a parent the first node and making the resources of the first node available to the second node by default.

49. A method according to any of claims 46 to 48, in further comprising allowing a fhst node to define the resources available to hierarchically lower node.

50. A content management system as herein defined with reference to the accompanying drawings.

51. A method as herein defined with reference to the accompanying drawings.

52. A computer program configured to implement a method as claimed in any of claims 25 to 49.

53. A computer readable medium storing a computer program as claimed in claim 52.