-
Notifications
You must be signed in to change notification settings - Fork 0
The snippets application in wordnet project looking up words
Word lookup is done through APIs which sit in the snippets/views.py module. A bootstrapped documentation is done through an API which shall be the only documentation here.
v1/wordnet/help/list_apis
This describes and enumerates the endpoint and input parameters(data types as well as valid values) for each of the APIs.
From a developers perspective who is going to design and implement new APIs for wordnet, the only requirement is using the viewset(as is already done) in snippets/views.py module. And the documentation(whatever is needed, like API endpoint, input parameters, and anything more) should be specified as docstrings immediately after the particular view method definition. This would automatically picked by the help API and displayed as a part of the documentation process.
As is expected, looking up words with graphs is fun process, sleek and efficient. Sadly the same can't be said of looking up examples for words. This is for two reasons:
- There are not many examples available with wordnet. And most of the words don't have good enough chunk of examples.
- Secondly provisioning for examples as a graph isn't a good idea if the only functionality to be expected is pulling an example as a sentence(text) from a database. In such scenarios an ideal candidate for a database server is a document based processing as against a graph based storage and processing.
But for now the implementation uses the same(or a different) graph for storing sentences. An approach tried was to convert a specified corpus into a network of sentences with nodes being words found(derivations or forms of the same word are different nodes) and edges are the links with unique numders like the position of the sentence in the corpus and the order of the words in the particular sentence.