epidoc / efes Goto Github PK

The text disappears if @xml:lang is put either on a div[@type="textpart"] or ab. I tried putting it both on div[@type="edition"] and "textpart"/ab for the experiment, and it doesn't appear. Seems like the only possibility is to have it on div[@type="edition"].
Needs fixing for cases of multiple languages in one inscription.

With the addition of user-indices, the Solr file_path field as the means of identifying which Solr documents to remove on indexing needs to trigger off something other than the actual file path. "source_id" is a better name for the field.

Kiln currently lists available texts using metadata extracted directly from the TEI header, in order for users to be able to put some files in the right directory and immediately see them listed, without first indexing them in Solr.

I'd like to change that so that the information is retrieved from Solr. I think it's silly to have an entire code path that duplicates much of another one for the sole benefit of having something appear on screen one step earlier.

Any objections?

The links from indexed references to the single page of the corpus don’t work properly with grc indices. The reason seems to be that in the xml files a lot of elements (including titles) are not tagged with xml:lang=”grc” (simply because they are not in Ancient greek), hence they are not (well) displayed on the webpage; besides the not very elegant and time consuming solution of systematically duplicating those elements and adding a 'false' xml:lang='grc', is there the possiblity to change the behaviour of EFES’ indices?

Include the Epidoc example XSLT into EFES, with customisation points corresponding to the XSLT parameters.

This parallels #9.

We need a link to (a) view and (b) download the original Epioc XML files from each inscription page (probably as part of the footer view of the EFES template?).

The EpiDoc Stylesheets in the Kiln area of EFES need to be imported into the Git repo as an "external"/Submodule from EpiDoc/Stylesheets, rather than copied by hand. Commits from EFES in the direction of Stylesheets should never happen, and local customisations can be executed via the non-Kiln /stylesheets/epidoc directory, as documented.

At release 1.0, the external link should be to the tagged version of EpiDoc Stylesheets 9.0, rather than the head, but in the meantime while both are in development in tandem, let's get them in sync as quickly as possible.

It doesn't seem possible to add external links to the metadata and to the commentary.

(findplace, original location, mentioned places, etc.)

The index page for the EpiDoc Samples directory should:

• list all files by //titleStmt/title + idno[@type='filename']
• give a choice to view file in "inslib" or "iospe" layout (i.e. send a filename suffix that allows the pipeline to choose between $edn-structure= "iospe" | "inslib")

Other options (e.g. choose line-increment, diplomatic, verse) will be added later.

Another suggestion was that when a user has serched for a term or browsed through various facets (or both) to find a subset of inscriptions in the search interface, they be given the option to download a ZIP file containing the XML files of just those inscriptions that appear in the search results list. This would enable them to create a mini corpus of just 1st century religious texts, or just texts on marble from Rome, or just pre-5th century texts mentioning Agathe Tyche, or whatever.

(See https://github.com/papyri/navigator)

In the Origin Date Evidence facet the links to remove facet values in Cyrillic don't work.

Once the refactoring of Epidoc XSLT in #28 is done, those htm-tpl-struct-* templates that remain should either be deleted or added to the list of XSLT needing refactoring to work with EFES.

Can we try to copy over the faceted browse interface from the IOSPE kiln instance so that it can be used generically for EFES? This may need some more input from Alejandro and/or Miguel.

Clone and install EFES following instructions at http://kiln.readthedocs.org/en/latest/quickstart.html

Mac OSX 10.11.1

• Visit /search
• Select any faceted search result
• Pick any result link on the right hand side and click on it

Result:

An error occurred
The resource you requested was not found.

Stacktrace:

org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: 5.2.html
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:149)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
    at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:254)
    at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
    at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
    at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:254)
    at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
    at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
    at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:254)
    at org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:118)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:47)
    at org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:108)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:143)
    at org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:69)
    at org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:235)
    at org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:177)
    at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:254)
    at org.apache.cocoon.Cocoon.process(Cocoon.java:699)
    at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:698)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:505)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1094)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:432)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1028)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
    at org.eclipse.jetty.server.Server.handle(Server.java:445)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
    at org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
    at java.lang.Thread.run(Thread.java:745)

Clone and install EFES following instructions at http://kiln.readthedocs.org/en/latest/quickstart.html

Mac OSX 10.11.1

• Visit /search
• Enter an artibrary term in the search terms box and hit enter

Result:

An error occurred
Invalid element name. Invalid QName {fq%3Atext}
On line 1048575, column -1 of file:///$KILN_HOME/webapps/ROOT/sitemaps/../kiln/sitemaps/../../sitemaps/../stylesheets/solr/../../kiln/stylesheets/solr/merge-parameters.xsl:

