Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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);
  • 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  
    Implement NewConceptMinRequirementsCheck
    • Requires
      • ...
      • validateMerge /validate/cui/merge/{cui1}/{cui2} - GET
    • DefaultValidationCheck
      • validate atom whitespace
      • validate that a concept has at least one atom and
      one semantic type.
      • 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).
    • Implement the same check also for a SNOMED concept.
  • Properly implement terminology remover functionality (e.g. content service rest.removeTerminology).  The content and the metadata objects need to be removed in the right order so as to avoid foreign key constraint errors. (e.g. attributes, definitions, semantic types, tree positions, transitive relationships, relationships, atoms, then atom classes - something like that).  For metadata I think terminology/rootTerminology is the only dependency (remove root terminology first).
    • Then update the mojo test case to remove the terminology (currently commented out)
  • Implement SNOMED APIs
    • 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.