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

Hierarchical search and browse #971

Open wsalesky opened 7 years ago

wsalesky commented 7 years ago

See related issues: https://github.com/srophe/srophe-app-data/issues/463 https://github.com/srophe/srophe-app-data/issues/710

davidamichelson commented 7 years ago

Search looks good.

For browse and search, in the summary view for "composite" URI records, include a sentence with a count like this:

This literary tradition comprises [count] texts with separate URIs.

davidamichelson commented 7 years ago

For places here is a draft:

This composite place includes [count] more narrowly conceived places.

wsalesky commented 7 years ago

Will there be/can there be more then one value in @passive or is there always only one 'parent'?

<relation active="http://syriaca.org/work/410" ref="skos:broadMatch" passive="http://syriaca.org/work/2057"/> Or (made up!):

<relation active="http://syriaca.org/work/410" ref="skos:broadMatch" passive="http://syriaca.org/work/2057 http://syriaca.org/work/20588"/> This dramatically effects query speed, as multiple uris in a string need to be parsed out before they can be matched.

nathangibson commented 7 years ago

Hmm, @davidamichelson and I haven't specifically discussed that. Usually there would only be one, but I can conceive of a work that might belong to multiple literary traditions, such as a saint's life that blends material from multiple other lives.

Is this a we-can-cross-that-bridge-when-we-come-to-it sort of situation, or is it best to future-proof it now? And does it make a difference in query speed if additional parents were each in their own relation elements rather than as multiple passive values?

wsalesky commented 7 years ago

It would be fine if they each had their own element, it is the text parsing that eats up processing time. Again, rdf may also solve this for us.

Sent from my iPhone

On Mar 22, 2017, at 2:30 PM, nathangibson notifications@github.com wrote:

Hmm, @davidamichelson and I haven't specifically discussed that. Usually there would only be one, but I can conceive of a work that might belong to multiple literary traditions, such as a saint's life that blends material from multiple other lives.

Is this a we-can-cross-that-bridge-when-we-come-to-it sort of situation, or is it best to future-proof it now? And does it make a difference in query speed if additional parents were each in their own relation elements rather than as multiple passive values?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

nathangibson commented 7 years ago

@davidamichelson What would you think about us requiring that if a URI belongs to multiple composite URIs, that we put in multiple <relation> elements (instead of simply multiple @passive values)? We might even be able to write such a rule into the ODD, though it'd be a little complicated.

dlschwartz commented 7 years ago

@nathangibson You can easily allow only one value for the passive attribute and the encoder would then just have to know that she is supposed to add another relation element.

nathangibson commented 7 years ago

Good to know, thanks! Can we restrict to only relations that have a ref=“skos:broadMatch”?

dlschwartz commented 7 years ago

Yes, but you would have to use schematron in your ODD. You would apply a text that would only allow one value for the passive attribute if there is also a ref element with a value of skos:broadMatch. Multiple values on the passive attribute would render an error in Oxygen. I can help or you can check out Syd Bauman's slides, etc. for the course I took at DHSI last summer (toward the bottom): [http://www.wwp.northeastern.edu/outreach/resources.html]

wsalesky commented 7 years ago

Let's hold off on that until after I test RDF, which may end up being faster.

Sent from my iPhone

On Mar 23, 2017, at 2:28 PM, Daniel Schwartz notifications@github.com wrote:

Yes, but you would have to use schematron in your ODD. You would apply a text that would only allow one value for the passive attribute if there is also a ref element with a value of skos:broadMatch. Multiple values on the passive attribute would render an error in Oxygen. I can help or you can check out Syd Bauman's slides, etc. for the course I took at DHSI last summer (toward the bottom): [http://www.wwp.northeastern.edu/outreach/resources.html]

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or mute the thread.

davidamichelson commented 7 years ago

Here is a sentence for places:

This composite place URI combines [count] specific places.

davidamichelson commented 7 years ago

I think we will want different handling for this in Places and Works. For places we will want all the children to show in browse list and also independently but this will be fine because there are not many of the.

wsalesky commented 7 years ago

This is causing some issues and will need to be reworked. Expect to see some odd search results over the next week as I sort it out.