One way to implement hierarchical documents is through the use of
predefined phrases. Consider the 2 hierarchies:
1. Kids_and_Teens/Computers/Software/Games
2. Computers/Software/Freeware
When indexing a document belonging to (1), add these terms in consecutive
order (autoincrement=1): dir:Top dir:Kids_and_Teens dir:Computers
dir:Software dir:Games dir:Bottom
For documents belonging to (2), add: dir:Top dir:Computers dir:Software
dir:Bottom
The terms dir:Top and dir:Bottom can be used to anchor a query
to a specific portion of the hierachy.
Thus, a query containing the phrase: dir:Computers dir:Software would
match documents in both (1) and (2) (and perhaps others), but a query for:
dir:Top dir:Kids_and_Teens dir:Computers dir:Software would target only
'Computer/Software' documents from the 'Kids_and_Teens' top level directory.
(The QueryPhrase 'slop factor' would be set to 0).
Peter
- Original Message -
From: Tatu Saloranta [EMAIL PROTECTED]
To: Lucene Users List [EMAIL PROTECTED]
Sent: Monday, October 20, 2003 8:24 PM
Subject: Re: Hierarchical document
On Monday 20 October 2003 10:31, Erik Hatcher wrote:
On Monday, October 20, 2003, at 11:06 AM, Tom Howe wrote:
There is not a more lucene way to do this - its really up to you to
be creative with this. I'm sure there are folks that have implemented
something along these lines on top of Lucene. In fact, I have a
particular interest in doing so at some point myself. This is very
similar to the object-relational issues surrounding relational
databases - turning a pretty flat structure into an object graph.
There are several ideas that could be explored by playing tricks with
fields, such as giving them a hierarchical naming structure and
querying at the level you like (think Field.Keyword and PrefixQuery,
for example), and using a field to indicate type and narrowing queries
to documents of the desired type.
I'm interested to see what others have done in this area, or what ideas
emerge about how to accomplish this.
I'm planning to do something similar. In my case problem is bit simpler;
documents have associated products, and products form a hierarchy.
Searches should be able to match not only direct matches (searching
product, article associated with product), but also indirect ones via
membership (product member of a product group, matching group).
Product hierarchy also has variable depth.
To do searches using non-leaf hierarchy items (groups), all actual product
items/groups associated with docs are expanded to full ids when
indexing (ie. they contain path from root, up to and including node,
each node component having its own unique id).
Thus, when searching for an intermediate node (product grouping),
match occurs since that node id is part of path to products that are in
the group (either directly or as members of sub-groups).
Since no such path is stored (directly) in database, this also allows me
to do
queries that would be impossible to do in database (I could add similar
path/full id fields for search purposes of course). Thus, Lucene index is
optimized for searching purposes, and database structure for editing
and retrieval of data.
Another thing to keep in mind is that at least for metadata it may make
sense
to use specialized analyzer, one that allows tokenizing using specific ids
to store ids as separate tokens; instead of using some standard plain text
analyzer. This way it is possible to separate ids from textual words (by
using prefixes, for example, @1253 or #13945); this allows for
accurate
matching based on identity of associated metadata selections.
-+ Tatu +-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
