You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mahout.apache.org by Fernando Tapia Rico <fe...@gmail.com> on 2011/05/17 18:49:07 UTC
MongoDataModel
Hi all,
I've been using Mahout for a while but I didn't find a DataModel for
MongoDB, so I decided to create my own implementation. I didn't find any
issue with my implementation, and I found it really helpful, so I would like
to share it with the community (and be a Mahout contributor). I'm attaching
the java source, and here is a taste recommender using this DataModel (
http://dl.dropbox.com/u/17178183/Recommender.zip). This project contains
some unit tests *src/test/TestMongoDataModel* for the MongoDataModel. It
also includes a test console in *src/TestStarter. *
**Another way to test it, is to deploy the war file and access to the REST
service (/users/{userID}/recommendUsers, /users/{userID}/recommendItems).
To config the interactive console (*src/TestStarter*) you need to set the
parameters into *recommender.properties.*
Hope you enjoy the app as I do.
Best Regards
Fernando Tapia Rico
www.fernandotapiarico.com
Re: MongoDataModel
Posted by Fernando Tapia Rico <fe...@gmail.com>.
Hi,
I took Grant's advice (Fernando, I would say just go ahead and put your
patch up against core for now and we'll work this out. This discussion
shouldn't derail you from putting up a reasonable first patch based on the
current structure -- i.e. put the model where all the other impl. models are
for now) and I submitted a patch on issue #705.
https://issues.apache.org/jira/browse/MAHOUT-705
Hope is all ok.
Best regards,
Fernando Tapia Rico
On Wed, May 18, 2011 at 4:20 PM, Sean Owen <sr...@gmail.com> wrote:
> Of course. I agree about JDBC. In practice, since JDBC APIs are a part of
> core Java, not JavaEE, it doesn't really do any harm dependency-wise to
> leave it in core. But it can move too indeed just for theoretical reasons.
>
> On Wed, May 18, 2011 at 2:54 PM, Grant Ingersoll <gsingers@apache.org
> >wrote:
> >
> > One person's core is another's non-core. ;-)
> >
> > I don't personally use JDBC much any more, so it isn't a "core" thing to
> me
> > and would be much more likely to use something like HBase/Cassandra/Mongo
> > (perhaps even Solr/Lucene), etc. (The big difference, I suppose, is that
> > Java has first order JDBC support, whereas it doesn't have first order
> NoSQL
> > support)
> >
> >
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
Of course. I agree about JDBC. In practice, since JDBC APIs are a part of
core Java, not JavaEE, it doesn't really do any harm dependency-wise to
leave it in core. But it can move too indeed just for theoretical reasons.
On Wed, May 18, 2011 at 2:54 PM, Grant Ingersoll <gs...@apache.org>wrote:
>
> One person's core is another's non-core. ;-)
>
> I don't personally use JDBC much any more, so it isn't a "core" thing to me
> and would be much more likely to use something like HBase/Cassandra/Mongo
> (perhaps even Solr/Lucene), etc. (The big difference, I suppose, is that
> Java has first order JDBC support, whereas it doesn't have first order NoSQL
> support)
>
>
Re: MongoDataModel
Posted by Grant Ingersoll <gs...@apache.org>.
On May 18, 2011, at 9:32 AM, Sean Owen wrote:
> On Wed, May 18, 2011 at 12:58 PM, Grant Ingersoll <gs...@apache.org>wrote:
>
>>
>> Actually, I think it is core at this point, since we moved the
>> Vectorization stuff to core. Unfortunately, we need Lucene core in order to
>> get the baseline definitions of TokenStreams for Vectorization.
>>
>
> Scratch that, yeah it's reasonably embedded.
>
>
>>
>> Agreed. I'm open to the move, just wanted to hear more about what it would
>> look like. I think it makes sense that all DataModel implementations move
>> along with it, other than the base classes, as a MySQLJDBCDataModel is in
>> the same class of things as a Mongo one (or Cassandra or HBase, etc.)
>>
>
> I don't think most implementations should move, no. Most are "core" to the
> project. Ones based on backing stores used by some but not many users are
> not core.
One person's core is another's non-core. ;-)
I don't personally use JDBC much any more, so it isn't a "core" thing to me and would be much more likely to use something like HBase/Cassandra/Mongo (perhaps even Solr/Lucene), etc. (The big difference, I suppose, is that Java has first order JDBC support, whereas it doesn't have first order NoSQL support)
>
> I'd like to reiterate I don't think this is specific to collaborative
> filtering at all. Right?
Yes.
>
>
>>
>> Likewise, we could do the same with our classification storage
>> implementations. (In fact, I wonder if there is duplication going on between
>> the Taste DataModel and the Classifier ones, at least a very low level)
>>
>
> I strongly doubt it, the DataModel implementations are pretty specific to
> recommenders for performance. Generalizing them breaks that quickly.
I mostly was wondering if there were lower level commonalities in the implementations, i.e. the pieces that actually talk to the storage that could be shared.
Ultimately, let's go for it and we can continue to refactor over time as the idea evolves.
-Grant
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
On Wed, May 18, 2011 at 12:58 PM, Grant Ingersoll <gs...@apache.org>wrote:
>
> Actually, I think it is core at this point, since we moved the
> Vectorization stuff to core. Unfortunately, we need Lucene core in order to
> get the baseline definitions of TokenStreams for Vectorization.
>
Scratch that, yeah it's reasonably embedded.
>
> Agreed. I'm open to the move, just wanted to hear more about what it would
> look like. I think it makes sense that all DataModel implementations move
> along with it, other than the base classes, as a MySQLJDBCDataModel is in
> the same class of things as a Mongo one (or Cassandra or HBase, etc.)
>
I don't think most implementations should move, no. Most are "core" to the
project. Ones based on backing stores used by some but not many users are
not core.
I'd like to reiterate I don't think this is specific to collaborative
filtering at all. Right?
>
> Likewise, we could do the same with our classification storage
> implementations. (In fact, I wonder if there is duplication going on between
> the Taste DataModel and the Classifier ones, at least a very low level)
>
I strongly doubt it, the DataModel implementations are pretty specific to
recommenders for performance. Generalizing them breaks that quickly.
Re: MongoDataModel
Posted by Grant Ingersoll <gs...@apache.org>.
On May 18, 2011, at 6:58 AM, Sean Owen wrote:
> The reasoning that led to 'taste-webapp' is what leads to create an expanded
> 'mahout-integration'.
>
> When I contributed my code, some folks asked, hmm, could we toss your EJB
> and web services integration, because it seems unfortunate to make the whole
> build depend on the EJB APIs and the Axis services. EJBs are defunct enough
> we just deleted that. Web services are not, but this integration was not put
> into core. It could have been, but it was better to farm it out.
>
> The only reason it was called 'taste-webapp', which I sense is striking
> people as some kind of issue, is because that was the only thing it happened
> to contain.
>
> But, we didn't put it in examples, whether by accident or design, and that
> sounds right to me. It's not just an example of how to use Mahout. It is
> something a user may use.
>
>
> Consider the Lucene integration points. These are actually in core (not
> examples as I thought). I don't believe that feels quite right in light of
> the above thinking, which sounds right to me. "Most" Mahout usage does not
> involve Lucene. Some does. Lucene isn't core to Mahout, so probably
> shouldn't be in core.
>
Actually, I think it is core at this point, since we moved the Vectorization stuff to core. Unfortunately, we need Lucene core in order to get the baseline definitions of TokenStreams for Vectorization.
> Should it be in examples? because there is also some Lucene stuff there.
> Better place, but not quite. Isn't this somewhere "more core" than just
> examples of end user usage, but not core?
>
>
> And now we have MongoDB integration. Would we like to put it in core? No, I
> don't think so, per above. Is it just an example? Not really, though that's
> a better place. It feels again somewhere in between, in the same place that
> the web services integration fell.
Agreed. I'm open to the move, just wanted to hear more about what it would look like. I think it makes sense that all DataModel implementations move along with it, other than the base classes, as a MySQLJDBCDataModel is in the same class of things as a Mongo one (or Cassandra or HBase, etc.)
Likewise, we could do the same with our classification storage implementations. (In fact, I wonder if there is duplication going on between the Taste DataModel and the Classifier ones, at least a very low level)
>
>
> That's "taste-webapp" then, though of course the name would no longer be
> accurate. So just change the name. (Rather than make n new modules for each
> integration, right?)
>
> And then I propose moving things like Lucene touch points there, yes.
>
I'm not sure it can, unless you are moving all the Vectorization stuff there. I think what we are seeing evolve here is a need for an ETL and Persistence layer that contains all of these optional bits. Not sure yet on where that belongs, although mahout-integration seems fine. We probably could somehow work in what is in Utils there too and drop Utils (or at least lighten it).
So, could mahout-integration look like:
1. ETL tools (Iterables, Vectorization)
2. Storage mechanisms
3. Web services/REST
Utils would keep the various other utils/helper classes.
>
>
> Nothing more. This is not any attempt to abstract-ify anything further.
> Hadoop stuff remains in core since it's pretty core, for example. It's just
> rearranging modules in a way that, to me, seems both more logical and more
> consistent with past decisions.
>
>
+1.
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
The reasoning that led to 'taste-webapp' is what leads to create an expanded
'mahout-integration'.
When I contributed my code, some folks asked, hmm, could we toss your EJB
and web services integration, because it seems unfortunate to make the whole
build depend on the EJB APIs and the Axis services. EJBs are defunct enough
we just deleted that. Web services are not, but this integration was not put
into core. It could have been, but it was better to farm it out.
The only reason it was called 'taste-webapp', which I sense is striking
people as some kind of issue, is because that was the only thing it happened
to contain.
But, we didn't put it in examples, whether by accident or design, and that
sounds right to me. It's not just an example of how to use Mahout. It is
something a user may use.
Consider the Lucene integration points. These are actually in core (not
examples as I thought). I don't believe that feels quite right in light of
the above thinking, which sounds right to me. "Most" Mahout usage does not
involve Lucene. Some does. Lucene isn't core to Mahout, so probably
shouldn't be in core.
Should it be in examples? because there is also some Lucene stuff there.
Better place, but not quite. Isn't this somewhere "more core" than just
examples of end user usage, but not core?
And now we have MongoDB integration. Would we like to put it in core? No, I
don't think so, per above. Is it just an example? Not really, though that's
a better place. It feels again somewhere in between, in the same place that
the web services integration fell.
That's "taste-webapp" then, though of course the name would no longer be
accurate. So just change the name. (Rather than make n new modules for each
integration, right?)
And then I propose moving things like Lucene touch points there, yes.
Nothing more. This is not any attempt to abstract-ify anything further.
Hadoop stuff remains in core since it's pretty core, for example. It's just
rearranging modules in a way that, to me, seems both more logical and more
consistent with past decisions.
On Wed, May 18, 2011 at 11:44 AM, Grant Ingersoll <gs...@apache.org>wrote:
>
> Right now, we have taste-web, and it pretty much just contains the things
> necessary to build Taste as a web service.
>
> All of our models are currently in core.
>
> Are you proposing, then, to have an integration model and in it would be
> all the models other than the abstract definitions? And then are you also
> proposing to extend it to have other integration pieces?
>
>
>
Re: MongoDataModel
Posted by Grant Ingersoll <gs...@apache.org>.
(Fernando, I would say just go ahead and put your patch up against core for now and we'll work this out. This discussion shouldn't derail you from putting up a reasonable first patch based on the current structure -- i.e. put the model where all the other impl. models are for now)
On May 18, 2011, at 6:34 AM, Ted Dunning wrote:
> Plausible.
>
> On Wed, May 18, 2011 at 3:31 AM, Sean Owen <sr...@gmail.com> wrote:
>
>> It happens that this, and the one thing that lives in taste-webapp, concern
>> one part of Mahout. There are many other things that can live in such a
>> module, and I don't see why we'd restrict it? For example, think about
>> integration points with Lucene from examples. They really aren't "examples"
>> but actual code to be used as integration. That's the kind of thing that
>> could properly live in the misnamed integration module that we already
>> have.
Right now, we have taste-web, and it pretty much just contains the things necessary to build Taste as a web service.
All of our models are currently in core.
Are you proposing, then, to have an integration model and in it would be all the models other than the abstract definitions? And then are you also proposing to extend it to have other integration pieces?
>>
>> On Wed, May 18, 2011 at 11:21 AM, Ted Dunning <te...@gmail.com>
>> wrote:
>>
>>> But this is really totally focussed on integration of taste, isn't it?
>>> What
>>> other integration is there?
>>
Re: MongoDataModel
Posted by Ted Dunning <te...@gmail.com>.
Plausible.
On Wed, May 18, 2011 at 3:31 AM, Sean Owen <sr...@gmail.com> wrote:
> It happens that this, and the one thing that lives in taste-webapp, concern
> one part of Mahout. There are many other things that can live in such a
> module, and I don't see why we'd restrict it? For example, think about
> integration points with Lucene from examples. They really aren't "examples"
> but actual code to be used as integration. That's the kind of thing that
> could properly live in the misnamed integration module that we already
> have.
>
> On Wed, May 18, 2011 at 11:21 AM, Ted Dunning <te...@gmail.com>
> wrote:
>
> > But this is really totally focussed on integration of taste, isn't it?
> > What
> > other integration is there?
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
It happens that this, and the one thing that lives in taste-webapp, concern
one part of Mahout. There are many other things that can live in such a
module, and I don't see why we'd restrict it? For example, think about
integration points with Lucene from examples. They really aren't "examples"
but actual code to be used as integration. That's the kind of thing that
could properly live in the misnamed integration module that we already have.
On Wed, May 18, 2011 at 11:21 AM, Ted Dunning <te...@gmail.com> wrote:
> But this is really totally focussed on integration of taste, isn't it?
> What
> other integration is there?
Re: MongoDataModel
Posted by Ted Dunning <te...@gmail.com>.
But this is really totally focussed on integration of taste, isn't it? What
other integration is there?
On Wed, May 18, 2011 at 2:53 AM, Sean Owen <sr...@gmail.com> wrote:
> Just make it more general still to expand its purpose to something more
> reasonable: mahout-integration. I think some stuff from examples can move
> over there, those things which are really utilities for connecting to some
> other system or project. It is something different from examples; it is
> non-core code that some users will nevertheless want to use and depend on.
> examples is something nobody should ever depend on, in theory.
>
> On Wed, May 18, 2011 at 10:48 AM, Grant Ingersoll <gsingers@apache.org
> >wrote:
>
> > +1 on something like "taste-integration" as a module instead of the
> poorly
> > named thing we have now.
> >
> > On May 18, 2011, at 2:19 AM, Sean Owen wrote:
> >
> > > There's no web app in here, it's just code that imports MongoDB
> > > classes. Yes it can be made 'provider' scope; it still means a lesser
> > > overhead of downloading the dependency. (kfs has been removed BTW.) I
> > > think we have the answer of farming this out to an 'integration'
> > > module that was have already under the wrong name.
> > >
> > > On Wed, May 18, 2011 at 3:23 AM, Ted Dunning <te...@gmail.com>
> > wrote:
> > >> I don't see a problem with an extra module if the webapp can somehow
> > resolve
> > >> the reference at run-time.
> > >>
> > >> And if the artifacts are in Maven, how bad is it to include them as
> > >> dependencies? If these could be made optional dependencies with
> > "provided"
> > >> scope, then anybody who doesn't use them wouldn't notice the lack.
> > Hadoop
> > >> does this with kfs, for instance. Nobody uses kfs any more, but they
> > could
> > >> if they wanted and nobody else has to resolve the dependency.
> > >>
> > >> On Tue, May 17, 2011 at 2:30 PM, Sean Owen <sr...@gmail.com> wrote:
> > >>
> > >>> Weird as it sounds, I think the best place is mahout-taste-webapp.
> > >>> Once the module is renamed it'll make more sense. But if you make a
> > >>> patch against that module with the right pom.xml changes it ought to
> > >>> be 99.9% what is needed.
> > >>>
> > >>> On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
> > >>> <fe...@gmail.com> wrote:
> > >>>> yep, I completely understand your concerns. So...What should I do?
> cos
> > >>>> I guess that I need to know where to place this to open the JIRA
> > >>>> ticket. I don't have any rush, I can wait until you guys decide what
> > >>>> is the best option for this DataModel.
> > >>>
> > >>
> >
> > --------------------------
> > Grant Ingersoll
> > Lucene Revolution -- Lucene and Solr User Conference
> > May 25-26 in San Francisco
> > www.lucenerevolution.org
> >
> >
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
Just make it more general still to expand its purpose to something more
reasonable: mahout-integration. I think some stuff from examples can move
over there, those things which are really utilities for connecting to some
other system or project. It is something different from examples; it is
non-core code that some users will nevertheless want to use and depend on.
examples is something nobody should ever depend on, in theory.
On Wed, May 18, 2011 at 10:48 AM, Grant Ingersoll <gs...@apache.org>wrote:
> +1 on something like "taste-integration" as a module instead of the poorly
> named thing we have now.
>
> On May 18, 2011, at 2:19 AM, Sean Owen wrote:
>
> > There's no web app in here, it's just code that imports MongoDB
> > classes. Yes it can be made 'provider' scope; it still means a lesser
> > overhead of downloading the dependency. (kfs has been removed BTW.) I
> > think we have the answer of farming this out to an 'integration'
> > module that was have already under the wrong name.
> >
> > On Wed, May 18, 2011 at 3:23 AM, Ted Dunning <te...@gmail.com>
> wrote:
> >> I don't see a problem with an extra module if the webapp can somehow
> resolve
> >> the reference at run-time.
> >>
> >> And if the artifacts are in Maven, how bad is it to include them as
> >> dependencies? If these could be made optional dependencies with
> "provided"
> >> scope, then anybody who doesn't use them wouldn't notice the lack.
> Hadoop
> >> does this with kfs, for instance. Nobody uses kfs any more, but they
> could
> >> if they wanted and nobody else has to resolve the dependency.
> >>
> >> On Tue, May 17, 2011 at 2:30 PM, Sean Owen <sr...@gmail.com> wrote:
> >>
> >>> Weird as it sounds, I think the best place is mahout-taste-webapp.
> >>> Once the module is renamed it'll make more sense. But if you make a
> >>> patch against that module with the right pom.xml changes it ought to
> >>> be 99.9% what is needed.
> >>>
> >>> On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
> >>> <fe...@gmail.com> wrote:
> >>>> yep, I completely understand your concerns. So...What should I do? cos
> >>>> I guess that I need to know where to place this to open the JIRA
> >>>> ticket. I don't have any rush, I can wait until you guys decide what
> >>>> is the best option for this DataModel.
> >>>
> >>
>
> --------------------------
> Grant Ingersoll
> Lucene Revolution -- Lucene and Solr User Conference
> May 25-26 in San Francisco
> www.lucenerevolution.org
>
>
Re: MongoDataModel
Posted by Grant Ingersoll <gs...@apache.org>.
+1 on something like "taste-integration" as a module instead of the poorly named thing we have now.
On May 18, 2011, at 2:19 AM, Sean Owen wrote:
> There's no web app in here, it's just code that imports MongoDB
> classes. Yes it can be made 'provider' scope; it still means a lesser
> overhead of downloading the dependency. (kfs has been removed BTW.) I
> think we have the answer of farming this out to an 'integration'
> module that was have already under the wrong name.
>
> On Wed, May 18, 2011 at 3:23 AM, Ted Dunning <te...@gmail.com> wrote:
>> I don't see a problem with an extra module if the webapp can somehow resolve
>> the reference at run-time.
>>
>> And if the artifacts are in Maven, how bad is it to include them as
>> dependencies? If these could be made optional dependencies with "provided"
>> scope, then anybody who doesn't use them wouldn't notice the lack. Hadoop
>> does this with kfs, for instance. Nobody uses kfs any more, but they could
>> if they wanted and nobody else has to resolve the dependency.
>>
>> On Tue, May 17, 2011 at 2:30 PM, Sean Owen <sr...@gmail.com> wrote:
>>
>>> Weird as it sounds, I think the best place is mahout-taste-webapp.
>>> Once the module is renamed it'll make more sense. But if you make a
>>> patch against that module with the right pom.xml changes it ought to
>>> be 99.9% what is needed.
>>>
>>> On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
>>> <fe...@gmail.com> wrote:
>>>> yep, I completely understand your concerns. So...What should I do? cos
>>>> I guess that I need to know where to place this to open the JIRA
>>>> ticket. I don't have any rush, I can wait until you guys decide what
>>>> is the best option for this DataModel.
>>>
>>
--------------------------
Grant Ingersoll
Lucene Revolution -- Lucene and Solr User Conference
May 25-26 in San Francisco
www.lucenerevolution.org
Re: MongoDataModel
Posted by Fernando Tapia Rico <fe...@gmail.com>.
Yeah, maybe I explained bad. I attached on this email just the DataModel.
The rest of the email, REST service, console, recommender etc, are related
to this file http://dl.dropbox.com/u/17178183/Recommender.zip. That was for
testing the DataModel and see a real example of MongoDataModel running. In
the code, your are right, there is no web app, it's like
https://builds.apache.org/hudson/job/Mahout-Quality/javadoc/org/apache/mahout/cf/taste/impl/model/jdbc/MySQLJDBCDataModel.htmlor
https://builds.apache.org/hudson/job/Mahout-Quality/javadoc/org/apache/mahout/cf/taste/impl/model/file/FileDataModel.htmlbut
adapted to MongoDB.
Cheers
On Wed, May 18, 2011 at 8:19 AM, Sean Owen <sr...@gmail.com> wrote:
> There's no web app in here, it's just code that imports MongoDB
> classes. Yes it can be made 'provider' scope; it still means a lesser
> overhead of downloading the dependency. (kfs has been removed BTW.) I
> think we have the answer of farming this out to an 'integration'
> module that was have already under the wrong name.
>
> On Wed, May 18, 2011 at 3:23 AM, Ted Dunning <te...@gmail.com>
> wrote:
> > I don't see a problem with an extra module if the webapp can somehow
> resolve
> > the reference at run-time.
> >
> > And if the artifacts are in Maven, how bad is it to include them as
> > dependencies? If these could be made optional dependencies with
> "provided"
> > scope, then anybody who doesn't use them wouldn't notice the lack.
> Hadoop
> > does this with kfs, for instance. Nobody uses kfs any more, but they
> could
> > if they wanted and nobody else has to resolve the dependency.
> >
> > On Tue, May 17, 2011 at 2:30 PM, Sean Owen <sr...@gmail.com> wrote:
> >
> >> Weird as it sounds, I think the best place is mahout-taste-webapp.
> >> Once the module is renamed it'll make more sense. But if you make a
> >> patch against that module with the right pom.xml changes it ought to
> >> be 99.9% what is needed.
> >>
> >> On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
> >> <fe...@gmail.com> wrote:
> >> > yep, I completely understand your concerns. So...What should I do? cos
> >> > I guess that I need to know where to place this to open the JIRA
> >> > ticket. I don't have any rush, I can wait until you guys decide what
> >> > is the best option for this DataModel.
> >>
> >
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
There's no web app in here, it's just code that imports MongoDB
classes. Yes it can be made 'provider' scope; it still means a lesser
overhead of downloading the dependency. (kfs has been removed BTW.) I
think we have the answer of farming this out to an 'integration'
module that was have already under the wrong name.
On Wed, May 18, 2011 at 3:23 AM, Ted Dunning <te...@gmail.com> wrote:
> I don't see a problem with an extra module if the webapp can somehow resolve
> the reference at run-time.
>
> And if the artifacts are in Maven, how bad is it to include them as
> dependencies? If these could be made optional dependencies with "provided"
> scope, then anybody who doesn't use them wouldn't notice the lack. Hadoop
> does this with kfs, for instance. Nobody uses kfs any more, but they could
> if they wanted and nobody else has to resolve the dependency.
>
> On Tue, May 17, 2011 at 2:30 PM, Sean Owen <sr...@gmail.com> wrote:
>
>> Weird as it sounds, I think the best place is mahout-taste-webapp.
>> Once the module is renamed it'll make more sense. But if you make a
>> patch against that module with the right pom.xml changes it ought to
>> be 99.9% what is needed.
>>
>> On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
>> <fe...@gmail.com> wrote:
>> > yep, I completely understand your concerns. So...What should I do? cos
>> > I guess that I need to know where to place this to open the JIRA
>> > ticket. I don't have any rush, I can wait until you guys decide what
>> > is the best option for this DataModel.
>>
>
Re: MongoDataModel
Posted by Ted Dunning <te...@gmail.com>.
I don't see a problem with an extra module if the webapp can somehow resolve
the reference at run-time.
And if the artifacts are in Maven, how bad is it to include them as
dependencies? If these could be made optional dependencies with "provided"
scope, then anybody who doesn't use them wouldn't notice the lack. Hadoop
does this with kfs, for instance. Nobody uses kfs any more, but they could
if they wanted and nobody else has to resolve the dependency.
On Tue, May 17, 2011 at 2:30 PM, Sean Owen <sr...@gmail.com> wrote:
> Weird as it sounds, I think the best place is mahout-taste-webapp.
> Once the module is renamed it'll make more sense. But if you make a
> patch against that module with the right pom.xml changes it ought to
> be 99.9% what is needed.
>
> On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
> <fe...@gmail.com> wrote:
> > yep, I completely understand your concerns. So...What should I do? cos
> > I guess that I need to know where to place this to open the JIRA
> > ticket. I don't have any rush, I can wait until you guys decide what
> > is the best option for this DataModel.
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
Weird as it sounds, I think the best place is mahout-taste-webapp.
Once the module is renamed it'll make more sense. But if you make a
patch against that module with the right pom.xml changes it ought to
be 99.9% what is needed.
On Tue, May 17, 2011 at 10:23 PM, Fernando Tapia Rico
<fe...@gmail.com> wrote:
> yep, I completely understand your concerns. So...What should I do? cos
> I guess that I need to know where to place this to open the JIRA
> ticket. I don't have any rush, I can wait until you guys decide what
> is the best option for this DataModel.
Re: MongoDataModel
Posted by Fernando Tapia Rico <fe...@gmail.com>.
yep, I completely understand your concerns. So...What should I do? cos
I guess that I need to know where to place this to open the JIRA
ticket. I don't have any rush, I can wait until you guys decide what
is the best option for this DataModel.
On Tuesday, May 17, 2011, Sean Owen <sr...@gmail.com> wrote:
> I'm talking about the DataModel -- there isn't a Recommender, is
> there? (Haven't looked at the code.)
> No, I mean that we don't want to introduce a dependency on MongoDB
> across the whole project just for this, but it could fit into an
> optional sub-module.
>
> On Tue, May 17, 2011 at 10:10 PM, Fernando Tapia Rico
> <fe...@gmail.com> wrote:
>> Thanks for the good responses. I will open a JIRA ticket, but...reading the
>> thread...where should I put this DataModel?
>> And, Sean, when you say "I would commit this to mahout-examples/ in a
>> heartbeat except that I'm
>> wondering about the issue of dependencies", are you talking about the
>> Recommender or the DataModel?
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
I'm talking about the DataModel -- there isn't a Recommender, is
there? (Haven't looked at the code.)
No, I mean that we don't want to introduce a dependency on MongoDB
across the whole project just for this, but it could fit into an
optional sub-module.
On Tue, May 17, 2011 at 10:10 PM, Fernando Tapia Rico
<fe...@gmail.com> wrote:
> Thanks for the good responses. I will open a JIRA ticket, but...reading the
> thread...where should I put this DataModel?
> And, Sean, when you say "I would commit this to mahout-examples/ in a
> heartbeat except that I'm
> wondering about the issue of dependencies", are you talking about the
> Recommender or the DataModel?
Re: MongoDataModel
Posted by Fernando Tapia Rico <fe...@gmail.com>.
Thanks for the good responses. I will open a JIRA ticket, but...reading the
thread...where should I put this DataModel?
And, Sean, when you say "I would commit this to mahout-examples/ in a
heartbeat except that I'm
wondering about the issue of dependencies", are you talking about the
Recommender or the DataModel?
Cheers
On Tue, May 17, 2011 at 10:18 PM, Sean Owen <sr...@gmail.com> wrote:
> It probably belongs in a renamed "mahout-taste-webapp" which is where
> we put the one similar thing in the project already. That can be
> "mahout-integration" or something.
>
> (Separately I'm conscious of an explosion of Maven modules... this
> isn't adding a new one, but, getting to be a lot of them.)
>
> On Tue, May 17, 2011 at 8:58 PM, Grant Ingersoll <gs...@apache.org>
> wrote:
> > Hmm, the license is AGPL, but then the drivers are ASL for MongoDB. What
> does this patch require?
> >
> > I suspect we will have other DataModels. I have heard interest in adding
> a Cassandra DataModel as well. Not sure if they belong in examples, but
> also agree they aren't "core" per se. Thoughts on where they belong?
>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
It probably belongs in a renamed "mahout-taste-webapp" which is where
we put the one similar thing in the project already. That can be
"mahout-integration" or something.
(Separately I'm conscious of an explosion of Maven modules... this
isn't adding a new one, but, getting to be a lot of them.)
On Tue, May 17, 2011 at 8:58 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Hmm, the license is AGPL, but then the drivers are ASL for MongoDB. What does this patch require?
>
> I suspect we will have other DataModels. I have heard interest in adding a Cassandra DataModel as well. Not sure if they belong in examples, but also agree they aren't "core" per se. Thoughts on where they belong?
Re: MongoDataModel
Posted by Grant Ingersoll <gs...@apache.org>.
Hmm, the license is AGPL, but then the drivers are ASL for MongoDB. What does this patch require?
I suspect we will have other DataModels. I have heard interest in adding a Cassandra DataModel as well. Not sure if they belong in examples, but also agree they aren't "core" per se. Thoughts on where they belong?
-Grant
On May 17, 2011, at 2:34 PM, Sean Owen wrote:
> Agree, that's the process, and agree this is cool.
>
> I would commit this to mahout-examples/ in a heartbeat except that I'm
> wondering about the issue of dependencies. It introduces a dependency
> on MongoDB in Maven just for this. Is that fine for examples, we
> think? It's not for core.
>
> On Tue, May 17, 2011 at 7:18 PM, Grant Ingersoll <gs...@apache.org> wrote:
>> Cool! Please see https://cwiki.apache.org/confluence/display/MAHOUT/How+To+Contribute on how to contribute, as the best way to get this in is via a patch on a JIRA ticket (please make sure you check the box saying you grant license to the ASF).
>>
>> -Grant
>>
Re: MongoDataModel
Posted by Sean Owen <sr...@gmail.com>.
Agree, that's the process, and agree this is cool.
I would commit this to mahout-examples/ in a heartbeat except that I'm
wondering about the issue of dependencies. It introduces a dependency
on MongoDB in Maven just for this. Is that fine for examples, we
think? It's not for core.
On Tue, May 17, 2011 at 7:18 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Cool! Please see https://cwiki.apache.org/confluence/display/MAHOUT/How+To+Contribute on how to contribute, as the best way to get this in is via a patch on a JIRA ticket (please make sure you check the box saying you grant license to the ASF).
>
> -Grant
>
Re: MongoDataModel
Posted by Grant Ingersoll <gs...@apache.org>.
Cool! Please see https://cwiki.apache.org/confluence/display/MAHOUT/How+To+Contribute on how to contribute, as the best way to get this in is via a patch on a JIRA ticket (please make sure you check the box saying you grant license to the ASF).
-Grant
On May 17, 2011, at 12:49 PM, Fernando Tapia Rico wrote:
> Hi all,
> I've been using Mahout for a while but I didn't find a DataModel for MongoDB, so I decided to create my own implementation. I didn't find any issue with my implementation, and I found it really helpful, so I would like to share it with the community (and be a Mahout contributor). I'm attaching the java source, and here is a taste recommender using this DataModel (http://dl.dropbox.com/u/17178183/Recommender.zip). This project contains some unit tests src/test/TestMongoDataModel for the MongoDataModel. It also includes a test console in src/TestStarter.
> Another way to test it, is to deploy the war file and access to the REST service (/users/{userID}/recommendUsers, /users/{userID}/recommendItems).
> To config the interactive console (src/TestStarter) you need to set the parameters into recommender.properties.
> Hope you enjoy the app as I do.
> Best Regards
>
>
> Fernando Tapia Rico
> www.fernandotapiarico.com