...
Sprint to extend some of the "read only" APIs, to finalize unit/integration testing for existing functionality, to extend the interface, to develop additional loaders, and to begin developing editing capabilities.
Fleshing out APIs
- DONE: Hierarchy - top level?? rest layer adds a dummy top for merging
- DONE: Clients should handle null parameters properly
- BAC: handle for content, metadata, project, security
- Make a RootClientRest with a precondition check for null or blank
- Search should handle parse exceptions, e.g. if there are mismatched parens or braces, etc.
- Consider all query-based lookups in ContentServiceJpa and reimplement as lucene lookups instead if it seems that it would improve performance.
- Finalize REST service for a general concept query (e.g. lucene query, HQL query, or SQL query)
- DONE: Must start with "SELECT " and not contain ";"
- provide appropriate error message via exception if not
- DONE: Execute the query but check the object type of the first result
- if doesn't match expected type, fail with an exception.
- Use timeout =>
query.setHint("javax.persistence.query.timeout", timeout);
- DONE: Must start with "SELECT " and not contain ";"
- Implement NewConceptMinRequirementsCheck and "validation service"
- Validation check
- validate(Concept), validate(Atom), validate(Code), validate(Descriptor), validateMerge(Concept,Concept)
- Validation service (Rest, ClientRest, RestImpl)
- pre-cache validation handlers (see how this works in MetadataService, etc).
- validateConcept /validate/cui/ (PUT) ConceptJpa
- load all validation handlers and call each validate Concept) method.
- validateAtom /validate/aui/ (PUT) AtomJpa
- validateDescriptor ...
- validateCode
- Requires
- ...
- validateMerge /validate/cui/merge/{cui1}/{cui2} - GET
- DefaultValidationCheck
- validate atom whitespace
- validate that a concept has at least one atom and
- at least one "hierarchical" relationship (to something that exists)
- update config.properties to use this check
- Organize validation checks into packages and create classes
- com.wci.umls.server.jpa.services.validation (DefaultValidationCheck)
- com.wci.umls.server.jpa.services.validation.umls (NewConceptMinRequirementsCheck)
- concept has at least one atom and at least one hierarchical rel
- com.wci.umls.server.jpa.services.validation.snomed (NewConceptMinRequirementsCheck)
- see term server project
- Create an integration (jpa) tests for the validation layer (e.g. put in spreadsheet, normal use, degenerate use, edge cases, etc).
- It may be desirable to organize integration test packages by terminology (e.g. "com.wci....validation.umls" for UMLS checks ".snomed" for SNOMED checks, etc).
- Validation check
- Implement the same check also for a SNOMED concept.
- Then update the mojo test case to remove the terminology (currently commented out)
- Model objects (in their own package)
- jpa layer?
...
- RRF Loader
- Finish metadata loading
- Do content loading
- RRF Loader - single source
Optimizations
- Consider all query-based lookups in ContentServiceJpa and reimplement as lucene lookups instead if it seems that it would improve performance.
- Consider a second search upon a parse exception that doesn't try to use lucene syntax (e.g. remove parens, brackets, etc.)
- Search should handle parse exceptions, e.g. if there are mismatched parens or braces, etc.
Future Stuff
- Test conditional envers auditing: http://stackoverflow.com/questions/14250612/conditional-envers-auditing
- escg (expression grammar - research)
- Use Lucene SynonymFilter with synonym table
- Component-Component relationships (between any two components).
- Value set definitions (and marking of subset.isValueSet()) and linking to definition? via attribute?
- Owl loader, Owl export of DL terminologies (e.g. RF2-loaded SNOMED)
- Rdf export (flat)
- Classifier (owl interface)
- Expression language (based on SNOMED expression constraint grammar)
- Sub-branching
- branchResolutionHandler - figures out how to copy and mark branched objects and update indexes - for different branching strategies.
- Handle mappings - may be not worth it
- Implement an RF2 loader (use DL features)
- Implement a ClaML loader
- Support semantic network (e.g. sty rels, etc). - probably want to wait for a real ontology - and maybe even load it as such.