-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semantic search, rough but functional #471
Conversation
Old lessons relearnt...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks clear to me. I think that the semantic-search
components should have more documentation: what is a chain, how does it go together with multibranch? Perhaps this could also be clarified in the README / search documentation. Right now it might not be clear a developer from outside of the project which DOM elements correspond to which views.
Thanks @BeritJanssen. I will add more documentation to the views and also add a (short) dedicated README to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks clean, interested in how the sparql queries are built, but will do this later :)
Seems I encounter a bug. When making a simple query (Name
- is defined
), the result is route http://localhost:8000/explore/item//annotations and shows:
The empty squares are actual items, for example the TextQuoteSelector corresponding with the correct annotation.
Console logs errors:
The select2('open') method was called on an element that is not using Select2. select2.js:6062
Uncaught TypeError: Cannot read property 'open' of undefined select2.js:6068
Also, only partially related, the labels are going wild with languages. I believe you are already aware of this.
Thanks for the review @JeltevanBoheemen! The query that you tried is invalid, i.e., the form is not meant to be used that way. So the output is "expected", but the form is still lacking the validation needed to prevent people from submitting such a query. Again, clear evidence that usage is not self-evident. You can get output that doesn't look so buggy by interjecting a property traversal. (The general rule is that the form as a whole must contain at least one property traversal, and that every chain must end in a filter.) Do you think the validation should be added before we can merge this? The incorrect route is one of the rough edges I mentioned in the OP. |
I think the validation should be in place before deploying to production. I do see the value in testing this out on acc before that though (rough edged as it may be). So I'd say merge. |
This is the finalization of #455, following up on #465 and #468. The welcome view (
/search
route) now has "Text search" and "Semantic search" tabs. The former is open by default and shows the pre-existing full-text search box. The latter reveals the recursive linked data traversal/narrowing/filtering form that I previously demonstrated. When clicking the "Search" button in this tab, the explorer is shown with a single search results panel, usingItemSummaryBlock
to represent each result item. Clicking one opens anAnnotationPanel
with the item. From here on, users can follow the annotations, related items etcetera.There are some rough edges, which I decided not to address yet so that we could deploy sooner:
I merged
develop
into my feature branch in order to test the feature with the new ontology. It worked more or less as-is, but I could not access pre-existing data that were migrated from the skinny ontology because they were associated with superclasses. I also needed to remove the restriction that only leaf classes can be selected in order to be able to follow inverse properties; this is something we'll need to discuss with @fvignale on Tuesday.The final commit in this PR (at the time of writing), 77ec7f4, allows for the selection of superclasses. We could omit/revert this commit in order to stick with the more restrictive subclass-only semantics. Otherwise, a couple of unittests will need slight updates, but this could wait until after merging.
For the review, I suggest the following:
@BeritJanssen
frontend/src/semantic-search
directory.frontend/src/semantic-search
directory.@JeltevanBoheemen
frontend/src/semantic-search
directory.