AU2003204729B2 - Indexing and Querying Structured Documents - Google Patents

Description

S&F Ref: 637414

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address of Applicant: Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha 30-2, Shimomaruko 3-chome, Ohta-ku Tokyo 146 Japan Ernest Yiu Cheong Wan Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) Indexing and Querying Structured Documents ASSOCIATED PROVISIONAL APPLICATION DETAILS [33] Country [31] Applic. No(s) AU PS3004 [32] Application Date 17 Jun 2002 The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5815c INDEXING AND QUERYING OF STRUCTURED DOCUMENTS Field of Invention The present invention relates to the indexing and querying of structureddocuments and, in particular, to the indexing and querying of XML documents.

Background Structured documents may be stored in traditional file systems or in databases.

With traditional file systems, entire documents are stored. Searching and retrieving data from a large collection of documents is cumbersome. Typically, text based databases provide more flexible and efficient searching and retrieval capability. Object databases and object-relational databases have been used for storing structured documents. Since XML (eXtensible Markup Language) is the most prevalent format for structured documents, many object-relational databases have built-in facilities for handling XML documents. These databases are often referred to as XML-enabled. XML-enabled objectrelational databases map the XML data to relational tables and support structural search through their underlying query facilities by reformulating XPath or XQuery expressions to SQL queries. Recently, a number of so called Native XML databases have also been developed for storing XML documents. Native XML databases store the XML data in raw XML or a proprietary format and build indices on elements and attributes to allow fast searching.

With all XML-enabled object-relational databases and some native XML databases, indices are only created on a small number of fields. Searching non-indexed fields is very inefficient. On the other hand, in many native XML databases, all element and attribute names and values are indexed. The large indices make updating such databases of structured documents very inefficient.

Summary It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

In accordance with one aspect of the present invention there is provided a method of indexing structured documents, the method comprising the steps of: parsing at least one schema of the structured documents to determine predefined deterministic 270503 637414.doc relationships between components of the structured documents to be indexed; removing from one or more sets of indices those components whose occurrences can be deduced by virtue of said determined predefined deterministic relationships from occurrences of another indexing component to provide corresponding one or more smaller sets of indices; and indexing said structured documents in accordance with said one or more smaller sets of indices.

In accordance with another aspect of the present invention there is provided a method of querying structured documents, wherein said structured documents comprise a plurality of components and have one or more associated sets of indices of indexing components, the method comprising the steps of: reformulating an original query substituting references to one or more non-indexing components in the query with references to said indexing components using predefined deterministic relationships predetermined from schemas of the structured documents wherever possible; querying said structured documents using said reformulated query and said one or more sets of indices of indexing components to provide one or more sets of intermediate results; and performing post-retrieval processing on the one or more sets of intermediate results to form the final result of said original query, said post-retrieval processing comprises the sub-steps of: locating the location of the one or more non-indexed components existing in the one or more intermediate results that were substituted in the original query; and generating a final result set to satisfy the original query using the located non-indexed components.

In accordance with another aspect of the present invention there is provided apparatus for indexing structured documents, the apparatus comprising: means for parsing one or more schemas of the structured documents to determine predefined deterministic relationships between components of the structured documents to be indexed; means for removing from one or more sets of indices those components whose occurrences can be deduced by virtue of said determined predefined deterministic relationships from occurrences of another indexing component to provide corresponding one or more smaller sets of indices; and means for indexing said structured documents in accordance with said one or more smaller sets of indices.

270503 637414.doc In accordance with another aspect of the present invention there is provided apparatus for querying structured documents, wherein said structured documents comprise a plurality of components and have one or more associated sets of indices of indexing components, the apparatus comprising: means for reformulating an original query substituting references to one or more non-indexing components in the query with references to said indexing components using predefined deterministic relationships predetermined from schemas of the structured documents wherever possible; means for querying said structured documents using said reformulated query and said one or more sets of indices of indexing components to provide one or more sets of intermediate results; and means for performing post-retrieval processing on the one or more sets of intermediate results to form the final result of said original query, said post-retrieval processing means comprises: means for locating the location of the one or more nonindexed components existing in the one or more intermediate results that were substituted in the original query; and means for generating a final result set to satisfy the original query using the located non-indexed components.

In accordance with another aspect of the present invention there is provided a computer program for indexing structured documents, the computer program comprising: code for parsing one or more schemas of the structured documents to determine predefined deterministic relationships between components of the structured documents to be indexed; code for removing from one or more sets of indices those components whose occurrences can be deduced by virtue of said determined predefined deterministic relationships from occurrences of another indexing component to provide corresponding one or more smaller sets of indices; and code for indexing said structured documents in accordance with said one or more smaller sets of indices.

In accordance with another aspect of the present invention there is provided a computer program for querying structured documents, wherein said structured documents comprise a plurality of components and have one or more associated sets of indices of indexing components, the computer program comprising: code for reformulating an original query substituting references to one or more non-indexing components in the query with references to said indexing components using predefined deterministic 270503 637414.doc relationships predetermined from schemas of the structured documents wherever possible; code for querying said structured documents using said reformulated query and said one or more sets of indices of indexing components to provide one or more sets of intermediate results; and code for performing post-retrieval processing on the one or more sets of intermediate results to form the final result of said original query, said postretrieval processing code comprises: code for locating the location of the one or more non-indexed components existing in the one or more intermediate results that were substituted in the original query; and code for generating a final result set to satisfy the original query using the located non-indexed components.

Other aspects of the invention are also disclosed.

Brief Description of the Drawings One or more embodiments of the present invention will now be described with reference to the drawings, in which: Fig. 1 is a block diagram of an overview of the preferred method of indexing; Fig. 2 is a block diagram of an overview of the preferred method of querying; Fig. 3 is a block diagram of a general purpose computer upon which the preferred methods can be practised; Fig. 4 is a flow chart depicting the preferred method of indexing; and Fig. 5 is a flow chart depicting the preferred method of querying; and the appendix in which: Table A is an example DTD used for demonstrating the preferred methods; Table B shows an example XML document that conforms to the DTD of Table A; Table C shows an example compact index list created by the preferred method of indexing in response to the parsing of the DTD of Table A; Table D shows an example mapping list created by the preferred method of indexing in response to the parsing of the DTD of Table A; Table E shows the example XML of Table B illustrating the assignation of node numbers by the preferred method of indexing; 270503 637414.doc Table F shows an example lexicon created by the preferred method of indexing after the document of Table B is added to the database; Table G shows an example inverted list for those element and attributes names created by the preferred method after the document of Table B is added to the database; Table H shows the example inverted list for those remaining element names and attributes names; Table I shows an inverted list for attribute values created by the preferred method of indexing after the document of Table B is added to the database; and Table J shows an inverted list for element values created by the preferred method of indexing after the document of Table B is added to the database.

Detailed Description including Best Mode Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

The principles of the preferred method described herein have general applicability to indexing and querying of structured documents. However, for ease of explanation, the steps of the preferred methods are described with reference to the indexing and querying of XML documents. However, it is not intended that the present invention be limited to the described methods. For example, the invention may have application to other types of structured documents such as SGML documents.

The preferred methods use the schemas of the XML data such as the DTD or XML Schemas to determine the existence of certain deterministic relationships among the indexing components. Using such knowledge when indexing the data and formulating query execution plans can greatly reduce the size of the indices and allow update and searching to be performed more efficiently. For instance, if the schema of the XML data declare that an element, say A, always exists with another element, say B, then the preferred methods can index A without indexing B. When searching for the occurrences of B, the original query is reformulated into one that searches for the occurrences of A.

270503 637414.doc The Bs associated with the As found are located in a post-retrieval scan and returned in the final query result.

A high-level block diagram is illustrated in Fig. 1 to provide an overview of the indexing process of the preferred indexing method. An Index Optimizer 100 parses the schema documents 110 that defines the schemas of a class of XML documents to determine the existence of certain deterministic relationships among the schema components. The Index Optimizer 100 removes indexing terms that possess such a deterministic relationship with another indexing term (for instance, an element that is the first mandatory child of another indexing element) from the full list of pre-defined indexing terms 120, creating a more compacted list of indexing terms 130 and reducing the number of terms that are actually indexed. The Index Optimizer 100 also adds the removed terms to another list 140 that maps each removed term to its related indexing term. The smaller index allows the database of XML documents to be updated and searched more efficiently. This smaller index also allows the index to be easily cached, (ie. maintaining the index in memory) increasing the efficiency even further. However, the Index Optimizer 100 has to trade off indexing efficiency and retrieval complexity and may not remove all indexing terms that can be removed from the full index list 120.

When XML documents 150 are added to the database or updated, the Run-time Database Processor 160 creates or updates indices 170 only for terms that appear in the compacted index list 130. The indices 170 point to the occurrences of the indexing terms in the stored XML data 180 allowing them to be located efficiently.

