as discussed in the preamble , in traditional prior art systems , item information is stored in data tables that have a pre - defined number of columns , each of which can be assigned to describe a particular property ( attribute ) of the item . fig1 illustrates a schematic example of a standard database table for providing information ( attributes 12 b , 12 c , etc ) on items 12 a . if a system has 10 columns in its item table , then it can have up to 10 data elements that can be used to define item - characteristics like : 1 . catalogue_number ; 2 . product_short_name ; 3 . product_description ; 4 . retail_price ; 5 . wholesale_price ; 6 . unit_of_measure ; 7 . pack_size ; 8 . product_image ; 9 . size ; 10 . colour if the user requires addition of data elements to describe the products , such as , length , height , width , weight , handling instructions etc . the system will have to be re - programmed , or if the user has different classes or types of products that have different characteristics , such as , material cost ; freight cost ; tax ; gst etc . then new tables or more data elements need to be added to the existing table , which involves re - programming effort . if a retailer sells books , cds , shirts and confectionery , the data elements that describe these different item classes may be : books : isbn , author , title , rrprice , number of pages , year published ; publisher ; language : edition ; uom cds : catalogue number , artist , album title , rrprice , number of tracks ; year released ; record company ; language ; volume ; uom shirts : label , designer , article name , rrprice , style ; cut ; colour ; season ; material 1 ; material2 ; care instructions ; ironing instruction ; size chest ; size collar ; uom candy : brand , type , article name , rrprice , colour ; ingredients 1 ; ingredients 2 - etc ; serving instruction ; pack size ; gross weight ; net weight ; uom ; use by date the above example illustrates that , to cater for the description of different product classes , traditional systems will need to be pre - defined with either one large database table that has hundreds of columns ( one table with all the data elements combined ) or many smaller database tables , one for each product type with only those data elements relevant for the product type ( that is , a books table , cds table , shirts table , candy table ). in either case the maintenance of product data becomes highly complex , cumbersome and slow . furthermore , the data elements can not be grouped or re - grouped without programming changes to the system or database as old products classes or phased - out and new ones phased - in . note also , that there may also be duplication of data elements ( such as rrprice , uom ). a description of an embodiment of the present invention will now be given with respect to fig2 and 3 . in fig2 an electronic catalogue 110 of the preferred embodiment of the present invention comprises a first database table 112 in which particular items e . g . 14 are associated with their respective property set identifiers , e . g . 16 . the electronic catalogue 10 also comprises a second database table 18 in which a set of properties , e . g . 20 , 22 and 24 are associated with property set identifiers , e . g . 16 . it will be appreciated by a person skilled in the art that by way of provision of the first database table 112 and the second database table 18 , a multitude of property sets having different sets of properties associated with them can be incorporated into the electronic catalogue 110 , without having to change the hard - coding ( i . e . the column headings ) of the database tables 12 and 18 . if a new item 26 is to be added to the electronic catalogue , for which none of the previous property set is suitable , a new property set identifier 28 is added in the database table 112 . at the same time , a new set of properties 30 , 32 and 34 are associated with the new property set identifier 28 in the second database table 18 . it is noted here that the same property can belong to different sets of properties associated with respective ones of the property set identifiers , see e . g . property 20 , 34 . the electronic catalogue 110 further comprises a third database table 36 in which the actual values , e . g . 38 of properties e . g . 20 of a particular item e . g . 14 are stored . editing of data in the electronic catalogue 110 is facilitated through a user interface in the form of a desk top computer 40 . it will be appreciated by a person skilled in the art that the addition of items and / or property sets in the above described embodiment does not require any hard coding to effect changes in the various database tables 112 , 18 and 36 . rather , the addition of data simply requires entering of data into the existing , hard coded database tables 112 , 18 and 36 . accordingly , this is a task which does not require specific programming skills . this makes the editing of the electronic catalogue 110 easy and cost effective . with the present invention , therefore , different ontologies “ templates ” can easily be created for new item classes without programmatic changes . in the example of fig2 item classes will be associated with the same ontology ( property set ). for example items 1 through 20 may all be cars . the associated property set identifier 123 may include a property set which includes colour ( a ), engine size ( b ) car type ( e . g . saloon , sports car , etc , data element c ). any item class “ car ” associated with property set identifier 123 will have the same ontology . this ontology can be added to by adjusting table 18 to add in another data element in addition to data elements 20 ( a ), 22 ( b ) and 24 ( c ). this is a simple matter of adding the data element and associating it with the same property set identifier 123 . the appropriate value for the data element is inserted in table 36 , against the appropriate item . all items of the same class can be accessed via the property set identifier . the ontology can be extended by manipulating table 18 . items of different classes can be included in the table 112 . any items may be included , e . g . cars , books , clothes , etc , all in the same table . different data classes can be associated with different ontologies ( property sets ). the number of ontologies that can be supported is basically unlimited . another feature of the present invention is that different ontologies can be defined for the same item classes , the ontologies being user defined to customise data elements that are visible to particular users i . e . what “ perspective ” a particular user has . for example , what information a user is able to view may depend on a particular security level i . e . the higher security level , the more information that a particular user is able to view . particular users , therefore , may only be able to utilise particular ontologies for particular item classes . each user may have a different “ perspectives ”. this can easily be handled with the present invention by defining different ontologies for different item classes associated with different user perspectives . in more detail , in the present invention , without requiring programming changes ( hard coding , changing of columns of the database ) there is no limit on : the number of data elements ( or attributes ) that can be defined how the user can use these ontologies to customise the data elements that are visible for every product item and to every user ( in “ perspectives ”) isbn , author , title , rrprice , number of pages , year published ; publisher ; language ; edition ; uom ; catalogue number ; artist , album title , number of tracks ; year released ; record company ; language ; volume ; label ; designer ; article name ; style ; cut ; colour ; season ; material 1 ; material 2 ; care instructions ; ironing instruction ; size chest ; size collar ; brand , type , article name , colour ; ingredients 1 ; ingredients 2 etc ; serving instruction , pack size ; gross weight ; net weight ; use by date these data elements can then be “ assembled ” into a template called an “ ontology ” for each product class , for instance : books ontology has data elements : isbn , author , title , rrprice , number of pages , year published ; publisher ; language ; edition ; uom cds ontology has data elements : catalogue number ; artist , album title , number of tracks ; year released ; record company ; language ; volume ; uom shirts ontology has data elements : label ; designer ; article name ; wholesale price ; first cost ; packaging cost ; freight cost ; rrprice ; promotion price ; style ; cut ; colour ; season ; material 1 ; material 2 ; care instructions ; ironing instruction ; size chest ; size collar ; uom candy ontology has data elements : brand ; type ; article name , rrprice ; colour ; ingredients 1 ; ingredients 2 etc ; serving instruction , pack size ; gross weight ; net weight ; uom , use by date additionally , when new product classes are required , new data elements can be added and new ontology templates can be created using any data element from the list of user - defined elements . another application of this is to create different ontologies to control the amount of product information that different users can see in their ‘ perspective ’ of the catalogue . for shirts , the catalogue manager can create different shirts ontologies for different users such as , customers , suppliers , accounting staff , sales staff etc . shirts ontology has data elements : label ; designer : article name ; wholesale price ; first cost ; packaging cost ; freight cost ; rrprice ; promotion price ; style ; cut ; colour ; season ; material 1 ; material 2 ; care instructions ; ironing instruction ; size chest ; size collar ; uom shirts ontology for customer 1 has data elements : label ; designer ; article name ; rrprice ; style ; cut ; colour ; season ; material 1 ; material 2 ; care instructions ; ironing instruction ; size chest ; size collar ; uom shirts ontology for customer 2 has data elements : label ; designer ; promotion price ; style ; cut ; colour ; season ; material 1 ; care instructions ; ironing instruction ; size chest ; size collar ; uom . shirts ontology for accounting staff has data elements : label ; designer ; article name ; wholesale price ; first cost ; packaging cost ; freight cost ; rrprice ; style ; cut ; colour ; season ; size chest ; size collar ; uom shirts ontology for sales staff has data elements : label ; designer ; article name ; rrprice ; promotion price ; style ; cut ; colour ; season ; material 1 ; material 2 ; care instructions ; ironing instruction ; size chest ; size collar ; uom . turning now to fig3 there are shown two separate electronic catalogues 50 , 52 . each of the catalogues 50 , 52 is substantially structured in the same way as the electronic catalogue 110 of fig2 described above . in the following , different scenarios for transferring items or groups of items between the electronic catalogues 50 , 52 will be described . firstly , if an identical property set exists in catalogue 52 to the one to which the item to be transferred from catalogue 50 belongs , the transfer is a matter of copying the relevant data from the database table 60 of catalogue 50 , in which the actual values of properties are stored for the particular items ( compare database table 36 of fig2 ). alternatively , should an identical property set exist in catalogue 52 but a different property set identifier is being used , the transfer will require execution of a rule : all items of the catalogue 50 having property set identifier 246 should be transferred into catalogue 52 with the property set identifier being changed to 789 , which is the property set identifier in catalogue 52 which is associated with an identical set of properties as used for those items in catalogue 50 . this rule , which is initially manually entered by a user of the catalogue 52 is subsequently stored in a rule database 76 . the rule database 76 is accessible by both catalogues 52 and 50 . any future transfer can utilise prior rules established by different users . the rule database 76 is arranged to notify a future user upon entering of a particular transfer request if a rule is already stored in the rule database 76 for a corresponding previous request . the rule database 76 is further arranged to apply the stored rule automatically in executing the new transfer request . the rule database 76 further comprises means for generating “ reverse ” rules for transfer in an opposing direction between the catalogues 52 , 50 on the basis of a transfer rule created manually for transfer in one particular direction . it will be appreciated by a person skilled in the art that the principle of rule - based transfer of data described above also applies to a scenario where it is desired to transfer data between the catalogues 50 , 52 where certain values need to be changed due to differences in the properties associated with a particular property set identifier . this will also involve the mapping of relations between properties of the catalogues 50 , 52 . for example , if a length property 78 of a classification group 79 in catalogue 50 is in centimetres whilst the length property 80 of a corresponding property set in catalogue 52 is in inches , a transfer rule would have to be applied in which the value 82 is converted into inches during transfer into a value 86 in database table 88 of catalogue 52 . it will be appreciated that conversion of certain values of properties would in that case be favourable rather than creating an entirely new property set in catalogue 52 , which would be the easier transfer . this is because it would be advantageous to keep items which should belong into the same property set by their nature together in the same property set . different examples of where applying rules to conform the transferred data is preferable over simply adding the data “ as received ” from another database table include where properties are identified by different names but their meaning is the same . this may be due e . g . simply because of different spelling in different languages , such as colour versus colour . it will be appreciated by a person skilled in the art that numerous variations and / or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described . the present embodiments are , therefore , to be considered in all respects to be illustrative and not restrictive . for example , in the embodiment described in fig3 if one of the electronic catalogues was not in a form embodying the present invention , the other electronic catalogue could further comprise means for extracting properties and their values from data entries of the other electronic catalogue . the extraction in turn could be facilitated by rules stored in a further database table . accordingly , an intelligent electronic catalogue system can be provided which can be made a tool for accessing information from a large variety of electronic catalogues through a single user interface . it will be appreciated by a person skilled in the art that the arrangement disclosed in the description and figures can be used very flexibly . for example table 18 of fig3 establishes the relationship between ontologies and their properties ( or attributes ). table 112 establishes the relationship between an item ( whether that is a product - item or a category - item ) and it &# 39 ; s ontologies . table 36 associates the values to the attributes of each item . therefore , table 18 allows a user ( typically a catalogue manager ) to create and maintain ontologies ; table 112 allows a user to create ( includes importing ), maintain and view all items ( all classes of items ) through different ontologies ( which are really customisation templates ), and table 36 defines the values for all the attributes that are associated with an individual item . by combining the three tables a user can create different templates ( ontologies ) that control how much details ( attributes and values of an item ) that a user can see . these templates ( ontologies ) can be applied for different item classes ( or within the same item class , different degrees of information detail - perspective , for example , an accountant can see cost information for products that a receptionist can &# 39 ; t ). with the present invention a tool , preferably a software tool , is provided to enable a person to construct the electronic catalogue described above on a computing system . this , as will be appreciated by a skilled person , can be developed from the above description of the electronic catalogue . in the above description and in the following claims the term “ electronic catalogue ” should be taken to mean any catalogue or database which can be implemented by a computing system , and , as computing systems develop into the future this is not necessarily limited to electronic computing systems . in the above description , databases have been represented as tables , having columns and rows . it will be appreciated that this is a representation only that can be easily understood by humans , and in a computing system the data may be stored in any format , not necessarily in a table structure . the term “ electronic catalogue ” has been used throughout this description . the present invention has general application , not just to electronic catalogues , but general application for the management of data and integration . other applications are managing directories of people and company &# 39 ; s details ( such as names and addresses in the phone directory ). a further application could be the integration and sharing of data between business systems ( such as erp , crm and other legacy systems ). a fourth application could be the management of electronic documents ( for example , medical records or web pages ). the term electronic - catalogue should be considered to be used very broadly in this context therefore , to cover any data management and integration application . it will be appreciated by a person skilled in the art the electronic catalogue of the present invention may be implemented on any computing system , whether a desktop or a network computing system , or any other type of computing system . in the claims that follow and in the summary of the invention , except where the context requires otherwise due to express language or necessary implication , the word “ comprising ” is used in the sense of “ including ”, i . e . the features specified may be associated with further features in various embodiments of the invention .