Improvement: Find all forms and cache in a database to increase lookup speed
- Dominant language
- Python
- Stars
- 3
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
Currently, when the input is long, LexSrt can be slow as it makes as many Sparql queries as there are tokens in the input.
As an example, Ordia combines all the input into one (long) Sparql query using the following syntax for the input:
```sparql
VALUES ?word { "fruit"@en "flies"@en "like"@en "bananas"@en }
```
Also, `spacy_token_to_forms` would become `spacy_tokens_to_forms` to accept all the tokens in one call.
The tokens won't have a single lexical category, so that part of the Sparql query would need to change too.
**Option 1:** It's possible to write the input for both variables like this:
```sparql
SELECT DISTINCT ?representation ?lexical_category ?form {
VALUES ( ?representation ?lexical_category ) {
( "flies"@en wd:Q1084 )
( "like"@en wd:Q24905 )
}
?lexeme dct:language wd:Q1860 ;
wikibase:lexicalCategory / wdt:P279* ?lexical_category ;
ontolex:lexicalForm ?form .
?form ontolex:representation ?representation .
}
```
**Option 2:** I think it might be better to move the filtering by lexical category to be outside of the Sparql query (but this can be a follow-up issue). This way, you can find results even when spaCy has guessed the lexical category wrong. (After the Sparql query returns results, you can filter out duplicate lexemes where the lexical category doesn't match.)
```sparql
SELECT DISTINCT ?representation ?lexical_category ?form {
VALUES ?representation { "flies"@en "like"@en }
?lexeme dct:language wd:Q1860 ;
wikibase:lexicalCategory ?lexical_category ;
ontolex:lexicalForm ?form .
?form ontolex:representation ?representation .
}
```
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.