A high-level block diagram is illustrated in Fig. 2 to provide an overview of the associated query processor of the preferred querying method. An Extended Query Processor 200 that comprises a Query Pre-processor 210, a conventional Query Processor 220, and a Post-retrieval Processing module 230 is used. The Query Preprocessor 210 modifies the high-level query 240 by substituting references to any removed indexing terms with references to the indexing terms they mapped to in the list 250 (that is, the list 140 in Fig. The resulting reformulated query 260 is processed by the conventional Query Processor 220 which parses and analyzes the query, formulates a query execution plan, then generates calls to the Run-time Database Query 270503 637414.doc Processor 220 for executing the plan. The query result 270 produced is then passed to the Post-retrieval Processing module 230. The Post-retrieval Processing module 230 checks for the selection criteria substituted or left out when reformulating the query. The Post-retrieval Processing module 230 comprises steps that scan the result of the reformulated query to locate the non-indexed terms in the original query 240 and/or compute the offset of these terms to an associated indexing term using additional information stored with the list 250.

Table A shows an example DTD (Document Type Definitions) that defines the schema of a class of XML documents that store employee records. Table B shows an example document that conforms to the DTD of Table A. Existing native XML databases either automatically index all element and attribute names and values (that is, treating all element and attribute names and values as indexing terms) or only allow a database administrator to manually specify a small number of schema components (such as the id attribute of the element person and the element person/name) as indexing terms. Instead of simply using the full list of indexing terms, the preferred indexing method as depicted in the overview in Fig. 1, will analyze the schema document, namely the DTD as shown in Table A, and uses certain deterministic relationships among the schema components to reduce the number of indexing terms. For instance, as name, gender, division, position and location are mandatory child elements of the element parent, the occurrences of person/name, person/gender, person/division, person/position and person/location are implied by the occurrences of person. Hence, the path of these elements will not be indexed by the preferred method. However, since the values of these elements can take on either a number of pre-defined values or arbitrary values, their values will still be indexed. The approach is demonstrated in the example depicted in Tables C, D, E, F, G, H, I, and J. Those skilled in the art will recognize that the described example is only one of many possible ways of practicing the preferred method.

In Tables C, D, E, F, G, H, I, and J, a native XML database system that automatically indexes selected element and attribute names and values is assumed. The Index Optimizer (100 of Fig. 1) of the database parses and analyses the DTD of Table A and creates two lists. A compacted list of indexing terms as shown in Table C, and a list 270503 637414.doc as shown in Table D that maps the remaining non-indexed terms to indexing terms (140 of Fig. It will be apparent to those skilled in the art that the full set of terms in the Element (path) field of Tables C and D constitute all of the element and attribute (path) terms of this particular example DTD as shown in Table A. Preferably, the Element (path) terms, Attribute (path) terms, and their Values are stored in three separate tables and have three corresponding separate indices. In this particular example, for sake of simplicity, the Attribute (path) terms are also stored in the Element (path) lists of Tables C and D.

Preferably, the XML is encoded in such a manner that the offset between some non-indexed elements and its associated indexing element in the mapping list as shown in Table D can be computed in advance. In our example, the text (of attributes and elements) is encoded separately from the structure (represented by the XML tags) so that each element node (or element instance in an XML document) is encoded with a fixedsize header of h bits, followed by the required attributes each encoded using a bits, the child element nodes, and then the optional attributes. Each leaf node is assumed to be encoded using e bits and point to its separately encoded textual content if the node is not empty. With such encoding, the Index Optimizer can compute the exact offsets between some non-indexed elements and its associated indexing element and store the offsets in a list as shown in Table D. The presence of optional elements make computing in advance the exact offsets for some of the non-indexed elements impossible. However, an offset can still be computed for these elements and used as the starting point in a post-retrieval scan.

When the example document as shown in Table B is added to the database, each element node of the document is assigned a unique number that is referred herein as a node number. The node number comprises information that enables the database processor to compute the physical location of the stored data that the node number references. For the sake of clarity, in the example, the node number of an element instance is simply formed by concatenating the 1-based index of the nodes that lead from the root element to the element instance as shown in the first column of Table E. For instance, the first child of the root element is assigned the node identifier 1.1 and the 270503 637414.doc second child of the first child of the root element is assigned the node identifier 1.1.2.

The node number of the root element can be treated as a document number.

The Run-time database processor (160 of Fig. 1) in this particular example is assumed to create an inverted file index for element and attribute names and values.

Table F shows a lexicon which contains all the element names that appear in the database after the single document as shown in Table A has been added to the database. The lexicon of Table F maps a term an element name in this case to its associated entry in the inverted file index as shown in Table G. The inverted list file index as shown in Table G stores a list of pointers to all occurrences of the term in the stored data. In the example, the pointers are node numbers. For the sake of comparison only, Table H is illustrated to show the inverted lists that are rendered unnecessary, as a result of the preferred method. That is the preferred method does not in fact index the document as shown in Table A with regard to the terms shown in Table H. Consequently, the size of the indices is greatly reduced by the preferred method and this allows update and searching of the database to be performed more efficiently.

Two other inverted files are used by the database in the example: one for the value of the attributes as shown in Table I and one for the textual value of the elements as shown in Table J. The most straightforward approach is assumed in the example. Each word that appeared in the value of an attribute or element is used as an indexing term without any case folding (that is, the replacing of all uppercase characters with their lowercase equivalents) or stemming (that is, reducing a word to its root word).

When the following XQuery: for $p in //personnel/person where $p/location/city "Chatswood" return $p/name is made to the database selected by the query, where $p is a variable to every object in the database. The Query Pre-Processor (210 of Fig. 2) may reformulate the query to: for $p in //personnel/person where contains($p, "Chatswood") return $p 270503 637414.doc using the relationships between non-indexed elements and indexing elements depicted in the list as shown in Table D (250 of Fig. It should be noted that a query can be reformulated in a number of different ways depending on the design of the database system. The Query Processor (220 of Fig. 2) then processes the reformulated query. The Query Processor 220 looks up the element name index of Table G for the occurrences of the nodes /personnel/person and locates the node 1.1, 1.2, 1.3, 1.4, 1.5, 1.6. The Query Processor 220 also looks up the element value index as shown in Table J for the value that contains the word "Chatswood" and locates the nodes 1.3.5.2, 1.4.5.2, 1.5.5.2 and 1.6.5.2.

From the node numbers, the Query processor can decide that only nodes 1.3, 1.4, 1.5, 1.6 satisfy the query. These nodes are fetched and form the intermediate query result (270 of Fig. The Post-retrieval Processing module (230 of Fig. 2) then verifies that the term "Chatswood" found in these node are indeed the values of their child element location/city. The offset information in the list as shown in Table D allows the element node /personnel/person/location/city to be located and checked quickly. The offset information also allows the elements nodes /personnel/person/name to be located quickly and returned as the final query result (280 of Fig. 2).

Turning now to Fig. 4, there is shown a flow chart of the preferred method of indexing. The preferred method 400 of indexing commences at step 410, where any necessary parameters are initialised. The preferred method 400 then proceeds to step 420, where the preferred method 400 parses the schemas of the data, for example the DTD document defining a class of XML documents. The preferred method 400 in step 430 then identifies from the parsed DTD document whether there exists any predefined deterministic relationships among the components to be indexed (for instance, an element that is the first mandatory child of another indexing element). After completion of step 430, the preferred method then proceeds to step 440. In step 440, the preferred method 400 then removes these identified components that can be inferred from other indexing components from a full list of index components, thus forming a smaller list of index components. These removed components in step 440 are also added to another list that maps each substituted or removed component to its related indexing component. After step 440, the preferred method 400 in step 450 then creates or updates indices of the 270503 637414.doc -11database of structured documents, eg. XML documents, only for the components that appear in the smaller list of index components. The indices point to the occurrences of the indexing terms in the stored XML data allowing them to be located efficiently.

Turning now to Fig. 5, there is shown a flow chart of the preferred method of querying. The preferred method 500 of querying commences at step 510, where any necessary parameters are initialised. The preferred method 500 then proceeds to step 520, where user query is received, and the preferred method 500 reformulates the query by substituting those non-indexed components in the query with their corresponding indexing components utilising the mapping list generated during the indexing method 400. After this step 520, the preferred method 500 proceeds to step 530, where the reformulated query is processed. During this processing 530, the preferred method 500 queries the XML database utilising this reformulated query to obtain intermediate query results and then proceeds to step 540. The preferred method 500 in step 540 then determines the location of any of the non-indexed components existing in the intermediate results that were substituted in the original query. Preferably, during this step 540, the preferred method 500 scans and computes the location of these 'substituted' non-indexed components in the intermediate results, by computing the offset of these components to an associated indexing component using information stored with the nonindexed list. Alternatively, during this step 540, the preferred method 500 may scan the entire intermediate results to locate these 'substituted' non-indexed components in the intermediate results. After completion of step 540, the preferred method 500 then in step 550, generates a final result set to satisfy the original query using the aforementioned located non-indexed components.

It should be noted that in a simple query the set of intermediate query results is same or larger than the set of final query results. Thus, in the case where the original query involves logical operators, the reformulated query of the preferred query method 500 return a plurality of sets of intermediate query results. When this is the case, the preferred query method 500 will apply any unprocessed operators to the plurality of intermediate query results to generate a final resultant set to satisfy the original query using the located non-indexed components.

270503 637414.doc -12- The preferred methods of indexing and querying are preferably practiced using a general-purpose computer system 800, such as that shown in Fig. 3 wherein the processes of Figs.1 and 4, and 2 and 5 may be implemented as software, such as an application program executing within the computer system 800. In particular, the steps of preferred methods of indexing and querying are effected by instructions in the software that are carried out by the computer. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part performs the indexing and querying methods and a second part manages a user interface between the first part and the user.

The software may be stored in a computer readable medium, comprising the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on the medium is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for indexing and apparatus for querying.

The computer system 300 is formed by a computer module 301, input devices such as a keyboard 302 and mouse 303, output devices comprising a printer 315, a display device 314 and loudspeakers 317. A Modulator-Demodulator (Modem) transceiver device 316 is used by the computer module 301 for communicating to and from a communications network 320, for example connectable via a telephone line 321 or other functional medium. The modem 316 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN), and may be incorporated into the computer module 301 in some implementations.

The computer module 301 typically comprises at least one processor unit 305, and a memory unit 306, for example formed from semiconductor random access memory (RAM) and read only memory (ROM). The module 301 also comprises an number of input/output interfaces comprising an audio-video interface 307 that couples to the video display 314 and loudspeakers 317, an I/O interface 313 for the keyboard 302 and mouse 303 and optionally a joystick (not illustrated), and an interface 308 for the modem 270503 637414.doc -13- 316 and printer 315. In some implementations, the modem 316 may be incorporated within the computer module 301, for example within the interface 308. A storage device 309 is provided and typically comprises a hard disk drive 310 and a floppy disk drive 311. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 312 is typically provided as a non-volatile source of data. The components 305 to 313 of the computer module 301, typically communicate via an interconnected bus 304 and in a manner that results in a conventional mode of operation of the computer system 300 known to those in the relevant art. Examples of computers on which the described arrangements can be practised comprise IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom.

Typically, the application program is resident on the hard disk drive 310 and read and controlled in its execution by the processor 305. Intermediate storage of the program and any data fetched from the network 320 may be accomplished using the semiconductor memory 306, possibly in concert with the hard disk drive 310. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 312 or 311, or alternatively may be read by the user from the network 320 via the modem device 316. Still further, the software can also be loaded into the computer system 300 from other computer readable media.

The term "computer readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 300 for execution and/or processing. Examples of storage media comprise floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 301.

Examples of transmission media comprise radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets comprising e-mail transmissions and information recorded on Websites and the like.

Industrial Applicability 270503 637414.doc -14- It is apparent from the above that the arrangements described are applicable to the database and data processing industries.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of'. Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

270503 637414.doc 15

APPENDIX

TABLE A <?xml encoding="UTF-8"?> <!ELEMENT personnel (person)+> <!ELEMENT person (name, gender, division, position, location, supervisor*, contactNumber*, email*)> <!ATTLIST person id ID #REQUIRED> <!ELEMENT name ((family, given))> <!ELEMENT family (#PCDATA)> <!ELEMENT given (#PCDATA)> 'ELEMENT location (state, city, street?)> <!ELEMENT state (NSWIVICIWAISAITASINTIACT)> <!ELEMENT city (#PCDATA)> <1ELEMENT street (#PCDATA)> <!ELEMENT supervisor EMPTY> <!ATTLIST supervisor id IDREF #REQUIRED> <!ELEMENT gender (malelfemale)> <lELEMENT division (#PCDATA)> <lELEMENT position (#PCDATA)> <!ELEMENT contactNumber (#PCDATA)> <lELEMENT email (#PCDATA)> 270503 205036374 14.doc -16- TABLE B <?xml version="1 encoding="UTF-8"?> <!DOCTYPE personnel SYSTEM "personnel. dtd"> <personnel> <Person id="329756"> <name> <family>James</family> <given>John</given> </aame> <gender> male</g end er> <division>Administration</division> <position >CEO</position> <location> <state> NSW</state> <city> Syd ney<Icity> </location> <email>John.James@foo.com.au</email> </person> <Person id="843575"> <name> <family>Lee</family> <given>Sara</given> </name> <gender>female</gender> <d ivision>Ad ministration </division> 270503 20503637414.doc 17- TABLE B CONTINUED (1) <position >secretary</position> <location> <state> NSW</state> <city> Syd ney</city> </location> <supervisor id="329756"I> <email>Sara. Lee@foo.com.au</email> person> <Person id='124567"> <name> <family>Smith</family> <g iven>Jason</giyen> </aine> <gender> male</gende r> <division> Marketing</division> <position>manager</position> <location> <state> NSW</state> <city>Chatswood </city> </location> <supervisor id="329756"I> <email>Jason.Smith@foo.com.au</email> </person> <Person id="1 20498"> <name> <family> Law</fami ly> 270503 20503637414.doc TABLE B CONTINUED (2) <given> Henry</given> </aame> <gender>male</gender> <division>Marketing</division> <position>salesperson</position> <location> <state> NSW</state> <city>Chatswood </city> </location> <supervisor id="1 2456 <email>Henry.Law@foo.com.au</email> </person> <Person id="2231 34"> <name> <family>Johnston</family> <given>Catherine</given> </name> <gender>female</gender> <division>Marketing</division> <position>salesperson</position> <location> <state> NSW</state> <city>Chatswood </city> </location> <supervisor id="1 24567"/> <email>Catherine.Johnston@foo.com.au</email> </person> 270503 20503637414.doc 19- TABLE B CONTINUED (3) <Person id="854765"> <name> <family>Taylor</family> <given>Mary</given> </aame> <gender>female</gender> <division> Marketing</d ivision> <position>receptonist</position> <location> <state> N SW</state> <city> Chatswood </city> </location> <supervisor id=" 1 24567"!> <email>Mary.Taylor@foo.com.au</emaij> </person> </personnel> 270503 275036374 14.doc 20 TABLE C Element (path) personnel personnel/person person nel/pe rson/location/street person nel/person/su pervisor person nel/person/contactNu mber person nel/person/emailI person person/location/street person/supervisor person/contactN umber person/email name location location/street supervisor gender division position contactNumber email 270503 20503637414.doc -21-

TABLED____

Element (path) ]Indexed element JOffset person nel/person/@ id person nel/person h person nel/person/supervisor/@id person nel/person/s upervisor h person nelI/person/name personnel/person h+a personnel/person/name/family person nel/person 2h+a personnel/person/name/given personnel/person 2h+a+e personnel/person/gender person nel/person 2h+a+2e person nelI/person/d ivision person nel/person 2h+a+3e person nel/person/pos ition person nel/person 2h+a+4e person nel/person/location person nelI/pe rson person nelI/person/location/state personnel/person person nel/person/location/city person nel/person 3n+a+6e person/@id person h person/supervisor/@id person/supervisor h person/name/family person h+a person/name/given person h+a+e person/gender person h+a+2e person/division person h+a+3e person/position person h+a+4e person/location person person/location/state person person/location/city person 2n+a+6e name/family name h name/given name h+e location/state location h location/city location h+e 270503 20503637414.doc 22 TABLE E Node XML data stored number 1 <personnel> 1.1 <Person id="329756"> 1.1.1<name> 1.1.1.1 <family>James</family> 1.1.1.2 <given>John</given> </name> 1.1.2 <gender>male</gender> 1.1.3 <division>Administration</division> 1.1.4 <position>CEO</position> 1.1.5 <location> 1.1.5.1 <state> NSW</state> 1.1.5.2 <city>Sydney</city> </location> 1.1.6 <email>John.James@foo.com.au</email> 1.2 <Person id="843575"> 1.2.1 <name> 1.2.1.1 <family>Lee</family> 1.2.1.2 <given>Sara</given> </name> 1.2.2 <gender>female</gender> 1 .2.3 <division>Administration</division> 1.2.4 <position>secretary</position> 270503 20503637414.doc 23 TABLE E CONTINUED (1) Node XML data stored number 1.2.5 <location> 1.2.5.1 <state> NSW</state> 1.2.5.2 <city> Syd ney</city> </locat ion> 1.2.6 <supervisor id="329756"I> 1.2.7 <emaili>Sara. Lee@foo. com. au</emai I> </person> 1.3 <Person id="124567"> 1.3.1 <name> 1.3.1.1 <fami ly>S mith </family> 1.3.1.2 <given>Jason</given> </name> 1.3.2 <gender>male</gender> 1.3.3 <division>Marketing</division> 1.3.4 <position >manag er</pos ition 1.3.5 <location> 1.3.5.1 <state> NSW</state> 1.3.5.2 <city> Chatswood </city> </location> 1.3.6 <supervisor id="329756"I> 1.3.7 <email>Jason.Smith@foo.com.au</email> </person> 270503 20503637414.doc 24 TABLE E CONTINUED (2) Node XML data stored number 1.4 <Person id="120498"> 1.4.1 <name> 1.4.1.1 <family>Law< family> 1.4.1.2 <given>Henry</given> </name> 1.4.2 <gender>male<Igender> 1.4.3 <division> Marketing</division> 1.4.4 <position >salesperson </position> 1.4.5 <location> 1.4.5.1 <state> NSW</state> 1.4.5.2 <city> Chatswood </city> </location> 1.4.6 <supervisor id="124567"/> 1.4.7 <email>Henry. Law@foo.com.au</email> </person> <Person id="2231 34"> 1.5.1 <name> 1.5.1.1 <family>Johnston</family> 1.5.1.2 <given>Catherine</given> </aame> 1.5.2 <gender>female</gender> 1.5.3 <division> Marketing ivision> 1.5.4 <position >salesperson </position> 1.5.5 <location> 270503 20503637414.doc 25 TABLE E CONTINUED (3) Node XML data stored number 1.5.5.1 <state> NSW</state> 1.5.5.2 <city>Chatswood </city> </location> 1.5.6 <supervisor id="1 24567"!> 1.5.7 <email>Catherine.Johnston@foo.com.au</email> </person> 1.6 <Person id =854765"> 1.6.1 <name> 1.6.1.1 <family>Taylor</family> 1.6.1.2 <given>Mary</given> </name> 1.6.2 <gender>female</gender> 1.6.3 <division>Marketing</division> 1.6.4 <position>receptonist</position> 1.6.5 <location> 1.6.5.1 <state> NSW</state> 1.6.5.2 <city>Chatswood </city> </location> 1.6.6 <supervisor id="1 24567"/> 1.6.7 <email>Mary.Taylor~foo.com.au</email> </person> 270503 20503637414.doc -26- TABLE F Term Index entry @id 2, 3 city 2 division 2 email 4 family 2 gender 2 given 2 name 2 location 2 person 2 personnel 1 position 2 state 2 supervisior 3 TABLE G index Element (path) Inverted list 1 personnel 1 2 personnel/person 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 3 personnel/person/supervisor 1.2.6, 1.3.6, 1.4.6, 1.5.6, 1.6.6 4 personnel/person/email 1.1.6, 1.2.7, 1.3.7, 1.4.7, 1.5.7, 1.6.7 270503 637414.doc -27- TABLE H Element (path) Inverted list personnel/person/@id 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 personnel/person/supervisor/@id 1.2.6, 1.3.6, 1.4.6, 1.5.6, 1.6.6 personnel/person/name 1.1.1, 1.2.1, 1.3.1, 1.4.1, 1.5.1, 1.6.1 personnel/person/name/family 1.1.1.1, 1.2.1.1, 1.3.1.1, 1.4.1.1, 1.5.1.1, 1.6.1.1 personnel/person/name/given 1.1.1.2, 1.2.1.2, 1.3.1.2, 1.4.1.2, 1.5.1.2, 1.6.1.2 personnel/person/gender 1.1.2, 1.2.2, 1.3.2, 1.4.2, 1.5.2, 1.6.2 personnel/person/division 1.1.3, 1.2.3, 1.3.3, 1.4.3, 1.5.3, 1.6.3 personnel/person/position 1.1.4, 1.2.4, 1.3.4, 1.4.4, 1.5.4, 1.6.4 personnel/person/location 1.1.5, 1.2.5, 1.3.5, 1.4.5, 1.5.5, 1.6.5 personnel/person/location/state 1.1.5.1, 1.2.5.1, 1.3.5.1, 1.4.5.1, 1.5.5.1, 1.6.5.1 personnel/person/location/city 1.1.5.2, 1.2.5.2, 1.3.5.2, 1.4.5.2, 1.5.5.2, 1.6.5.2 TABLE I Word Inverted list 120498 1.4 124567 1.3, 1.4.6, 1.5.6, 1.6.6 223134 329756 1.1, 1.3.6 843575 1.2, 1.2.6 854765 1.6 270503 637414.doc 28 TABLE J Word JInverted list Administration 1.1.4, 1.2.3 Catherine 1.5.1.2 Catherine. Joh nston@foo.com.au 1.5.7 CEO 1.1.5 Chatswood 1.3.5.2, 1.4.5.2, 1.5.5.2, 1.6.5.2 Henry 1.4.1.2 Henry. Law@foo.com.au 1.4.7 James 1.1.1.1 Jason 1.3.1.2 Jason. Smith~foo.com. au 1.3.7 John 1.1.1.2 John.James@foo.com.au 1.1.6 Johnston 1.5.1.1 Law 1.4.1.1 Lee 1.2.1.1 Marketing 1. 3.3, 1.4.3, 1.5.3, 1.6.3 Mary 1.6.1.2 Mary.Tayor~foo.com.au 1.6.7 NSW 1. 1. 5.1, 1.2.5.1, 1.3.5.1, 1.4.5.1, 1.5.5. 1, 1.6.5.1 Sara 1.2.1.2 Sara. Lee@foo.com.au 1.2.7 Smith 1.3.1.1 Taylor 1.6.1.1 Sydney 1.1.5.2,1.2.5.2 270503 20503637414.doc 29 TABLE J CONTINUED (1) Word IInverted list female 1.2.2, 1.5.2, 1.6.2 male 1.1.2, 1.3.2, 1.4.2 manager 1.3.4 receptionist 1.6.4 salesperson 1.4.4, 1.5.4 secretary 1.2.4 270503 275036374 14.doc

Claims (20)

1. A method of indexing a structured document, the method comprising the steps IDof: parsing at least one schema of the structured document to determine predefined deterministic relationships between indexing components of the structured document to be indexed; identifying non-indexing components of the structured document, said non- Sindexing components being those said indexing components whose occurrences can be deduced, by virtue of said determined predefined deterministic relationships, from occurrences of other said indexing components; removing from one or more sets of indices for the structured document the identified non-indexing components to provide corresponding one or more smaller sets of indices; and indexing said structured document in accordance with said one or more smaller sets of indices.

2. A method as claimed in claim 1, wherein said method comprises the step of: generating a list that maps the removed components to the indexing components.

3. A method as claimed in claim 2, wherein said method comprises the steps of: encoding the components of the structured document in such a manner that said predefined deterministic relationship between any two components is characterized by a fixed offset between the two encoded components; and storing said offsets in said mapping list.

4. A method as claimed in claim 1, wherein said predefined deterministic relationship comprises one component as being a mandatory child of another component. 181105 637414 -31- A method as claimed in claim 1, wherein said predefined deterministic relationship comprises one component as being a mandatory attribute of another Scomponent.

6. A method as claimed in claim 1, wherein said structured document is an XML C document and said schema is an XML schema.

7. A method as claimed in claim 6, wherein said schema is a DTD document. ,I 10 8. A method of querying structured documents having one or more associated sets of indices of indexing components, the method comprising the steps of: reformulating an original query by substituting references in the original query to one or more non-indexing components with references to said indexing components using predefined deterministic relationships predetermined from a schema of the structured documents querying said structured documents using said reformulated query and said one or more sets of indices of indexing components to provide one or more sets of intermediate results; and performing post-retrieval processing on the one or more sets of intermediate results to form the final result of said original query, said post-retrieval processing comprises the sub-steps of: locating the location of the one or more non-indexing components in the one or more intermediate results that were substituted in the original query; and generating a final result set to satisfy the original query using the located non- indexing components.

9. A method as claimed in claim 8, wherein the locating sub-step comprises the following sub-step: 181105 637414 -32- scanning the one or more intermediate results to locate the location of any of the N non-indexing components existing in the one or more intermediate results that were U substituted in the original query.

10. A method as claimed in claim 8, wherein the locating sub-step comprises the Cfollowing sub-step: computing the offset of the non-indexing components existing in the one or more intermediate results that were substituted in the original query to an associated indexing (Ni component. ,IC

11. A method as claimed in claim 8, wherein said predefined deterministic relationship comprises one component as being a mandatory child of another component.

12. A method as claimed in claim 8, wherein said predefined deterministic relationship comprises one component as being a mandatory attribute of another component.

13. A method as claimed in claim 8, wherein said structured documents are XML documents and said schemas are XML schemas.

14. A method as claimed in claim 13, wherein said schemas are DTD documents. Apparatus for indexing a structured document, the apparatus comprising: means for parsing one or more schemas of the structured document to determine predefined deterministic relationships between indexing components of the structured document to be indexed; means for identifying non-indexing components of the structured document, said non-indexing components being those said indexing components whose occurrences can be deduced, by virtue of said determined predefined deterministic relationships, from occurrences of other said indexing components; 181105 637414 -33 means for removing from one or more sets of indices for the structured document the identified non-indexing components to provide corresponding one or more smaller sets of indices; and ND means for indexing said structured document in accordance with said one or more smaller sets of indices.

16. Apparatus for querying structured documents having one or more associated sets of indices of indexing components, the apparatus comprising: means for reformulating an original query by substituting references in the (N 10 original query to one or more non-indexing components with references to said indexing components using predefined deterministic relationships predetermined from a schema of the structured documents; means for querying said structured documents using said reformulated query and said one or more sets of indices of indexing components to provide one or more sets of intermediate results; and means for performing post-retrieval processing on the one or more sets of intermediate results to form the final result of said original query, said post-retrieval processing means comprises: means for locating the location of the one or more non-indexing components existing in the one or more intermediate results that were substituted in the original query; and means for generating a final result set to satisfy the original query using the located non-indexing components.

17. A computer program for indexing a structured document, the computer program comprising: code for parsing one or more schemas of the structured document to determine predefined deterministic relationships between indexing components of the structured document to be indexed; 181105 637414 34 code for identifying non-indexing components of the structured document, said N non-indexing components being those said indexing components whose occurrences can be deduced, by virtue of said determined predefined deterministic relationships, from IN occurrences of other said indexing components; code for removing from one or more sets of indices for the structured document the identified non-indexing to provide corresponding one or more smaller sets of indices; and Scode for indexing said structured document in accordance with said one or more Osmaller sets of indices.

18. A computer program for querying structured documents having one or more associated sets of indices of indexing components, the computer program comprising: code for reformulating an original query by substituting references in the original query to one or more non-indexing components in the query with references to said indexing components using predefined deterministic relationships predetermined from a schema of the structured documents; code for querying said structured documents using said reformulated query and said one or more sets of indices of indexing components to provide one or more sets of intermediate results; and code for performing post-retrieval processing on the one or more sets of intermediate results to form the final result of said original query, said post-retrieval processing code comprises: code for locating the location of the one or more non-indexing components existing in the one or more intermediate results that were substituted in the original query; and code for generating a final result set to satisfy the original query using the located non-indexing components.

19. A method of querying structured documents, the method substantially as described herein with reference to Figs. 2 and 5 of the accompanying drawings. 181105 637414 A method of indexing structured documents, the method substantially as Sdescribed herein with reference to Figs. 1 and 3 of the accompanying drawings. ID

21. Apparatus for querying structured documents, the apparatus substantially as Sdescribed herein with reference to Figs. 2, 3, and 5 of the accompanying drawings.

22. Apparatus for indexing structured documents, the apparatus substantially as Cc€ Sdescribed herein with reference to Figs. 1 and 3, and 4 of the accompanying drawings. <N

23. A computer program for querying structured documents, the computer program substantially as described herein with reference to Figs. 2, 3, and 5 of the accompanying drawings.

24. A computer program for indexing structured documents, the computer program substantially as described herein with reference to Figs. 1 and 3, and 4 of the accompanying drawings. DATED this 18 th Day of November, 2005 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON&FERGUSON 181105 637414