Replies: 41 comments
-
|
thanks, that is very useful. |
Beta Was this translation helpful? Give feedback.
-
|
Regarding issues with the "less-advanced" searches, especially relating to the indexing and ranking of results, is it worth considering an alternative search engine to eXistDB's own functions? I'm thinking of options like ElasticSearch or Algolia, professional search tools that have more sophisticated methods of indexing and ranking data. Perhaps our data is subject to frequent updates and reindexing, but I'm not sure it's worth inventing our own solutions when there are existing options with years of development and refinement behind them. Just an idea. |
Beta Was this translation helpful? Give feedback.
-
|
Feature request for XPath search: every time you run an XPath search, the input field is cleared. It would be nice if the query remained in the input field so you could modify it or adjust it more easily (rather than having to retype it). |
Beta Was this translation helpful? Give feedback.
-
|
@smaugustine your idea is to change DB and indexing... well, BM will need to change developer for that (@abausi), I am definitely not going to develop newly the entire research environment just to use fancier technical solutions and waste time in development which could be invested otherwise for more functionality, more data. Also exist-db has years of development and refinement, as well as a flexibility in data handling hardly comparable to any other resource which is the reason we used it to begin with, and we are not alone, besides being tightly related to the TEI community. I also think it would not bring any actual benefit over the Lucene indexes we already have, compared to a process of continuous improvement and optimization which we carry out on a daily basis. You are of course free to develop your own application using those tools over the BM data in any of the provided formats. also, please make a new issue for a new issue. |
Beta Was this translation helpful? Give feedback.
-
|
@PietroLiuzzo To be clear, I wasn't my intention to suggest so drastic a change. Database and search are two separate things. Just as an example to clarify, we see that these are separate offerings within single companies: Amazon DynamoDB and Amazon ElasticSearch, MongoDB and Atlas Search. I would never suggest that we use anything other than eXistDB for our database, and I think we have a great database, honestly. I was simply inquiring about options for searching. Beta Masaheft already has a data API, feeding the data into a new index wouldn't require so much change. If it's impractical and better that we continue to work with our existing indexes, okay. It was just an open suggestion. |
Beta Was this translation helpful? Give feedback.
-
|
we clearly have very different Weltanschauungen. I simply do not think Elastic Search or similar would help solve this issue. if you can practically demonstrate it would in some respect, I am happy to consider that and go on with any change which will bring measurable practical improvement. I will also ask on the exist db channels if there are others using elastic search in addition to these indexes to gather more intelligence. The indexes defined in exist can be improved in number and quality, the queries on them as well. feeding data to a new index, changing queries to look at that index where appropriate, maintain additional indexes in the flow so they are in sync with the others, etc. are much of a change IMHO. |
Beta Was this translation helpful? Give feedback.
-
|
Dear all, I apologize for not using the correct technical terms, as I do not know/understand them. I simply think, very plainly phrased, that BM is a search engine, with an amazing backbone of information. But if this information is not accessible it is not worth much.* The accessibility should be the focus here, and while it would be wonderful for all users to get acquainted with the IT behind BM, we cannot expect the to have time or interest in this. The average user has probably very different interests. He uses BM to find either a catalogue, or a certain manuscript, an art theme, or wants to compare incipit of Miracles or so. Are there ways to see what people most frequently search for? I would take this as a start and create a quick search, as Zhenia suggested. If they do not find what they are looking for they still have the advanced search and can explore on their own. But I think this would ease the access to the most important feature of the database that people are interested in. My understanding of BM might be wrong, but I thought it is a tool for people to use, said usage should be easy and as barrier-free as possible, otherwise they will stop at one point. The main advantage of BM is making information available to the wider public that was otherwise contained in books that have a much more limited availability.** Think about all Ethiopian colleagues - how many catalogues are accessible in Ethiopian libraries? Few! To this (and other issues) BM is the remedy. *do you know this joke? "Where do you best hide a dead body? On the second page of Google search results." |
Beta Was this translation helpful? Give feedback.
-
|
I was CC by Sophia; I understand that this is again the output of the yesterday session (that I could not attend), which confirms that it was very useful. I support the idea that the resources must be as clearly understandable and as simply accessible as possible. Out of experience in every field, those who develop a system are not in the best situation to understand what is generally needed and which are the challenges, and in the end it is good that the focus of the developer remains on the quality of the data. This is a complex issue. In the end, however, the search for a more simply way of making resources accessible is extremely important and all voices claiming that more has to be done towards this direction must be heard. |
Beta Was this translation helpful? Give feedback.
-
|
I have done some experiment using only the currently available search field on the home page, so limited to that functionality. TL;DR summary: I am really struggling to understand why a one simple access point would be more complex than seven entries as in the example in the picture.
|
Beta Was this translation helpful? Give feedback.
-
could this be please unpacked? I do not understnd |
Beta Was this translation helpful? Give feedback.
-
there where? in the menu? please remember that last year, after a lot of discussion we opted for diminishing the load on a page, we are now going full speed in the opposite direction by loading with text and information parts of the app, like the navigation bar, which are always available. can we instead consider expanding the "explore" module? |
Beta Was this translation helpful? Give feedback.
-
|
as for the sparql endpoint editable, it is possible, not easy. this is the best example I know https://query.wikidata.org/ |
Beta Was this translation helpful? Give feedback.
-
Introduce on each search dedicated page. Would that really slow down the process so much if https://betamasaheft.eu/xpath where we have the text |
Beta Was this translation helpful? Give feedback.
-
|
ok, now I understand what you mean, not in the menu, in the page with the search. |
Beta Was this translation helpful? Give feedback.
-
Menu: SEARCH |
Beta Was this translation helpful? Give feedback.
-
because I may never get to the page in search results with any miracle of mary as an art theme from the general search. you know, we know, that it is encoded and can be searched for, but a John Doe from the outside does not and will possibly never find out.
I would disagree. The BM search is not at all the same from the GUI point of view. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if more people should be asked to contribute to the issue with their input or it would make it even more chaotic :-) |
Beta Was this translation helpful? Give feedback.
-
and your proposed solution is a dedicated search on the home page which says "art themes"? and what would you expect that to search in? which kind of results would you expect? only hits in the art themes? manuscripts containing that art theme?
please point out how. |
Beta Was this translation helpful? Give feedback.
-
his conversation is public as any other here, anyone can contribute. |
Beta Was this translation helpful? Give feedback.
-
I'm just going to step back and say that I am not being aggressive or critical in any way, nor would it ever be my intention. People have asked about ways to help simplify the more advanced types of searches and I'm simply trying to present ideas to bridge things between the very technically advanced side of things and average everyday people just trying to find the data they're looking for. So far, I only have presented very open suggestions, "What about?", "Would it be helpful if?". If it's a dumb idea or something we already have or something not worth implementing, then that's a show of my own ignorance. I don't see how it becomes some sort criticism or attack. |
Beta Was this translation helpful? Give feedback.
-
|
so please @SusanneHummel @antobrita @DariaElagina @DenisNosnitsin1970 @MarcinKrawczuk @Ralph-Lee-UK if you have some ideas as to how the access to search options can be improved (if it should be improved - maybe it is perfect as it is) - use this issue to share, thank you! |
Beta Was this translation helpful? Give feedback.
-
|
sorry @smaugustine the entire conversation, not your suggestions, which are more constructive than others indeed in many respects, is addressed to me instead of being a common reflection. I did not intend that as a line for you specifically, I am sorry if it came through like this, it was more in reply of what @eu-genia wrote. |
Beta Was this translation helpful? Give feedback.
-
I was not criticizing at all. I am awfully sorry if anything came across as a criticism. I will step back as well, AFAIK we can leave all as it is. |
Beta Was this translation helpful? Give feedback.
-
only because I had already started this reply. |
Beta Was this translation helpful? Give feedback.
-
|
please @eu-genia it would be useful for the clarity of this issue not to leave the many questions opened by your points un-answered. if you could spend few minute replying to each I am sure many more precise requirements would come up so that they can be listed, split into separate issue and carried out. |
Beta Was this translation helpful? Give feedback.
-
|
I have updated the top message with my first input after the meeting, for the rest I am at a loss as I have the impression nothing is possible or sensible, so leave it to the others. While we are at it - I was also wondering - I know again we have here something we designed "together" - but I now have the feeling that part of this is because some new users may not even understand that the main page is scrollable down. The arrow and the menu button are visible for me but do many use them? @SophiaD-M have you ever scrolled down to e.g. https://betamasaheft.eu/#furtherSearchOptions? Should there be a way to make the homepage content which is already there more visible? |
Beta Was this translation helpful? Give feedback.
-
|
@eu-genia please reply to the questions about the DomLib search above. |
Beta Was this translation helpful? Give feedback.
-
|
I did not in fact! That might be because I am using my laptop only? Look at this screenshot, the arrow pointing down is not even visible on my screen.
|
Beta Was this translation helpful? Give feedback.
-
|
It was obviously impossible for me to follow the discussion. I think
this is one of the cases when a discussion in person (on Zoom) is the
onyl way to progress. I remain with the impression that more mutual
understanding is needed and that there are real and genuine needs that
must be considered.
Il 08.12.2020 14:32, Pietro Liuzzo ha scritto:
…
@eu-genia <https://github.com/eu-genia> please reply to the questions
about the DomLib search above.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/BetaMasaheft/Documentation/issues/1597#issuecomment-740620889>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEYMY2HGUSTWORJUU4YITWTSTYTGRANCNFSM4UQJX7UQ>.
|
Beta Was this translation helpful? Give feedback.
-
I am sorry I probably cannot explain well what I meant. In a "traditional" very plain search of DomLib you do search from the very beginning in only one type of entity, you see which fields exist, you can search in any, or all, or any combination, with the GUI hinting as to whether you are looking for an exact or a partial match, all those things, in one click. In BM I have to go through a lot of filters (which would not give me the same results, as I have no option of free text search in separate fields) or do an XPath query which would but is not so straightforward for outsiders I understand that BM has much more complex data structure and has much more to offer so such "simplified" solutions are not possible but maybe there are ways to make it useable also to non-specialists. E.g. having pre-set sample searches for different types of entities that one can then modify could possibly help. But maybe others have better ideas as to what can make the VRE more transparent. |
Beta Was this translation helpful? Give feedback.
-
Following up on the discussion - some ideas to make the various Search options make more accessible to the larger audience
Have a separate menu point (can stay under Resources - or top level, but again the width may be an issue) for Search, where all Searches have sub-menu-points
Menu: SEARCH
Submenu 1: Simple search
Submenu 2: Facet search
Submenu 3: Advanced search
Submenu 4: X-Path query
Submenu 5: SPARQL query
Introduce in the search pages the definitions currently hidden under general Help (https://betamasaheft.eu/help.html) - i.e.
Reproduce the definitions on the specific search pages, e.g. the page https://betamasaheft.eu/xpath should have on top at least the text as present now
XPath search
All searches are XPath searches in an XML database like the one behind this website, but what you can ask in a XPath query is much more than any of the provided search interfaces can offer. So, if you know how to write your XPath, and know the source TEI (available for each file, by appending .xml to the identifier of the record) you will then be able to see your results listed.
Here you can avail yourself also of the structure of the file, the relative position of elements, and the nested elements, querying across the axes.
Examples:
person record which have at least some attribute for birth and death (can be when, notBefore, notAfter) elements and occupation type ruler'.
Manuscripts with an addition element typed Ownership Note followed by another one with type Supplication.
Provide more ready-to-go search examples of various types and various degree of granularity where the users can "simply" subsitute variables
(I am not sure whether it is possible to make the SPARQL search examples more "editable", or one can only do it in the address line such as "https://betamasaheft.eu/sparql?query=SELECT+%3Fms+%3Fperson%0D%0AWHERE+%7B%0D%0A++%3Fannotation+a+bm%3Adonor+%3B%0D%0A++++++++++++++oa%3AhasBody+%3Fperson+%3B%0D%0A++%09%09%09++oa%3AhasTarget+%3Fms+.%0D%0A++%3Fms+a+bm%3Amss+.%0D%0A++%3Fperson+foaf%3Agender+%27female%27+.%0D%0A%7D+")
Beta Was this translation helpful? Give feedback.
All reactions