Hardy, I understand that discussions about the search and browse functions are technical issues. But before technical things happen, there needs to be general discussion among the users: what are the advantages and disadvantages of the Discovery and the traditional Search? Why have some users put the money or effort into customizations? I suspect that outside of the "techies" very few users even know they have options.
It says in the manual for 3.2 that: "Search is an essential component of discovery in DSpace. Users' expectations from a search engine are quite high, so a goal for DSpace is to supply as many search features as possible." Have there been discussions with the non-technical user community to determine what features really are important? It seems as though there is a large user base for DSpace, but I suspect most of the discussion is among the tech folks, not the non-tech user community. (I'm not even sure how you would go about communicating with those people.) My usage stats indicate that the interaction with our open collections is coming from the web - folks accessing the bitstreams directly from web search engines, not through the native DSpace search. Thus, these aren't actual users of DSpace "Search". (I base this on the fact that bitstream downloads often greatly exceed item views.) What I'd like to know is: What search functions do "actual" end users want and need? How do we identify "actual" end users and communicate with them? Richard Jizba Health Sciences Library Creighton University (402) 280-5142 [email protected] -----Original Message----- From: Pottinger, Hardy J. [mailto:[email protected]] Sent: Thursday, February 13, 2014 3:03 PM To: Jizba, Richard; [email protected] Cc: [email protected] Subject: Re: [Dspace-general] Search in DSpace Hi, I note that this discussion is taking place on DSpace-general, it's probably best-suited for DSpace-tech. I say that mostly because I'm about to link to technical info :-) However, since it started in -general I'll leave it here. Richard, your existing Lucene customizations (in particular your custom filter code) are very likely portable to Solr [1]. I'm not promising Shangri-La, but, it's likely pretty workable. I have repository managers here who were interested in implementing the non-Porter stemming analyzer, enough that they asked me to work towards making that option configurable for DSpace. With a bunch of help from the community, we made that happen for DSpace [2]. I am *sure* we can get DSpace to do what you need, no matter the specifics of the search back-end. As we trundle on down the road to DSpace 5.0, I hope you'll continue to help us ensure the system remains usable for you and the community. Thanks! [1] https://wiki.apache.org/solr/SolrPlugins [2] https://jira.duraspace.org/browse/DS-849 -- HARDY POTTINGER <[email protected]> University of Missouri Library Systems http://lso.umsystem.edu/~pottingerhj/ https://MOspace.umsystem.edu/ "And remember, also" added the Princesss of Sweet Rhyme, "that many places you would like to see are just off the Map and many things you want to know are just out of sight or a little beyond your reach. But someday you'll reach them after all, for what you learn today, for no reason at all, will help you discover all the wonderful secrets of tomorrow." --Norton Juster, The Phantom Tollbooth On 2/13/14 1:58 PM, "Jizba, Richard" <[email protected]> wrote: >Solr may build on Lucene, but it may also inhibit me from taking real >advantage of Lucene. We had that problem a couple of years ago with the >porter stem filter. We couldn't conduct the kind of searches we wanted >because the porter stem filter stemmed our search terms -- and at the >time, there wasn't an easy way to turn it off. > >I understand faceting, but I also know that sometimes the most >effective way to search is to let people who know how to search do it >in the most direct way possible. It's particularly true when they >create the collections they want to search. We have some collections >that are only searched by the people who make them. They are good >searchers who know what they are doing. > >Faceting, it seems to me, is aimed at the naïve user who doesn't know >anything about searching. Do such people actually search DSpace >directly through the interface, or do their searches originate in >Google, Bing, etc? In any case, we have some user groups with closed >collections in our repository and they need the traditional search and >browse functions. I just want to make sure that future dspace >developments don't adversely impact their needs. Just telling me that >Solr builds on Lucene doesn't really answer the question. > >Richard Jizba >Health Sciences Library >Creighton University >(402) 280-5142 >[email protected] > >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >helix84 >Sent: Thursday, February 13, 2014 11:23 AM >To: Jizba, Richard >Cc: [email protected] >Subject: Re: [Dspace-general] Search in DSpace > >Hi Richard, >just a short reply. > >Are you aware that Solr (Discovery in DSpace uses Solr) builds on Lucene? >They even support the same syntax with some minor differences and even >that is configurable. The issue is not that Lucene is worse than Solr >or anything, it's just that Solr brings many features that aren't in >pure Lucene. The reason why we dislike keeping both is that there's a >significant development, maintenance and support burden for DSpace >commiters to keep both. Count with me - two search backends times two >UIs (plus other interfaces like REST API in the works) are four wildly >different systems to work with. DSpace is not just one platform, it's a >collection of platforms. If we converge upon a single search platform >(I don't see this happening with UIs), we'll have more time to put >towards improving DSpace and adding new features thanks to not doing >double the amount of work. This will make DSpace better in the long term. > >From what you said, it seems to me that everything you have should be >also possible to do in Discovery. I do understand that changing your >highly customized implementation from Lucene to Solr is a lot of work. >But it has very tangible advantages. > > >Regards, >~~helix84 > >Compulsory reading: DSpace Mailing List Etiquette >https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >----------------------------------------------------------------------- >--- >---- >Android apps run on BlackBerry 10 >Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >Now with support for Jelly Bean, Bluetooth, Mapview and more. >Get your Android app in front of a whole new audience. Start now. >http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.c >lkt >rk >_______________________________________________ >Dspace-general mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/dspace-general ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Dspace-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-general
