new branch
Gabriel Farrell
like to start a new branch to clean things up a bit. Here's the short
list of what we'd like to see in the new branch:
1. Follows Django project/app conventions.
2. Recreates present functionality for search, facets, i18n, rss, and
item view (but cleaner! :).
3. Makes room (by involving the database, most likely) for expanding
into tagging, comments, etc.
4. Set up a sort of Django API for Solr, similar to the database API.
The first point needs some consensus on naming. I propose to call the
project "helios" and the app "search". I don't want to get too deep
into a project-name-change discussion if it will stall things, but I
like "helios" a lot better than "fac-back-opac" (I think I've made
that pretty obvious). Also, I prefer "search" to "catalog" because
FBO/Helios could be extended to search across multiple indexes in a
way similar to LibraryFind or VuFind.
The fourth point is my main interest in getting involved in FBO, and
I'm not sure how best to implement it at this point, but a slick Solr
connection could be useful for the larger Django community and some
other projects I'm working on.
Gabe
Jodi Schneider
Glad you're getting involved, and I'm all for whatever you want to do.
That said, I've got a couple questions. Could you help me understand?
(1) What's the difference between a "search" and a "catalog"?
(I see that a "search" utility may operate on multiple indexes. Any other differences?)
(2) > a slick Solr connection could be useful for the larger Django community and some
> other projects I'm working on.
-Jodi
/me relurks
Gabriel Farrell
On Oct 4, 1:03 pm, "Jodi Schneider" <jodi.a.schnei...@gmail.com>
wrote:
> Gabe,
>
> Glad you're getting involved, and I'm all for whatever you want to do.
>
Hi Jodi. Thanks for the interest in my goofy ideas.
> That said, I've got a couple questions. Could you help me understand?
>
> (1) What's the difference between a "search" and a "catalog"?
> (I see that a "search" utility may operate on multiple indexes. Any other
> differences?)
>
In this context, I think of "catalog" as "an inventory of physical
resources". This is obviously a narrowing definition of catalog when
one takes into account the panoply of data and metadata that
constitutes most library catalogs these days (including Drexel's,
which is my most immediate concern), but it helps me better visualize
how the library apps I work on might relate to one another.
Given that definition of "catalog", "search" would then operate over
the catalog, the electronic journal holdings, the list of currently-
available e-books, the institutional repository, the web site, and, to
whatever extent they're accessible, either the summaries or contents
of other open and subscription databases. A great thing about Lucene
(and therefore Solr) is that multiple indexes can be searched almost
as easily as a single index, so my ideal setup at this time would be
an FBO/Helios front-end that would query a solr server that has an
index for each of our silos.
Some of the features that FBO now provides and may extend upon that
couple more closely with a catalog, such as individual item views,
comments, tagging, etc., might more appropriately reside in a
"catalog" app. As I've worked with Django on various things I've
grown to appreciate the way the project/app structure can more
logically organize the different parts of the whole.
These app names and divisions are just ideas off the top of my head.
I'm very interested in continuing discussion on this issue.
> (2) > a slick Solr connection could be useful for the larger Django
> community and some
> > other projects I'm working on.
>
> Could you say more about this? It sounds like you've got some interesting
> ideas/visions...
>
The main question I'm asking myself here is how much benefit it would
be to represent what's going on in Solr at the model level. On the
one hand, search index interfaces (and especially Solr's) act very
much like database interfaces. We can pull data from them and put
data into them. So why not treat it as a model?
On the other hand, Solr's RESTful interface might just be simple
enough, yet different enough from the Django DB API, that an attempt
to work it into a Django-model-like representation would result in a
more complicated interface that confuses more than it helps. In that
case, a couple of helper functions at the view level (which is what
Casey has already done, and might need just a little refinement) could
be the best route.
So those are my thoughts on the Django/Solr connection, which I won't
really be able to confirm until I've tried to put them in code.