Re: job ads ok?
No, that would be a violation of netiquette. Please just send them directly to me. On Thu, May 28, 2009 at 10:06 AM, Jodi Showers wrote: > Greetings, > > Is is ok to post solr job ads here? > > thanks. > Jodi >
Re: Opensearch XSLT
According to the guy in their booth, they support federated searches on engines that support OpenSearch (meaning you can use their federation tool to search content indexed by search engines that have an OpenSearch interface -- e.g., A9) but SearchServer '08 does NOT have an OpenSearch interface to it's native search functionality. You can write one using .NET or have one of their partners develop one for you. Bill On Nov 26, 2007 3:38 PM, Koji Sekiguchi <[EMAIL PROTECTED]> wrote: > Doesn't Microsoft push OpenSearch? > http://www.microsoft.com/presspass/press/2007/nov07/11-06SearchServer08ExpressPR.mspx > > Koji > > > Otis Gospodnetic wrote: > > Ed, > > Wunder minght be right. As far as I know, only A9 was pushing OpenSearch. > > Now that A9 is not *really* around much, I think nobody is pushing it. I > > don't know of anyone pushing GData either, other than Google, but Google is > > doing rather (too?) well these days. > > > > Otis > > -- > > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > > >
Re: Forced Top Document
The typical use case, though, is for the featured document to be on top only for certain queries. Like in an intranet where someone queries 401K or retirement or similar, you want to feature a document about benefits that would otherwise rank really low for that query. I have not be able to make sorting strategies work very well. Our approach has been to create a separate index of featured items that are tagged by the desired query. And then the results are placed in a different hit list as featured results (sort of like sponsored results). On 10/24/07, mark angelillo <[EMAIL PROTECTED]> wrote: > > Charlie, > > That's interesting. I did try something like this. Did you try your > query with a sorting parameter? > > What I've read suggests that all the results are returned based on > the query specified, but then resorted as specified. Boosting (which > modifies the document's score) should not change the order unless the > results are sorted by score. > > Mark > > On Oct 24, 2007, at 1:05 PM, Charlie Jackson wrote: > > > Do you know which document you want at the top? If so, I believe you > > could just add an "OR" clause to your query to boost that document > > very > > high, such as > > > > ?q=foo OR id:bar^1000 > > > > Tried this on my installation and it did, indeed push the document > > specified to the top. > > > > > > > > -Original Message- > > From: Matthew Runo [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, October 24, 2007 10:17 AM > > To: solr-user@lucene.apache.org > > Subject: Re: Forced Top Document > > > > I'd love to know this, as I just got a development request for this > > very feature. I'd rather not spend time on it if it already exists. > > > > ++ > > | Matthew Runo > > | Zappos Development > > | [EMAIL PROTECTED] > > | 702-943-7833 > > ++ > > > > > > On Oct 23, 2007, at 10:12 PM, mark angelillo wrote: > > > >> Hi all, > >> > >> Is there a way to get a specific document to appear on top of > >> search results even if a sorting parameter would push it further > >> down? > >> > >> Thanks in advance, > >> Mark > >> > >> mark angelillo > >> snooth inc. > >> o: 646.723.4328 > >> c: 484.437.9915 > >> [EMAIL PROTECTED] > >> snooth -- 1.8 million ratings and counting... > >> > >> > > > > mark angelillo > snooth inc. > o: 646.723.4328 > c: 484.437.9915 > [EMAIL PROTECTED] > snooth -- 1.8 million ratings and counting... > > >
Re: Opensearch XSLT
There is a file ${SOLR_HOME}/conf/xslt/example_rss.xsl which is easily
modified to transform Solr's output to OpenSearch. Works great, though
fixing the date format is a hassle. The supported, searchable Solr date
format is not the OpensSearch standard.
On 10/12/07, Robert Young <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Does anyone know of an XSLT out there for transforming Solr's default
> output to Opensearch format? Our current frontend system uses
> opensearch so we would like to integrate it like this.
>
> Cheers
> Rob
>
Re: Solr and KStem
Hello, I would like to test this and have a few questions (please excuse what may seem naive questions). I would like to verify that this is purely a configuration feature -- since the schema.xml defines the analysis/tokerizer chain no other changes are required. Also, the source seems to say that a lower case factory needs to be "farther down" the tokenizer chain. So does this mean that the KStem factory appears before the lower case filter factory in the schema.xml. Is there a recommended (required?) tokenizer factory. I am using the WhiteSpaceFactory which seems OK. Finally, I take it that I need to remove the EnglishPorterFilterFactory item in the schema.xml -- or no? Thanks, Bill On 9/10/07, Wagner,Harry <[EMAIL PROTECTED]> wrote: > > Hi Yonik, > The modified KStemmer source is attached. The original KStemFilter is > now wrapped (and replaced) by KStemFilterFactory. I also changed the > path to avoid any naming collisions with existing Lucene code. > > I included the jar file also, for anyone who wants to just drop and > play: > > - put KStem2.jar in your solr/lib directory. > - change your schema to use: class="org.oclc.solr.analysis.KStemFilterFactory" cacheSize="2"/> > - restart your app server > > I don't know if you credit contributions, but if so please include OCLC. > Seems only fair since I did this on their dime :) > > Cheers! > harry > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik > Seeley > Sent: Friday, September 07, 2007 3:59 PM > To: solr-user@lucene.apache.org > Subject: Re: Solr and KStem > > On 9/7/07, Wagner,Harry <[EMAIL PROTECTED]> wrote: > > I've implemented a Solr plug-in that wraps KStem for Solr use. KStem > is > > considered to be more appropriate for library usage since it is much > > less aggressive than Porter (i.e., searches for organization do NOT > > match on organ!). If there is any interest in feeding this back into > > Solr I would be happy to contribute it. > > Absolutely. > We need to make sure that the license for that k-stemmer is ASL > compatible of course. > > -Yonik > >
Re: Indexing a URL
Thanks, Brian. On 9/5/07, Brian Whitman <[EMAIL PROTECTED]> wrote: > > > > It is apparently attempting to parse &en=499af384a9ebd18f in the > > URL. I am > > not clear why it would do this as I specified indexed="false." I > > need to > > store this because that is how the user gets to the original article. > > the ampersand is an XML reserved character. you have to escape it > (turn it into &), whether you are indexing the data or not. > Nothing to do w/ Solr, just xml files in general. Whatever you're > using to render the xml should be able to handle this for you. > > >
Indexing a URL
Hello, I am trying to post the following to my index: http://www.nytimes.com/2007/08/25/business/worldbusiness/25yuan.html?ex=1345694400&en=499af384a9ebd18f&ei=5088&partner=rssnyt&emc=rss The url field is defined as: However, I get the following error: Posting file docstor/ffc110ee5c9a2ed28c8f35aa243bb53b.xml to http://localhost:8983/news_feed/update Error 500 HTTP ERROR: 500ParseError at [row,col]:[3,104] Message: The reference to entity "en" must end with the ';' delimiter. It is apparently attempting to parse &en=499af384a9ebd18f in the URL. I am not clear why it would do this as I specified indexed="false." I need to store this because that is how the user gets to the original article. Is there any data type that simply ignores the characters in the field? I don't care that it can't be a search field. I've tried the "ignored" field type and it still gives me the same error. Thanks, Bill
