Sorry but that was BAAAAAADDDD Sent from my iPad (excuse the terseness) David A Lee [email protected] 812-630-7622
On Aug 20, 2013, at 3:53 PM, "Ron Hitchens" <[email protected]> wrote: > > --- > Ron Hitchens {[email protected]} +44 7879 358212 > > > On Aug 20, 2013, at 7:26 PM, Jason Hunter <[email protected]> wrote: > >> MarkMail did #1 but has the downside as you list. You can eliminate the >> downside by upping quality over time and adjusting down the quality weight >> on the search. (That assumes you don't have any other factors in the quality >> calculation except recency.) Maybe once in a while reset things globally so >> the numbers don't get ridiculous. >> >> MarkLogic 7 adds scoring to range index values, which is what you really >> want. > > I'll take it. But I've got to get to 6 before I can get to 7. > > Why was MarkLogic 6 afraid of MarkLogic 7? Because 7 8 9. > > Sorry. > >> Sent from my iPhone >> >> On Aug 20, 2013, at 11:10 AM, Ron Hitchens <[email protected]> wrote: >> >>> >>> What are the techniques out there for giving newer documents >>> higher relevance? My target is MarkLogic 5.x, but 6.x may be in >>> play before long. >>> >>> There are two schemes that I am aware of, neither of which feels >>> very elegant: >>> >>> 1) Give documents a high quality value when ingested. Periodically >>> crawl the content and for any document with positive quality, reduce >>> its quality according to some algorithm until the quality reaches zero. >>> >>> This gives the best control over "freshness", but has the disadvantage >>> of causing potentially large numbers of updates on each pass with the >>> attendant merges and disk I/O & CPU load. >>> >>> 2) Replicate the "real" query n times, each and-ed with a time-based >>> query against the insertion date. All of these are or-ed together >>> with descending weights for older dates. >>> >>> This does't require changing documents to tweak their freshness. But >>> it also means you have a stair-step function of n-steps, which may not >>> be very precise - and which wouldn't scale very well for large values >>> of n. And unfortunately, since the queries would be time-based, you >>> can't pre-register them ahead of time. >>> >>> Any other clever techniques that you've used? >>> >>> --- >>> Ron Hitchens {[email protected]} +44 7879 358212 >>> >>> >>> >>> >>> _______________________________________________ >>> General mailing list >>> [email protected] >>> http://developer.marklogic.com/mailman/listinfo/general >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
