search

ODM2 / ODM2PythonAPI

A set of Python functions that provides data read/write access to an ODM2 database by leveraging SQLAlchemy.
http://odm2.github.io/ODM2PythonAPI/
BSD 3-Clause "New" or "Revised" License
4 stars 13 forks source link

`categorical` Result Type doesn't exist based on vocab database. #126

Open lsetiawan opened 6 years ago

lsetiawan commented 6 years ago

Based on ODM2 Vocabulary Repository for Result Types, I don't see anything with Categorical, but python api is using it. The closest thing I see is Category observation

https://github.com/ODM2/ODM2PythonAPI/blob/dd1ec35d29a1450988cc2b0e8037b04b2c2b3678/odm2api/ODM2/services/readService.py#L1246

emiliom commented 6 years ago

Side question: are you currently trying to implement ALL result types in the REST API?? Or just a narrow subset that @horsburgh specified in the design doc? (I don't remember). I don't think we should be trying to implement every single result type in the REST API, at this time. Time Series and Measurements should be the targets, for now, unless Jeff's Specimen DB actually uses categorical results.

But back to your main point: it sounds like odm2api needs to be updated to match the CV term.

lsetiawan commented 6 years ago

are you currently trying to implement ALL result types in the REST API??

I'm implementing what the database allows me to, others I can't really test, so I don't implement them, the code is there though, since it was easy to just put it there (I took similar code from the python api) It was just something I noticed, so I opened an issue, not planning to act on it whatsoever.

emiliom commented 6 years ago

I'm implementing what the database allows me to, others I can't really test, so I don't implement them, the code is there though, since it was easy to just put it there (I took similar code from the python api)

I'm not sure I completely follow. But my recommendation is not to bother implementing result types we're not using yet in an actual ODM2 database you're aware of. Things may change in the future with the REST API design (eg, see Jim Kreft's email a minute ago!), so let's focus on what we know we're likely to use and test (Jeff's design doc) soon.

But we digress from this github issue. Again, thanks for creating this issue here. Totally relevant and helpful.