persephone-tools / persephone-web-api Goto Github PK

Need to see if there are memory or namespacing issues from having more than one model be available to users at once.

Currently this serialization to JSON being done in code and duplicated in various places, move to a schema based approach.

Currently if you GET either of these you get a reference to where these are used in Utterances:

*** uploading WAV files ***
{
  "filename": "crdo-NRU_F4_ACCOMP_PFV.1_21.wav",
  "id": 1,
  "in_utterances": [],
  "url": "uploads/audio_uploads/crdo-NRU_F4_ACCOMP_PFV.1_21.wav"
}
*** uploading transcription files ***
{
  "filename": "crdo-NRU_F4_ACCOMP_PFV.1_23.phonemes",
  "id": 1,
  "in_utterances": [],
  "url": "uploads/text_uploads/crdo-NRU_F4_ACCOMP_PFV.1_23.phonemes"
}

This currently is not in agreement with the API specification. Should we expose this information to the user from these endpoints or not? (Incidentally this is the exact sort of issue that GraphQL solves nicely)

Similar to the test case in Persephone persephone/tests/experiments/test_na.py::test_tutorial

Some of the API parameters have changed and updating the example would be good

For ease in deploying, see persephone-tools/persephone#131

Be able to manually specify the maximum samples parameter.

Cuts down on code needed.

Having two classes called Corpus is confusing, change the class name for the DB ORM that handles Corpus

Currently only the response code for successful creation (201) is included in the API specification YAML file. The cases where an invalid request (400) or a duplicate (409) are not currently in the API sepcifcation.

Probably using alembic

Create a basic search endpoint

Consider this script to create a corpus via Curl:

# This is a very quick and dirty to populate some initial data via calling the API.
# Note that for now ID's are hardcoded in later steps.
# TODO: process response data IDs
# Upload WAV files
echo "*** uploading WAV files ***"
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --form audioFile=@crdo-NRU_F4_ACCOMP_PFV.1.wav 'http://127.0.0.1:8080/v0.1/audio'
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --form audioFile=@crdo-NRU_F4_ACCOMP_PFV.3.wav 'http://127.0.0.1:8080/v0.1/audio'
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --form audioFile=@crdo-NRU_F4_ACCOMP_PFV.7.wav 'http://127.0.0.1:8080/v0.1/audio'
# Upload transcriptions
echo "*** uploading transcription files ***"
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --form transcriptionFile=@crdo-NRU_F4_ACCOMP_PFV.1.phonemes 'http://127.0.0.1:8080/v0.1/transcription'
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --form transcriptionFile=@crdo-NRU_F4_ACCOMP_PFV.3.phonemes 'http://127.0.0.1:8080/v0.1/transcription'
curl -X POST --header 'Content-Type: multipart/form-data' --header 'Accept: application/json' --form transcriptionFile=@crdo-NRU_F4_ACCOMP_PFV.7.phonemes 'http://127.0.0.1:8080/v0.1/transcription'
# Create Utterances
echo "*** specifying utterances ***"
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
   "audioId": 1,
   "transcriptionId": 1
 }' 'http://127.0.0.1:8080/v0.1/utterance'
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
   "audioId": 2,
   "transcriptionId": 2
 }' 'http://127.0.0.1:8080/v0.1/utterance'
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
   "audioId": 3, 
   "transcriptionId": 3 
 }' 'http://127.0.0.1:8080/v0.1/utterance'

# Create corpus
echo "*** creating corpus ***"
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/problem+json' -d '{
   "name": "Test Corpus", 
   "label_type": "phonemes",
   "feature_type": "fbank",
   "testing": [
     1
   ],
   "training": [
     2
   ],
   "validation": [
     3
   ]
 }' 'http://127.0.0.1:8080/v0.1/corpus'

Gives this:

{
  "feature_type": "fbank",
  "filesystem_path": "f2976bee-900f-11e8-9a5f-d8cb8acb264b",
  "id": 1,
  "label_type": "phonemes",
  "max_samples": null,
  "name": "Test Corpus",
  "preprocessed": false,
  "testing": [
    1
  ],
  "training": [
    1
  ],
  "validation": [
    1
  ]
}

The test, train, validation are the primary keys of the DataSet DB models, NOT the utterance primary keys.

{
  "filename": "crdo-NRU_F4_ACCOMP_PFV.1_16.wav",
  "id": 1,
  "in_utterances": [],
  "url": "uploads/audio_uploads/crdo-NRU_F4_ACCOMP_PFV.1_16.wav",
  "utterances": []
}

{
  "filename": "crdo-NRU_F4_ACCOMP_PFV.1_18.phonemes",
  "id": 1,
  "in_utterances": [],
  "url": "uploads/text_uploads/crdo-NRU_F4_ACCOMP_PFV.1_18.phonemes",
  "utterances": []
}

In this in_utterances is a duplicate of utterances.

There are times where returning error information will make the frontend much easier to write. For example a mismatch of label types would be a good thing to have an error response about.

Currently these are being fetched from the app.config which is not the right way to go about this

This will make it easier to run this locally.

Currently in ad-hoc arrangement

Currently this parameter is not supported.

Create API for model definitions

Currently this parameter is not supported.

Say you have an audio and a transcription and you create an utterance with those ID's should a second call with the same ID's create a new utterance?

Currently these files get written to disk and not cleared after a test run.

Prevent memory exhaustion issues that can occur from uncapped file upload sizes.

Having a real ELAN file to test against would make life much easier for development

Currently the example data has the same id duplicated in the testing, training, validation sets which is confusing and represents improper usage of the API.

It might be good to expose information about which filetypes the backend will accept.

Should we support this?

Currently for development purposes files are being served via flask which is not production ready.

Settings need to be changed in GitHub organization to allow this.

For convenience in specifying the allowable labels for a Corpus.

Currently when you upload more than one file of the same name a duplication check is performed so that nothing is overwritten but that means when you download the file again the name can be different to the name of the file you uploaded. This is something that needs a bit of attention.

Should duplicate files have the same ID or different IDs?

Currently some tests that really only need a DB fixture are being created via API call automation. While that's OK for integration tests it's not ideal for unit testing.

See https://github.com/klen/mixer for possible solution.

Use the serializers instead of ad-hoc approach.

Explain how the yaml file specifies the API endpoints and pipes this through to the python API handling code.

Setting up a VM with a development environment will reduce time required for contributors to get started

https://github.com/shieldfy/API-Security-Checklist

Needed for long running tasks

An endpoint to use existing models to transcribe audio

Currently these are scattered around and should be moved to the one place in API flask app initialization

Currently a lot of duplicated testing code

Currently the corpus name is used in the filename for ease of development, this isn't good practice for a variety of reasons and will need to be changed for a production release.

Make all the filesystem artifacts required to run a Persephone model.

Currently there's no support for this in the API because it's mostly dependent on implementation details of the ASR software in the backend.