aso2101 / satavahana-inscriptions Goto Github PK

After the upgrade to eXist 3, the search function returns to following error, regardless of which filter (Metadata/Text/Translation) is chosen. It looks like it's a problem with the new KWIC library.

err:XPTY0004 xs:string(
   ) is not a sub-type of text() [at line 72, column 23, source: jar:file:/home/andrew/applications/eXistDB3/exist.jar!/org/exist/xquery/lib/kwic.xql]
In function:
	kwic:callback(function?, text(), xs:string) [109:38:jar:file:/home/andrew/applications/eXistDB3/exist.jar!/org/exist/xquery/lib/kwic.xql]
	kwic:truncate-previous(node(), node()?, item()*, xs:integer, xs:integer, function?) [107:25:jar:file:/home/andrew/applications/eXistDB3/exist.jar!/org/exist/xquery/lib/kwic.xql]
	kwic:truncate-previous(node(), node()?, item()*, xs:integer, xs:integer, function?) [244:27:jar:file:/home/andrew/applications/eXistDB3/exist.jar!/org/exist/xquery/lib/kwic.xql]
	kwic:get-summary(node(), element(), element()?, function?) [335:17:jar:file:/home/andrew/applications/eXistDB3/exist.jar!/org/exist/xquery/lib/kwic.xql]
	kwic:summarize(element(), element()?, function?) [898:18:jar:file:/home/andrew/applications/eXistDB3/exist.jar!/org/exist/xquery/lib/kwic.xql]
	app:show-hits(node()*, map, xs:integer, xs:integer) [221:18:/db/apps/SAI/modules/app.xql]
	templates:call-with-args(function, function*, element(), map) [208:13:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process-output(element(), map, item()*, element()) [205:9:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:call-by-introspection(element(), map, map, function) [187:28:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:call(item(), element(), map) [135:36:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [277:13:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process-output(element(), map, item()*) [270:9:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process-output(element(), map, item()*, element()) [205:9:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:call-by-introspection(element(), map, map, function) [187:28:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:call(item(), element(), map) [143:37:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [146:81:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [462:17:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process-output(element(), map, item()*) [270:9:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process-output(element(), map, item()*, element()) [205:9:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:call-by-introspection(element(), map, map, function) [187:28:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:call(item(), element(), map) [135:36:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [131:51:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:process(node()*, map) [88:9:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]
	templates:apply(node()+, function, map?, map?) [43:5:/home/andrew/applications/eXistDB3/webapp/WEB-INF/data/expathrepo/shared-0.4.0/content/templates.xql]

• add a "staff" page that will list contributors editors etc.
• add a page (like view.html) for each contributor
• link to that page from <persName> elements that gave a key starting with staff:

Remove depreciated code in app.xql. Some of the code has been made redundant by the switch to teiPublisher. Some functions should be retained for possible future use.

app:map is invoked elsewhere on the site, and it's nicer, because it pulls dynamic data from the model and uses a separate function to serialize it into geojson. But there seems to a problem with simply replacing app:inscription-map with app:map in view.html: the map doesn't appear (and view.html still has the annoying paging functions from TEIPublisher that are triggered when the map is expanded or collapsed).

@wsalesky is there a way to sort the inscriptions on browse.html so that we have (e.g.) 9, 10, 11 rather than 1, 10, 11, 12, 13, 2, etc.? (See the order of inscriptions at http://localhost:8080/exist/apps/SAI/browse.html?fq=;fq-Place:pl:Bh%C4%81j%C4%81)

(the same thing happens with Pauni, where there are just two places within places)

It appears that the search is no longer separating the text from the metadata and the translation when one of these filters is selected. See:

http://37.252.124.228:8080/exist/apps/SAI/search.html?query=*ye*&filter=text

which returns results from the text, metadata, and translation.

Also the text in the drop-down menu is white, and invisible against the white background unless moused over; this should be changed to black.

• <app> (uses @source rather than @wit)
• <choice>

Use ODD? (see processing model at https://github.com/TEIC/TEI-Simple)

Right now the database indexes everything and the search function (app:query in app.xql) returns hits from the following TEI elements: p, head, lg, trailer, l, quote, text, unclear, supplied.

I think it would be best to have a search interface with a couple of sets of options:

• Search metadata (see below)
• Search text (see below)
• Search translation (TEI/text/body/div[@type="translation"])

For searching metadata, there are potentially four kinds of matches: the TEI header of inscription files (I would also return matches from text/body/div[@type="bibliography"] and text/body/div[@type="commentary"]); person description files; place description files; and bibliography description files. It would be nice to be able to filter these matches. Thus searching for "Sarma" will return all of the inscription documents that refer to Sarma in their individual bibliographies, plus the corresponding entry in the project-wide bibliography (and any people or places that happen to mention this name).

For searching the text, I think the default behavior should be to search for the "correct" text and throw out anything that would appear in a critical apparatus (i.e., only return matches for <lem> and <sic>, and throw out <corr> and <rdg>). But we'll have to make some other adjustments: <lb break="no"> elements that occur (by definition) in the middle of the world shouldn't cause its two halves to be indexed separately; I know that similar indexing problems occur with "unclear" or "supplied" letters (these should just be indexed as part of the word: deyadha?ma matches deyadhaṃma in Sai1, but not deyadha<unclear>ṃ</unclear>ma in Sai2).

Wildcards should already work with the Lucene index but I haven't tested them thoroughly. Is there a way to make them work at the beginning of a string?

Here is /db/system/config/db/apps/SAI/collection.xconf:

<collection xmlns="http://exist-db.org/collection-config/1.0">
    <index xmlns:xs="http://www.w3.org/2001/XMLSchema">
        <fulltext default="none" attributes="false"/>
    </index>
</collection>

Some of my Sanskritist colleagues are really impressed by the 'TEI Export' feature on syriaca.org—not because it's useful to them, but because it demonstrates that the data is open and accessible and whatnot.

Would it be possible to put a TEI Export button (like the one on the right of the title row on, e.g. http://syriaca.org/person/321) on view.html? I imagine it would just output the document that is loaded on app:load. It could be called from app:navigation-title, I suppose.

1. rewrite person.html
2. add ODD behaviours for person.html (using the elements described here.
3. write special functions for person.html in ext-html.xql

I think that when people search for terms they will want to ignore all of the text-critical markup. Thus for example K6 has the line ghara<unclear>sa</unclear> in div[@type='edition'], which is rendered as ghara(sa) by the ODD. But if one searches for gharasa, there are no results. In order to find the relevant passage one has to search for ghara*.

The following elements should be "ignored" (i.e., their text content should be combined with the immediately preceding or immediately succeeding text node, up to the space) for the sake of searching:

• unclear: e.g., ghara<unclear>sa</unclear> should be indexed as gharasa (K6)
• supplied: e.g., ga<supplied reason="lost">ha</supplied>patino should be indexed as gahapatino (Ku21)
• add: e.g., <add place="below">gha</add>riniya should be indexed as ghariniya (no examples in my corpus yet)
• del: e.g., <del>gha</del>ghariniya should be indexed as ghariniya (actually I think it is indexed this way anyway, so nothing needs to be done here).

These should also be combined, since these elements often occur together (e.g., <supplied reason="lost">bha</supplied><unclear>yata</unclear> should be indexed as bhayata).

If possible, the same kind of behavior should be applied to those elements even when they contain spaces (although this should happen much less frequently and I can't find any examples right now):

• de<unclear>ya dha</unclear>ma should be indexed as deya and dhama

For the elements <choice> and <app>, which occur in the corpus relatively often, I am a bit more uncertain. I plan on moving 'inline' apparatus elements to an external apparatus for all of the inscriptions, so theoretically <app> should not match anything in div[@type='edition']. But I think that when one includes the apparatus in the search (I will post a separate issue for this) then all of the elements inside <app> should be considered potential hits (i.e., <lem>, <rdg>, and <note>), although the behaviour of the inline elements (<unclear> and <supplied>) should be the same as noted above.

For the element <gap>, I am not sure what to do. Right now, I think that <gap> just screws up any searches, in the sense that pu<gap/>ṇa will probably not match the terms pu*, pu*ṇa, puteṇa (which is probably what this stands for), etc. Would be be possible for <gap> elements to be treated as quasi-wildcards, so that a search term like "puteṇa" would match pu<gap/>ṇa?

Possibly @arlogriffiths will have something more to add.

TEI Publisher maps the right and left keyboard arrows to "forward" and "back" within an XML document. But since our documents don't have pages, I don't see much of a use for this.

I believe we can also get rid of the "single page" button on the top bar (I'm not even sure what this is supposed to do).

see http://localhost:8080/exist/apps/SAI/person/Sa-Somaghosanik%C4%81, where "81 (white)" is added from msIdentifier/altIdentifier

see about, credits, editorial conventions at http://hisoma.huma-num.fr/exist/apps/EIAD/works/

since we are using EM's ODD, the conventions should be the same, so we can just link there.

RE: #54

@wsalesky I think that in order for the "Show on map" button to appear, the @xml:id of a <place> (which provides the heading in the list) needs to be identical to the label that the place is given on the map, which is derived from <placeName> (specifically the first occurrence of an "ancient" placeName, and otherwise the modern placeName). This has meant that some places (like Bhaja and Bedse) have lost their "show on map" button when I've added additional <placeName> elements.

I now think that it's better to leave as an "editorial decision" how particular places will be referred to, i.e., whether to use ancient or modern names. For <place> elements that already have full TEI records the preferred name of the place will be in the <title> element; otherwise, it will be the first occurrence of <placeName> (which will match the title when it is added). Could you change smap:create-data and app:browse-hits to use this information for the name of the place, and check that the "Show on map" functionality in browse.html is restored?

Following our conversation this morning, view.html should produce the following sections in #content-container:

1. Metadata (<teiHeader>)
2. Map (probably a separate function, since the map data will come from the TEI document itself in the case of inscriptions and places, but not in the case of people).
3. Facsimiles (<facsimile>) — only for inscriptions (but maybe places will have images as well)
4. Edition (<div type="edition">, with tabs as in the EIAD website) — only for inscriptions
5. Translation (<div type="translation">) — only for inscriptions
6. Commentary (<div type="commentary">) — only for inscriptions; right now this mostly contains prefatory matter, and it might make sense to put it above the edition.
7. Bibliography (<div type="bibliography">)
8. Place information (<place>) — only for places
9. Person information (<person>) — only for persons
10. Relations between people (probably a separate function: see app:inscriptions-related-to-person-revised) — only for persons
11. Bibliography item (<biblStruct>) — only for bibliography items
12. Records containing this bibliography item (a separate function) — only for bibliography items

These sections ought to be collapsible, eventually (like the map is now)

The placeNames and personNames in the edition and translation divisions are not appearing, probably because the EIAD-PYU ODD that we're using doesn't use <placeName> and <persName> in these contexts.

• Add a customization to sai-customizations.odd for placeName and persName in this context (should be able to select them with predicate=ancestor::div[@type='edition'] or something similar)
• Check Emmanuelle's functions (ext-html.xql) for a suitable behavior that will convert the text of the name to a link that points at a URL derived from the @key value (as in the old system).

• results from <div type="translation"> are given in the facet list as "div"; they should say "translation"
• i think results from <div type="edition"> should also say "text" (or "inscription text"?) rather than "inscription"

Does the reference to model("persons") in app:dynamic-map-data suggest that this will be called on people.html? (By the way, It seems that people.html gets the data from model("hits"), set by app:browse-get-persons, so I wonder whether the references to model("persons") could be eliminated here.) I do think it makes sense to have the same dynamically-generated map that's on browse.html and places.html. However, I think there should be two (non-exclusive) options on this page for putting places onto the map:

• Places where the matching people (model("hits")) are attested (i.e., a <placeName> that occurs in <origPlace> in the inscription attached to <person> in the model)
• Places where the matching people are said to reside (i.e., a <placeName> that occurs in the <person> element, specifically <residence>).

I would have both of them enabled by default.

I've just changed browse-person-facet-def (affcb14) to reflect this distinction between place of attestation and place of residence.

I also notice that model("hits") has a <person> entry that contains both the content of <person> (in the data collection) and a list of inscriptions where that person's name occurs. Will this be a problem if and when I replace the XML fragments in contextual/People with complete TEI documents? (It doesn't seem like it, since model("hits") right now only graps <person>, and not the entire document.)

I have been scratching my head about this one, but maybe it will be clearer to you @wsalesky:

On the most recent version (0497bef), which I haven't put on the server, it seems that none of the ODD behaviours are being applied at all.

On the version that is currently installed on the server, some documents like SaC14 seem to work fine (i.e., they apply the ODD), whereas others, like SaC13 , return the following error:

exerr:ERROR XPTY0004: The actual cardinality for parameter 1 does not match the cardinality declared in the function's signature: root($arg as node()?) node()?. Expected cardinality: zero or one, got 2. [at line 1315, column 69, source: /db/apps/SAI/modules/app.xql]

I'm not sure what's causing the discrepancy in behavior. Anyway, we want all documents to work like SaC14 on the server.

The list of search results doesn't use the ODD processing, and so all of the behaviours defined by the ODD (like brackets around unclear or supplied text, or replacing <ptr> elements with the <title> of the corresponding record) are not used. The result is that the search results don't look as one would expect them to look (try searching "Based on" in "Commentary": since this is always followed by a <ptr> element, it is always blank in the search results).

Is there a way to process the KWIC results with the ODD? (I imagine that this is non-trivial.) Otherwise we can think of other solutions (like writings special xquery transforms for the KWIC results).

bibliography.html still uses app:list-bibitems and app:bibitems, which don't do anything except output the unprocessed content of <biblStruct>. This should be replaced with TEI Publisher functionality.

Note that Emmanuelle's site uses a single TEI document as a bibliography (so the bibliography is just view.html with the bibliography file passed to it), whereas we have all of the bibliographic records in separate files. But I think that just means we keep bibliography.html and populate the model with <biblStruct> entries from $config:remote-context-root.

I should also admit that I don't exactly understand the parameters pm-config functions: what do I need to pass to them? (It seems like a <biblStruct> node taken from the model won't do...)

on browse pages (from #42)

After loading the package in eXist 3, the filter for "language" on the left side of the browse page (browse.html) seems to show all values instead of unique values.

Since my practice is to prefix an abbreviated place name to the xml:ids for people, I think it's better for app:browse-get-persons to order the hits by the "real" name (the first persName in the record), rather than by the xml:id (so the person with the xml:id Hi-Rakṣita is sorted under R rather than H). However, when I try setting $name to $i//tei:persName[1]/text(), we end up with multiple entries having the same value for $name, which doesn't work. Maybe you have an easy solution @wsalesky?

I think the current search function must interpret any document that has a TEI root as an inscription:

where the first is one of the few person entries that I've stored as a full TEI document rather than a fragment with the root <person>.

How can we distinguish inscriptions from people/places/bibliography items when the latter will (eventually) be stored as TEI documents as well?

@wsalesky my plan was to augment the current behavior on person.html (app:person-relations) with a visualization using d3.js, as we've discussed. In the vast majority of cases, there will be a relation with at most one other person, so it seems most straighforward to have two labelled nodes, with a labelled line connecting them. But in a few cases there will be more relations.

As far as I can remember, the most elaborate relations are found in the Kuḍā data (contextuals/Persons/Kuḍā/Ku-000-relations.xml). I have not yet converted the person records for Kuḍā into full TEI documents, but that shouldn't matter right now. The Kuḍā data should give you an idea of how complex the relations will get. The main relations are parent/child, spouse, sibling, and teacher/student. There are a few more that I will add when we import another set of inscriptions soon...

I know it's possible to do this with webhooks but I've never used them before.

Add div[@type='apparatus'] to the list of sections that can be searched under "Inscriptions" in the drop-down menu. (This is a relatively new addition and only a few records have an external apparatus but once the feature is there I can test it using those records.)

The bibliographic information in bibl.html right now uses the ODD behaviours that were written for other contexts (e.g., bibliography.html). See (e.g.) http://localhost:8080/exist/apps/SAI/bibliography/MNOVH2014.

The title (produced by app:navigation-title) should be the "short title" of the record, i.e., title[@type='short']. Right now it evidently uses title[1].

Then what follows should be a formatted citation that looks like (e.g.): Nakanishi, Maiko & von Hinüber, Oskar. Kanaganahalli Inscriptions (Annual Report of the International Research Institute for Advanced Buddhology at Soka University for the Year 2013, vol. XVII, Supplement) Tokyo: The International Research Institute for Advanced Buddhology, Soka University, 2014. The behaviours for each of the elements in <biblStruct> are defined in the ODD (hisoma-epigraphy.odd); they can be overridden by copying the elementSpec to the custom ODD (sai-customizations.odd) and changing whatever is necessary.

Then should follow the "Cited in the following records" with a list of inscriptions. I would actually change the xquery code in app:related-inscriptions so that it appears in a "collapsible section" (see line 529 in modules/ext-html.xql).

Then, finally, there should be another collapsible section for the "metadata," which is basically information from the header about who created the bibliographic record (i.e., the <editor> and <resp> from the titleStmt). But if you just leave this section blank I will fill it in later.

We've run into a few discrepancies between browsers:

The search bar at the top right now BREAKS on Chrome but is INLINE in Chromium and Safari.

<form action="/exist/apps/SAI/search.html" class="navbar-form navbar-right">
  <div class="input-group input-group-sm" style="width:350px;">
    <input type="search" class="form-control" name="query" style="margin-left:19px"/>
    <select class="form-control" name="filter">
      <option value="''"> - Search Filter - </option>
      <option value="metadata"> Metadata </option>
      <option value="text"> Text </option>
      <option value="translation"> Translation </option>
    </select>
    <span class="input-group-btn">
      <button id="f-btn-search" type="submit" class="btn btn-primary">
        <span class="glyphicon glyphicon-search"/>
      </button>
    </span>
  </div>
</form>

We want an input-group, but there are some conflicts with navbar-form regarding the width of the elements that made me have to specify the width explicitly (and add 19px of margin to get the elements to actually run together).

I noticed after searching for ghara* and getting a few results, I tried to search for it again and got zero results. It turns out that I got results when searching for "Inscription" but not for "Text" (although the results occurred in div[@type='edition']. A few other examples:

• dham* gives 53 results for "Inscription," but zero results for "Text," although most of the results are contained in div[@type='edition']
• likewise, deya* gives 112 results for "Inscription," most of which lie in div[@type='edition'], but only one result for "Text"

We have a working place.html but the ODD doesn't do anything with <place>s at the moment. Write some behaviours to put in the ODD.

@wsalesky I've assigned myself but feel free to take a stab at this---Beḍsā.xml is a good example. Actually, app:related-inscriptions is called but doesn't seem to do anything here. We should have a list of all the inscriptions at each site (which we already have in browse.html).

Currently all persons in the database are displayed in a list (persons.html) with associated inscriptions and a link to an individual entry for each person (person.html).

I would like to change this to something like browse.html, i.e., a dynamically sorted list with filters. For we can dispense with the "associated inscriptions" data and have a table with the following columns:

Name (No.) | Places | Identifiers

Where "Name" will be a link to the individual entry, "No." is the total number of inscriptions in which that person's name appears, and "Places" is a comma-separated list of the places where that person's name appears. "Identifiers" will be a comma-separated list of social/political identifiers, but I am still figuring out exactly how to encode these and what the expath expressions will be. But they'll include the <state> elements in the <person> entry. I'll update this issue when I've settled on the identifiers (hopefully over the weekend).

I think it will be useful to be able to filter this list on the basis of place and identifier. The "place" filter will work exactly as on browse.html.

Right now the inscriptions are listed on three pages (by_place.html, by_date.html, and by_ruler.html), where they are arranged according to different XQuery routines by their place, their date, and the ruler (if any) mentioned in them. The map only appears on the "by place" page.

All three should be replaced by a "Browse inscriptions" page that will populate and sort the list of inscriptions based on user-selected criteria. The default behavior will be to list all inscriptions in the database and sort them by place (much as on the "by_place" page now). But the following criteria should appear in a horizontal bar at the top of the page:

PLACE | TYPE | DATE | LANGUAGE

Each of these should come with a drop-down list of preselected options which the user can "unselect" in order to filter out certain inscriptions:

• PLACE: Maharashtra, Karnataka, Andhra Pradesh, Madhya Pradesh, Sri Lanka
• TYPE: Label, Donation, Memorial
• DATE: 2nd c. BCE, 1st c. BCE, 1st c. CE, 2nd c. CE, 3rd c. CE
• LANGUAGE: Middle Indic, Sanskrit, Unknown

I haven't coded all of the inscriptions for all of these criteria yet: most of them are in the TEI header of the individual inscription files, but the "place" criteria will involve two steps, first looking up which sites are in the selected places (in the listPlace data), and then fetching the inscriptions that belong to those sites. NOTE: Get the elements/XPath for all of these criteria and how it should appear on the page.

It would also be nice if the individual categories could be rearranged, e.g., the default behavior will be to sort on place first, then type, then date, then language, but the user can drag language to the first position and hence sort on language first, etc.

Finally, the current code for the map just throws all of the sites in the database on a map. But it would, again, be better to do this dynamically, based on user-selected criteria (e.g., all of the inscriptions that are loaded in the "browse" page are put into the map, and not ones that are filtered out).

@wsalesky you don't happen to know of anything that will take relational data (like the TEI <relation> element or some JSON serialization thereof) and turn it into a nice-looking family tree? I know d3 can do it, and I am looking into https://github.com/ErikGartner/dTree, https://github.com/mrblueblue/d3-react-family-tree, and https://github.com/Yakubovich/descendant_tree, but maybe you have some ideas. In any case we would probably need to convert the TEI <relation>s to JSON.

Just like what I suggested in #20 for people.html, I think the map on places.html should have two options: to show places where inscriptions are actually found (i.e., all <placeName>s that occur in <origPlace>) and places that are mentioned in the inscriptions (<placeName>s in <div type="edition">). Of course not all of the latter are identified, so they won't have tei:geo data, but it's still worth making the distinction, I think.

I notice that browse.html currently calls one important function (app:browse-get-inscriptions), which puts all of the documents that match the facets into the model in a variable hits. A couple of questions about how the code in app.xql works with this data (since I'm beginning to clean up app.xql):

• app:dynamic-map-data begins looking for things in hits that have teo:geo data, but since inscriptions don't have geo:geo data, I'm not sure what this is for... (and it doesn't seem to hurt if I delete it)
• I have changed app:dynamic-map-data so that if the model has "hits" (i.e., inscriptions) rather than "places" or "persons" it will only populate the map with places that are the <origPlace> of inscriptions (see 4e9563b — previously it was also putting places on the map that were merely mentioned in each inscription)
• How is model("data") used?