Ozone applicable for my faceted classification?

Hi list,

I'm afraid this email became a bit long, but if someone can help me, I'd 
be very grateful.

I'm going to decide upon a storage system for a custom designed faceted 
classification system. I have a preliminary design of my classes, which 
you can find here: http://arethusa.tweakers.net/~acm/facettree.png

The storage system will have to store all those objects, or a similar 
representation, in some persistent way since keeping everything in 
memory is probably a no-go (maybe, I can keep the structure mapped in 
memory and retrieve the documents). I do see a way to construct this 
setup in a sql-database. The model itself shows that it can be done in Java.

The problems start as soon as I'm starting to think of the document 
retrieval process. Documents can be retrieved based on certain criteria. 
For instance, one could want to have the set of documents that:
- are in the main FacetClass -> Computer Hardware -> Laptops (all 
FacetObjects "below" this Class),
- are in a facet Who-facet -> Manufacturer -> Dell (all FacetObjects 
related to this facet, directly or indirectly),
- are in a facet Part-specification -> screen size -> 15 inch (""),
- has to be found in the location "forum",
- should be dated later than 1-jan-2003.

One needs a simple cross-section of the result sets of the above set of 
specifications and has a list of complying documents.

Since I have found a few ways in SQL to do single-query tree-traversal I 
can get the above criteria in a few simple queries which can then be 
literally intersected using the INTERSECT-statement, but that is slow. A 
good performing query will, however, probably become very easily very 
complex and as a result also be (a bit less) slow. I'm therefore not too 
happy with the ways SQL allows me to do the above.

A straightforward solution in an OO-environment is to simply retrieve 
all documents which are connected (potentially using multiple levels of 
the hierarchy) to each selected FacetElement or Facet, intersecting 
those sets and afterwards filtering the location and date.
With a few thousand documents, this can be done relatively fast, but I 
may get tens or even hundreds of thousands documents in our setup.

My questions are simple:
- Will I be able to structure the above in ozone (probably yes) and what 
kind of problems may I run into (if I follow the ozone-way-of-work, I 
should run into none, right?) ?
- Will I be able to efficiently retrieve a set of 
facetelements/documents from the database that fully comply to the 
requested set of criteria or with a minimal amount of work?

If the last question is a result of my sql-focusness, please point me in 
the right direction of reformulating that question :)

Thanks in advance and best regards,

Arjen van der Meijden




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click