fsteeg / drc Goto Github PK

Basic idea: use the compare editor to review changes made by other users. Depends on #5 (index) and somewhat on #9 (editor). Open question: how well does the compare editor work with e4/RAP?

Depends on #18

• First version depends only on #6
• Proper implementation depends on #5, #6, #7

Users should be able to give votes to corrections made by other users ('correct'/'not correct'), so that positive/negative votes can be summed up in profile

Depends on #5 (index)

• JUnit plug-in tests
• SWTBot

To avoid corrections being too different from OCR-text:

• limit length on word level
• no blanks

• What information is required (name, contact, location, access rights, age, language, region)?
• How to store user data?
• What else do we need to gather useful statistics?

The positional information from the OCR result PDFs (see #6) needs to be associated with the actual search index (in Lucene, see #5) in some form.

• Logic layer?
• Data layer? Lucene? Solr? Luke? DB?

Non-public, internal evaluation involving native speakers.

Screen cast?

Users could mark words/pages as correct, when other users give enough positive votes, the word/page is closed for editing

Via change log / history / details view - see Issue 30:http://github.com/fsteeg/drc/issues#issue/30

Get a basic e4 app running that can display highlighted words in the image.

Some related questions:

• How will we transform the raw text to basic wiki markup (and which)?
• Should we store the markup in the index or preprocess before displaying?
• How does the WikiText editor work with e4/RAP?

Basically depends on #5 (index) and #8 (highlighting).

Which framework to use for authentication and authorization?

Time stamps needed, see also issue 43.

Based on our plan to use Lucene, we could:

• Use Solr to store the OCR result PDF directly
• Get the raw text out of the OCR result PDF with iText, store that

This issue is related to getting and storing positional information, which needs to be associated with the texts stored in the index.

See also issue 42.

The OCR result PDFs contain line-base position information. It could be retrieved using regular expressions or line-based parsing (which is probably easier here).

The positional information should be associated with the actual index (#5).

Could show

• history
• live search results

As we only have starting positions of lines, we get wrong highlighting for words distant from the line start if the lines are tilted.

Connected to #39: Count positive votes?

Options: Search in all /latest, original version