10/02/17

Permalink 03:40:59 pm, by mholmes, 70 words, 14 views   English (CA)
Categories: Activity log; Mins. worked: 180

Refactoring for eXist 3.0

The new 3.0 has a bug with namespaces which can be worked around by refactoring a bit; since the refactoring actually produces better code, I've done it for several projects including Mariage. I've also reworked the search functionality so that it handles the problem case of a large document with hundreds of hits. Other layout and style bugfixes also done, and a couple of obvious things added to the stopword list.

22/12/16

Permalink 03:44:59 pm, by mholmes, 82 words, 18 views   English (CA)
Categories: Activity log; Mins. worked: 120

Generic search functionality work

Made a number of tweaks to the way the search currently works, but principally worked on generic code in the hcmc/xquery/xq-utils.xqm library to convert user-friendly search-box input into the XML syntax that eXist can use to talk to Lucene. This seems to be working well, although I haven't yet found a way to put it into practice because we're still using a string-construct-and-eval approach to filtered queries. It may be just a case of using the XQuery serialize() function.

21/12/16

Permalink 04:35:19 pm, by mholmes, 235 words, 20 views   English (CA)
Categories: Activity log; Mins. worked: 360

More work on search and nuances of search links

As I hack away at search testing, I'm discovering more and more little tweaks that are more than nice-to-have. Today I fixed a bunch of bugs in processing of ambitious search strings (quoted phrases are not supported yet, although I have half-a-plan for that). I also decided that search-string highlighting in a document that you have found is better done using a much simpler search string than the one you used to find documents in the collection (for instance, you don't want minused terms in the document highlighter because it causes eXist to return nothing, for some reason). So I now have a clever conversion of the original search string that is appended to the URL of the document link in the initial search results.

I've also fixed the display of the gravures so that a search result link will pop up the containing annotation, and also so that a link to the id of an element which is not an annotation itself, but is inside one, will cause the annotation to be shown.

We're clearly down to minor tweaks at this stage, so we're close. PS is still working on a couple of cosmetic issues. I'm thinking that there should be some more sophisticated diagnostics to catch broken links; I don't think that check is currently finding links that point to an element in a document which is not one of the ref docs.

20/12/16

Permalink 04:12:59 pm, by mholmes, 68 words, 21 views   English (CA)
Categories: Activity log; Mins. worked: 180

Last tweaks to eXist search and some display bugs

PS is working on the styling of the results page, and fixing a bug in scrolling of marginal page-numbers in normalized documents; I've fixed some other bits and pieces related to search, parameterized the build process so that I can easily build a full eXist XAR (1.4GB) locally without making Jenkins do it, and tested the big XAR on a local eXist (it works well). We're getting closer.

16/12/16

Permalink 02:48:23 pm, by mholmes, 43 words, 24 views   English (CA)
Categories: Activity log; Mins. worked: 180

Search with image fragments now working

I think this was the last piece of the puzzle for the Mariage eXist app. I haven't yet tested building the complete webapp; I'll do that soon. Meanwhile, there's one issue regarding the display of the gravures that I'm working with PS on.

09/11/16

Permalink 03:27:37 pm, by mholmes, 429 words, 21 views   English (CA)
Categories: Activity log; Mins. worked: 120

Working on search

I've implemented search result caching in Mariage, and done a bunch more work to bring it up to speed with what I learned in the Graves project. However, I'm now faced with a problem in search design which also afflicts MoEML, summarized here:

Imagine you want to find "amour" in your documents. You search for "amour".

