Skip to content
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

feat(api-v2): Allow querying for rdfs:label in Gravsearch #1649

Merged
merged 10 commits into from Jun 3, 2020

Conversation

benjamingeer
Copy link

@benjamingeer benjamingeer commented May 26, 2020

User story: https://dasch.myjetbrains.com/youtrack/issue/DSP-271

  • Add OntologyConstants.ResourceMetadataPropertyAxioms specifying the object type of rdfs:label, so the type inspection mechanism knows it (by reading it in IntermediateTypeInspectionResult.newInstance).
  • Change AbstractPrequeryGenerator so it doesn't generate any extra statements for a variable that is the object of rdfs:label.
  • Add a knora-api:matchLabel function to AbstractPrequeryGenerator, so you can do Lucene full-text searches in labels.
    • In InferringGravsearchTypeInspector, infer that the first argument of knora-api:matchLabel is a resource.
  • Support the regex function with rdfs:label in AbstractPrequeryGenerator.
  • Add tests:
    • In GravsearchTypeInspectorSpec for type inspection
    • In NonTriplestoreSpecificGravsearchToPrequeryTransformerSpec for generating the prequery
    • In SearchRouteV2R2RSpec for searching for a resource by label:
      • Using a literal in the simple schema
      • Using a literal in the complex schema
      • Using a variable and a FILTER in the simple schema
      • Using a variable and a FILTER in the complex schema
      • Using knora-api:matchLabel in the simple schema
      • Using knora-api:matchLabel in the complex schema
      • Using regex in the simple schema
      • Using regex in the complex schema
  • Update docs (query-language.md).

@tobiasschweizer
Copy link
Contributor

I am looking forward to searching for labels!

@benjamingeer benjamingeer self-assigned this May 29, 2020
Copy link
Contributor

@SepidehAlassi SepidehAlassi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I tried searching for various BEOL resources with refs:label, works like a charm.
Question: Now that we can query for refs:label like any other text value, do we still need to keep the separate route searchbylabel?

@benjamingeer
Copy link
Author

Thanks for the review!

do we still need to keep the separate route searchbylabel?

If I remember correctly, that route is mainly for populating a GUI text box representing a resource IRI in the advanced search widget, so the user can type “Euler” and get Euler’s IRI to use in the advanced search. I guess having a route for this is simpler than making a Gravsearch query, and keeping it means we don’t have to change existing client code.

@benjamingeer benjamingeer merged commit d56004b into develop Jun 3, 2020
@benjamingeer benjamingeer deleted the wip/DSP-271-label branch June 3, 2020 20:15
@benjamingeer benjamingeer mentioned this pull request Jun 3, 2020
@tobiasschweizer
Copy link
Contributor

I guess having a route for this is simpler than making a Gravsearch query, and keeping it means we don’t have to change existing client code.

Maybe you could use Gravsearch internally at some point, and the client would still communicate with the same route. I think we cannot restrict by project yet in Gravsearch: HTTP GET to http://host/v2/searchbylabel/searchValue[limitToResourceClass=resourceClassIRI]
[limitToProject=projectIRI][offset=Integer]

@kilchenmann kilchenmann added the enhancement improve existing code or new feature label Nov 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement improve existing code or new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants