search

srophe / srophe-eXist-app

DEPRECATED eXist code for Syriaca.org: The Syriac Reference Portal
GNU General Public License v3.0
10 stars 11 forks source link

Dynamically pull related places from eXist database #66

Open tacarlson opened 10 years ago

tacarlson commented 10 years ago

The "Related Places" section of the .html page would ideally be populated by searching the eXist database for <relation> elements which point to the URI of the currently displayed place. This will allow any semantic relation to be curated in a single place. When that is implemented, we may need to strip out redundant "shares-name-with" relation elements.

davidamichelson commented 10 years ago

Auto generate shares a name relationships from XML index.

wsalesky commented 10 years ago

Can I get some clarification on this? Isn't this what we are already doing with related places? Or do you have something different in mind? Thanks!

tacarlson commented 10 years ago

As I understand it, the HTML view creates a "Related Places" section only if this record has a <relation> element, and queries the eXist database to supply the names of other places in the <relation> element. If this record does not have a <relation> element, then it has no "Related Places" section, even if it is related to another place in that other place's record. So to make a bilateral relation appear on the record of both places, it is necessary to curate it in two places (and more for multi-lateral relations).

For example, Edessa (place/78) has a relation to Osrhoene (place/145), which shows up on the Edessa page but not on the Osrhoene page.

I'm wondering whether, in generating the HTML for Osrhoene, it's possible to query the eXist database for <relation> elements cite "http://syriaca.org/place/145" and group them under a "Related Places" section. This would allow any relation to be curated as a <relation> element in only one record. Does that make sense?

If a TEI record has <relation> elements, it will be necessary to represent the relations from this TEI record as well as any other relationships drawn in from the eXist database.

I think there are two implications of this move:

  1. The format of the prose will need to change, and indeed will need to be supplied in a <desc> child of the <relation>, because it will not be possible to generate the prose of the relationship from any possible name of the relationship. In an ideal world, the relation prose would use the English headword and when the process looks up the name of each listed URI, it would turn the occurrences of that name in the desc into links to that place. But that may be too crazy on the string-processing, so it should be possible to have a bullet point of the form: <desc> " (" <list other place's names as links to their URIs> ")"
  2. If it works to process both "internal" <relation> elements from this record and "external" <relation> elements from the database, we're immediately going to have a bunch of superfluous "share-a-name" relationships which will need to be pared down. The processing of this element need not change much if it just pulls in the whole <relation> element from whichever place record has it.

Let me know what here is still unclear. Thanks!

wsalesky commented 10 years ago

@tacarlson Thanks! That helps. I will write something up and see what the results look like. Then we can go from there.

wsalesky commented 8 years ago

Done

davidamichelson commented 8 years ago

Okay, misunderstood, this is not yet done. But this will be handled by RDF serialization instead of the XML.