It seems that the normal use case is line=document with some exception
for cross-line indexing.
The edge case could be solved by either indexing additional 'two-line'
documents with lower boost or to have 'context' field with line
before/after where applicable (e.g. within same para). Then there
It's easy to then store a map of "term position" to line-number and page-number
along with each paragraph, or?
Paul
On 24 avr. 2013, at 16:24, Timothy Potter wrote:
> Chapter seems too broad and line seems too narrow -- have you thought
> about paragraph level? Something like:
>
> docID, book
Chapter seems too broad and line seems too narrow -- have you thought
about paragraph level? Something like:
docID, book fields (title, author, publisher, etc), chapter fields (#,
title, pages, etc), section fields (title, #, etc), sub-sectionN
fields, paragraph text, lines
Seems like line #'s wo
If you can represent your books in XML, then MarkLogic could do the job very
cleanly. It isn't free, but it is very good.
wunder
On Apr 23, 2013, at 6:47 PM, Jason Funk wrote:
> Is there a better tool than Solr to use for my situation?
>
>
> On Apr 23, 2013, at 5:04 PM, Jack Krupansky wrote:
Is there a better tool than Solr to use for my situation?
On Apr 23, 2013, at 5:04 PM, Jack Krupansky wrote:
> There is no simple, obvious, and direct approach, right out of the box. Sure,
> you can highlight passages of raw text, right out of the box, but that won't
> give you chapters, page
There is no simple, obvious, and direct approach, right out of the box.
Sure, you can highlight passages of raw text, right out of the box, but that
won't give you chapters, pages, and line numbers. To do all of that, you
would have to either:
1. Add chapter, page, and line number as part of t
