dpriskorn / dpriskorn/LexSrt

Improvement: Find all forms and cache in a database to increase lookup speed

Open
#17 4 comments 1 reaction 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.