(See how this is handled in Kiln and especially cf. IOSPE)

The iospe.5.*.xml files all have content in both English (@xml:lang='en') and Russian (@xml:lang='ru'). Currently, sending the file name along should return the English version; sending [filename]-ru.html should return the Russian version. I guess this will require a change in EpiDoc Example XSLT?

Maybe see if we can figure out a way to return both strings, and choose between them in the Cocoon view?

The existing EFES repo contains experimental work from early 2015, and is both 22 commits behind the Kiln master, and incompatible with Jamie's latest work on EFES. This content needs to be entirely overwritten with the latest version of Kiln (/EFES) and development to take place in this location going forward.

A desideratum that came from one of our stakeholders, and we have started to discuss the practicability of, is the ability to filter the results in the main indices (names, words, abbreviations, symbols, etc.) by some of all of the values of the facets in the browse function. I.e. if we have an index of abbreviations, which lists all the instances of that abbreviation (even if there are multiple in a single inscription, on different line numbers), a user would want to be able to filter those results to only those on inscriptions from a certain date range, or a certain text type, or a combination of several facets.

I recall that a date slider on the search was mentioned before the start of the project. Is this associated with tei:msDesc/tei:history/tei:origin/tei:origDate? Specifically with @type textDate? What labels should be used for the slider?

Where static textual content is added as part of the EpiDoc XSLT transformation to HTML, this content should be wrapped in i18n:text elements with nicely specific @key values.

It needs to be checked whether common HTML renderers will be fine (ie, will ignore) these elements or not; if not, then for non-EFES EpiDoc XSLT users an additional step in the transformation, to strip out these i18n elements, may be necessary.

To allow the Epidoc example XSLT to work both as currently (standalone) and as part of EFES, refactor the HTML edition structure templates to have the content sections (CSS/JS decalarations, inscription text, title) in named templates. EFES has its own templating system and so needs to be able to access those parts separately from the surrounding HTML.

Desideratum: Subfacets would be extremely appreciated.

Codebases including:

• RIB
• EAGLE
• USEP
• IGCyr
• Telamon?
• Edition Visualisation Tool

EpiDoc XSLT does not provide any transformation of tei:graphic into html:img. This needs to be added so that images can be displayed in EFES.

On the EpiDoc XSLT side, the transformations need to produce HTML output for the tei:graphic elements within tei:facsimile, incorporating a new parameter specifying the URL prefix for generating html:img/@src URLs.

Each tei:graphic will be transformed into an html:a linking to the full image and an html:img referencing a thumbnail image. That non-EFES EpiDoc users will have to generate such thumbnails themselves is not considered a problem.

On the EFES side the changes are:

• Passing in a suitable URL prefix (to match the existing image pipelines; ie, "/images/").
• Creating map:match sections to handle the generation of thumbnail images.

Support for using an image server will not be part of this work, except inasmuch as appropriate URLs might be generated by changing the supplied URL prefix. More significant changes to the URLs would require customisation of the EpiDoc XSLT.

This may involve adding the CSS as a new <link> to the base.xsl file, perhaps with an <xsl:if> saying only include this for /sample/ and /corpus/ pages, or there may be some more subtle way to include contextual css in kiln. Ask Miguel (or better, issue a "support request" through the Kiln tracker) if in doubt.

Another desideratum we received was the option to download the results of an index (filtered or otherwise) or search in a tabular data format, CSV/JSON or similar. So a user could download the search results with columns for search term, result/context, inscription id, internal reference, etc., and load into their own database or data analysis tool.

Automatically generated bibliographic references don't seem to work.

Add content from tei:w/@lemma and dereferenced tei:name/@nymRef to the Solr index and allow that to be searched over.

Copy the basic faceted browse features from IOSPE, and think about the integration of this with the indices (see #11) and the issue of authority lists (internal, external, custom, etc.)

Create a list of stakeholders, especially those from non-Greco-Roman epigraphic traditions, and put PY in contact to start drawing up longer list of desiderata.

Troubles with visualisation (http://localhost....) randomly changing after each harvesting, apparently there is no ratio in this behaviour.

When language switch code is implement in a menu item, the XSLT in webapps/kiln/stylesheets/menu/normalize-menu replaces the language code in the URL, but if the current URL is the home page (i.e. ends with /{lang}/) the final slash is missing from the href, and so the page linked to throws an error.

Partial lack of alphabetical order: we can get only one language in alphabetical order at a time, that is, the language of the xml ids in Alists; in addition, in Alist for which we choose numbers as IDs, the order of the entries is that of the numbers themselves (i.e. id=001 will be the first, id=002 the second, etc.).