It finds (say) thirty documents which contains "amour". It returns the first ten (it's paging in sets of ten results), and it sets about giving you all the keyword-in-context display results for each document.

Now, the first document has 200 instances of "amour". So the search code has to do a kwic expand operation on all 200 of those results in order to give you 200 keyword-in-context fragments for that document. These operations take a long time, so it takes ages for your results to come back.

If your results page contains ten documents, each of which has 200 hits, you're now processing 2,000 hits to give a single page of results.

In the Graves project, this isn't an issue, because all the documents are tiny (one diary entry). But in Mariage and MoEML, we have a combination of very small (one poem, one little article) and very large (Satire Menipée, Stow) documents.

One option is that instead of returning all the hits for a document, you just return (say) the first five, with a note "195 more", and the option to search only that document. If you take that option, you see hits only from that document, but paged in sets of ten.

Another option is to treat the search as a search of the collection itself, so that every hit is a separate "result"; in that case, in our imaginary scenario, the first 200 hits (i.e. the first 20 pages of results) come from the first large document, and you have to get to page 21 before you see anything from the next document.

Another option is to search at the granularity of smaller fragments rather than full-scale documents (Stow chapters, etc.). The problem with that can be seen in this example, where search results from the same play are scattered around because each scene is searched as if it were a separate document.

I have a vague notion that you might let users search "FOR DOCUMENTS" (in which case they'd get summaries with the first one or two hits, with documents ordered by hit-count) or "IN DOCUMENTS" (in which case each individual hit in a document would be a separate "result" on the page. But I'm not sure how easy that would be for users to understand.

08/11/16

Permalink 04:38:00 pm, by mholmes, 26 words, 27 views   English (CA)
Categories: Activity log; Mins. worked: 60

Fix for repeating title bug; addition of XAR icon

Fixed the bug where the docTitle was repeated at the beginning of introductory fragment documents. Also created an application icon for use in the XAR file.

28/10/16

Permalink 02:31:28 pm, by mholmes, 142 words, 32 views   English (CA)
Categories: Activity log; Mins. worked: 120

Mariage: fixing the history/search/ajax interaction

Worked with GN to fix some issues we've identified with AJAX searches which are pushed into the history stack with JavaScript. The solution (in search.js) depends on a couple of factors:

  • When a page reloads as a result of the use of the back button, the window's onload event does not fire, therefore the URK is not parsed and the search is not done. The solution here is to use the window's onpopstate event to trigger the same behaviour.
  • When a search is sent off and a new URL-encoded version of that search is ready to be pushed into the history stack, check that it's not identical to the current one; if it is, don't put it in the stack, otherwise you'll have two copies of the same URI in the stack.

Current solution tested and working on Chromium and Firefox.

26/10/16

Permalink 04:34:36 pm, by mholmes, 96 words, 25 views   English (CA)
Categories: Activity log; Mins. worked: 360

eXist search now working with AJAX

As of today:

  • JS/AJAX search is now working, using a simpler AJAX approach that I might generalize to replace js.jx.
  • Search params are pushed into the window history.
  • Loading a saved search URI populates the form and runs the search.
  • A large list of French stopwords is implemented, although we're still using the standard analyzer.
  • Pages are now being served as XHTML from eXist, which makes the CSS work properly on Chrome.

Lots of work still to do, including making search highlighting apply to document display, and making image search retrieve an image "fragment".

19/10/16

Permalink 03:50:16 pm, by mholmes, 63 words, 29 views   English (CA)
Categories: Activity log; Mins. worked: 60

Confusion over hyphenation

I erroneously gave CC the instruction to use pc/@force="weak" for hyphens that should be retained; and she misunderstood and added it to hyphens that should be dropped. This resulted in a bit of unnecessary encoding in a short text. I've fixed the text, revised the instructions and tweaked the XSLT handling, and with luck everything should work for the next text.

:: Next Page >>

Mariage

Faut-il se marier? La question de Panurge s’avère incontournable en Occident, surtout à partir de la contre-réforme. Des débuts de la Concile de Trente en 1545 jusqu’à la fin du règne de Louis XIV, la tentative de renouveler le mariage se heurte en France à l’intervention croissante de la monarchie dans cette institution dominée auparavent par l’Église. La rencontre entre ces deux autorités fut tumultueuse mais propice au foisonnement des documents qui font l’objet de ce site : « l’imaginaire nuptial » se compose de divers genres textuels, chacun ayant son caractère propre, mais tous traitant des peurs, des désirs et des fantasmes de plus en plus visibles dans la société d’Ancien Régime grâce aux débats soulevés par la nouvelle problématique de l’union conjugale. L’accent pour le moment est sur les textes et images misogames qui font partie d’un renouveau de la Querelle des femmes pendant les 25 premières années du XVIIe siècle.

Reports

Categories

March 2017
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

XML Feeds