Why am I afraid?
Building the index wouldn't be a problem. I guess.
Querying it would be more difficult.
Let's see.
Custom properties... defined by the user, there is no restriction, in quantity,
and values.
> > Custom property name: Frequency> > Custom property value: Quarterly> >> >
> > Custom property name: Last update> > Custom property value: 2006-01-01
Cube1 has Frequency, Last Update
Cube2 has Suggestion, Frequency
Cube3 has Time Range, Original Source
...
...
In the index the document should have one field per CustomProperty
docid=0, cubename=cube1, Frequency=Quarterly, Last update=2006-01-01
docid=1, cubename=cube2, Suggestion="This cube should be used by the Account
manager", Frequency="Monthly"
docid=2, cubename=cube3, Time Range="Since 1980 up to 2007", Original
Source="Account subsystem"
....
....
Each custom property should be a Field, there is no control over which fields
are created.
How the query should be constructed, at the query you specify which fields you
should use. There is a way to query all the fields.
Well it looks like it should work.
Is this how I should do it?
Add each Custom Property as a Field is the answer?
For the hierarchy info modeling, the answer is generating every combination of
dimension and levels?
Thanks for taggin me along with this.
Roger CamargoUMSS "University"Cochabamba - Bolivia
> Date: Mon, 14 Jan 2008 09:56:36 -0500> From: [EMAIL PROTECTED]> To:
> java-user@lucene.apache.org> Subject: Re: How to model hierarchy info to be
> searched related to a document> > I am not sure why you are afraid of adding
> more fields to the document.> Having 20-30 fields to a document is not a bad
> thing to do. Do you have any> constraints to limit the number of fields in
> the document?> > > > > > > > > > On Jan 14, 2008 7:59 AM, Roger Camargo
> <[EMAIL PROTECTED]> wrote:> > > Thanks for answering.> >> > It seems that
> there isn't any other way around, having every combination> > of dimension
> and level.> >> > The example for the observations of the dimension, would be
> as follow,> > maybe isn't such an important information to be stored, but
> type it is.> >> > Dimension name: Region> > Dimension observations: The
> dimension only includes countries of south> > america <--This would be the
> observations of the dimension.> > Dimension type: Geographical> >> > OK, now
> it seems that I have one document per combination of dimension and> > level
> (following the example I provided it would be something like this> > doc 0:
> id=0, name="Quarter sales per region", desc="Description of the> > cube",
> dimension="Region", level="Country"> > doc 1: id=0, name="Quarter sales per
> region", desc="Description of the> > cube", dimension="Region", level="City">
> > doc 2: id=0, name="Quarter sales per region", desc="Description of the> >
> cube", dimension="Time", level="Year"> > doc 3: id=0, name="Quarter sales per
> region", desc="Description of the> > cube", dimension="Time",
> level="Quarter"> >> > OK and adding the Dimension type would end up like
> this:> >> > doc 0: id=0, name="Quarter sales per region", desc="Description
> of the> > cube", dimension="Region", dimensiontype="Geographycal"
> level="Country"> > doc 1: id=0, name="Quarter sales per region",
> desc="Description of the> > cube", dimension="Region",
> dimensiontype="Geographycal" level="City"> > doc 2: id=0, name="Quarter sales
> per region", desc="Description of the> > cube", dimension="Time",
> dimensiontype="Time" level="Year"> > doc 3: id=0, name="Quarter sales per
> region", desc="Description of the> > cube", dimension="Time",
> dimensiontype="Time" level="Quarter"> >> > Now what about the custom
> properties?> >> > Custom property name: Update Frequency> > Custom property
> value: Quarterly> > Custom property name: Last update> > Custom property
> value: 2006-01-01> >> > I'm afraid that I would end up not using them for the
> search, they would> > have each one a field, and because the user can create
> any number of these> > custom properties they would be hard to query them. Or
> is there any correct> > way to add them to the document model?> >> > Roger
> Camargo> > UMSS "University"> > Cochabamba - Bolivia> >> >
> ------------------------------> > Date: Sun, 13 Jan 2008 17:07:52 -0500> >
> From: [EMAIL PROTECTED]> > To: java-user@lucene.apache.org> > Subject: Re:
> How to model hierarchy info to be searched related to a> > document> > CC:
> [EMAIL PROTECTED]> >> >> > Roger,> >> > Why can;t you have one document for
> every combination of dimension,> > level ? Add cube name , id and description
> too as a field to all documents> > , all it would be reduntant information,
> but you can live with it i suppose?> >> >> > I think you are developing an
> application to search a cube ?> >> > what do you mean by observations of a
> dimension ? is there an example?> >> > On Jan 11, 2008 7:57 PM, Roger Camargo
> < [EMAIL PROTECTED]> wrote:> >> > I'm trying to index information related to
> Olap Cubes.> >> > Each cube I'm trying to model it like a document.> >> > The
> cube have the following information:> >> > ID - Unique identifier for the
> cube> > Name - Name of the cube> > Description - Description of the cube> >>
> > (There can be many dimensions per cube)> > Dimension name - Name of the
> dimension of the cube> > Dimension observations - Observations related to the
> dimension. (Optional)> > Dimension type - Type of the dimension> >> > (Each
> dimension has at least one Level, but there can be many levels per> >
> dimension)> > Level name - Name of the level> > Level observations -
> Observations of the level (Optional)> >> > (There has to be at least one Fact
> per cube)> > Fact name - Name of the fact> > Fact aggregation - Aggregation
> of the fact> >> > (Also there can be custom properties added by the user,
> with the form> > Name,Value)> > Custom property name - Name of the custom
> property> > Custom property value - Value of the custom property> >> > Right
> now I'm just indexing the first 3 ID, Name and Description, but I> > would
> also want the other information to be indexed and search the cube with> >
> that information.> >> >
> --------------------------------------------------------> > Data sample:> >>
> > ID: 0> > Name: Quarter sales per region> > DescriptÃon: Description of the
> cube...> >> > Dimension name: Region> > Dimension observations: The dimension
> only includes countries of south> > america> > Dimension type: Geographical>
> >> > Level name: Country> > Level observations: Observations of the
> level....> >> > Level name: City> > Level observations: Observations of the
> level....> >> > Dimension name: Time> > Dimension observations: Has data only
> from the year 2000> > Dimension type: Time> >> > Level name: Year> > Level
> observations: No observations> >> > Level name: Quarter> > Level
> observations: No observations> >> > Fact name: Sales> > Fact Aggregation:
> Sum> >> > Fact name: % Quarter Growth> > Fact Aggregation: AVG> >> > Custom
> property name: Frequency> > Custom property value: Quarterly> >> > Custom
> property name: Last update> > Custom property value: 2006-01-01> >
> --------------------------------------------------------> >> > My problems
> would be the following.> >> > 1. How to index "Dimension name" and "Dimension
> observations".> > If there would be just Dimension names, I cound index it as
> a single Field> > with multiple values.> > But with the addition of the
> observations, I need to know if the search> > term was founded within the
> observation, to wich dimension belongs the> > founded observations.> > And
> the same happens with the "Dimension type"> >> > 2. There can be many of
> these Dimension name, observations, type. The same> > applies for the Level
> name, observation - Fact name,type - Custom property> > name, value.> >> > 3.
> The levels. if the search term was founded in the level observation, I> >
> would need to know to which level name is related the level observation> >
> founded along with the dimension related, and finally the cube itserlf.> >> >
> Well... this was a bit long question to be my first one.> >> > Maybe what I
> want can't be done, maybe there could be some walkaround that> > someone
> knows it.> >> > I was thinking that if it can be posible to have a field,
> with additional> > info attached to the value, that is not searchable, it
> just needed when the> > field value is retrieved it.> >> > For example a
> Multi-value field called DimObs.> >> > Value1: "Observations related to the
> first dimension of the cube"> > Related info: "Dimension name1"> >> > Value2:
> "Observations related to the second dimension of the cube"> > Related info:
> "Dimension name2"> >> > When the search is performed and is founded in the
> DimObs, for example> > "first".> > Then the search found "first" int the
> DimObs, but I would need to retrieve> > the "Related info" to know to which
> Dimension belongs the observations> > founded.> >> > Thanks in advance for
> keeping with me till the end of this mail and for> > any suggestions that
> could give me.> >> > Roger Camargo> > UMSS "University"> > Cochabamba -
> Bolivia> >> >
> _________________________________________________________________> > Express
> yourself instantly with MSN Messenger! Download today it's FREE!> >
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/> >> >> >> >
> ------------------------------> > Express yourself instantly with MSN
> Messenger! MSN
> Messenger<http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/>> >
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
