LexEVS Meeting Minutes
Meeting Name: / LexEVS Technical meeting / Location: / Stabile 11-69Date: / 09/08/2010 / Time: / 1:00 PM CDT
Facilitator: / Traci/Craig / Attendees: / Larry, Sherri, Rob, John, Jason, Kim, David, Sridhar, Scott, Kevin, Craig Tracy, Gilberto, Andrea
Conf. Line / 866-365-4406, #5388249, Centra ID Mayo_LexGrid2
Topic / Discussion Points / Action Items
· Status / · Alpha 2 was released on Gforge and is loaded onto NCI Dev. / ·
· Browser Topics (Wil/Larry)
o PDQ links (new Gforge item) / · This is a problem in 5.1 but it’s probably likely in 6.0. We’ll have to take a look at both. / · Kevin will take a look at this item to try to fix.
· General discussion on how local extensions functionality works in LexEVS and sample local extension coding scheme (Kevin) / · Kevin demonstrated using a local extension and showed how to register as an extension.
· / ·
· Sample mapping coding scheme based on MRMAP.RRF (Scott) / · Ran out of time for demo. Scott has some files that Kim could look at. / · We’ll plan for demo the week after next.
· SDK REST API searches - case sensitivity issue (Case-insensitive option for database?) What are the downstream effects? – (Kevin/Sherri) / · We have some users of LexEVS use of Rest API and the search is case sensitive. It looks like the use of the REST API is going to increase in the future so we’d like to look at what changes could be made to either LexEVS or SDK to make things better.
· The easiest thing would be a change the database tables to a case insensitive collation. We don’t believe it would change anything downstream. In the regular API, all our searching is done via Lucene first (e.g. property, text string) so it doesn’t seem likely.
· Linux is case sensitive and they like to keep it at that. We don’t specify the character set and case insensitive collation but will in 6.0.
· Larry mentioned setting up a database like that and testing that out and if that works then changes that over. Try it on 5.1 Dev first?
· It could be done for existing data tables. We’d have to alter the current tables. But also change default collation. / ·
· LexEVS REST API / · The REST API exposes the full LexGrid model and is strictly query by example. The LexBIG model is what we use in the API so it does not use that because it’s not physically stored in the database. It is meant to be used in API setting.
· The REST API doesn’t do the full LexEVS functionality. It’s also not easy to do relationship type querying as well as hierarchy processing.
· What this does is make us an SDK like service.
· The REST API that Harold has envisioned would resemble the LexEVS API. This would likely need a model change – but perhaps a model extension. / ·
Adjourn / Thanks for your participation!
LexEVS_20100908_MeetingNotes Page 2 of 3 9/8/2010