A grammar of SignWriting

Signed languages have not enjoyed the benefits of writing for lack of an effective writing system. Writing systems designed for spoken languages are not easily adaptable to signed languages because signed languages are not based on sound. A successful writing system for sign languages must convey a different set of articulators, namely the configurations and movements of the hands, head, and body to convey meaning. This necessarily means that writing systems for signed languages must find a way to express those articulators, reducing a three-dimensional event to a written representation. One such writing system is SignWriting, a system developed by Valerie Sutton based on her earlier DanceWriting system. Unlike other attempts at writing sign languages such as Stokoe, HamNoSys, or SignFont which imitate spoken language writing conventions with a largely linear sequence of symbols, SignWriting makes use of the spatial relationships of symbols in a two-dimensional sign box to represent a sign. These signs are then written vertically down the page to represent signing. The selection and placement of these symbols is not unpredictable. Analysis shows that SignWriting has a grammar , that is, rules that govern how symbols function and how they combine to form whole written signs. The approximately 35,000 symbols are variations of 639 base symbols. I analyzed these symbols to determine the different categories and subcategories, analogous to analyzing the lexicon and grammatical categories of a natural language. Available data in publicly available dictionaries and online SignWriting lessons provided rules governing how symbols combine to form the representations of whole signs as well as the internal structure of individual symbols, analogous to the syntactic and morphological rules of a natural language. All symbols fit into a set of seven major categories: hand symbols, movement symbols, a head circle with a set of modifiers, torso and limb symbols, dynamic symbols, punctuation, and SignSpelling notation. Symbols for the hands, head, torso, and limbs represent the active and passive articulators utilized by sign languages. The movement symbols describe how those articulators move and interact with other articulators. The dynamic symbols provide additional information to indicate the manner of the movement or how two-handed signs move. Unlike the other symbols which are composed inside a sign box, punctuation symbols are placed in their own sign box and function much like spoken language punctuation. SignSpelling symbols are not used in everyday writing but are used to store a representation of a sign in a dictionary for collating purposes. Because of the analysis required on the symbol inventory, only preliminary research was possible on the structure and relationships within a sign. The last two chapters present some preliminary rules that govern the placement of symbols and what work remains to determine more specific rules. Further research along these lines will hopefully open the way for this system to be more easily used with general-purpose software applications and open the possibility for sign languages to take advantage of written forms in an effective and useful fashion. While the decision to use SignWriting (or any written system for sign languages) remains a sociolinguistic matter to be decided by each Deaf community, it is my hope that this research contributes toward the resolution of the technological barriers so that it is no longer a factor in their decision-making processes

Pancreatic Cysts Identification Using Unstructured Information Management Architecture

poster abstractPancreatic cancer is one of the deadliest cancers, mostly diagnosed at late stages. Patients with pancreatic cysts are at higher risk of developing cancer and surveillance of these patients can help with early diagnosis. Much information about pancreatic cysts can be found in free text format in various medical narratives. In this retrospective study, a corpus of 1064 records from 44 patients at Indiana University Hospital from 1990 to 2012 was collected. A natural language processing system was developed and used to identify patients with pancreatic cysts. The input goes through series of tasks within the Unstructured Information Management Architecture (UIMA) framework consisting of report separation, metadata detection, sentence detection, concept annotation and writing into the database. Metadata such as medical record number (MRN), report id, report name, report date, report body were extracted from each report. Sentences were detected and concepts within each sentence were extracted using regular expression. Regular expression is a pattern of characters matching specific string of text. Our medical team assembled concepts that are used to identify pancreatic cysts in medical reports and additional keywords were added by searching through literature and Unified Medical Language System (UMLS) knowledge base. The Negex Algorithm was used to find out negation status of concepts. The 1064 reports were divided into sets of train and test sets. Two pancreatic-cyst surgeons created the gold standard data (Inter annotator agreement K=88%). The training set was analyzed to modify the regular expression. The concept identification using the NegEx algorithm resulted in precision and recall of 98.9% and 89% respectively. In order to improve the performance of negation detection, Stanford Dependency parser (SDP) was used. SDP finds out how words are related to each other in a sentence. SDP based negation algorithm improved the recall to 95.7%

Using NLP tools in the specification phase

The software quality control is one of the main topics in the Software Engineering area. To put the effort in the quality control during the specification phase leads us to detect possible mistakes in an early steps and, easily, to correct them before the design and implementation steps start. In this framework the goal of SAREL system, a knowledge-based system, is twofold. On one hand, to help software engineers in the creation of quality Software Requirements Specifications. On the other hand, to analyze the correspondence between two different conceptual representations associated with two different Software Requirements Specification documents. For the first goal, a set of NLP and Knowledge management tools is applied to obtain a conceptual representation that can be validated and managed by the software engineer. For the second goal we have established some correspondence measures in order to get a comparison between two conceptual representations. This information will be useful during the interaction.Postprint (published version

The Synonym management process in SAREL

The specification phase is one of the most important and least supported parts of the software development process. The SAREL system has been conceived as a knowledge-based tool to improve the specification phase. The purpose of SAREL (Assistance System for Writing Software Specifications in Natural Language) is to assist engineers in the creation of software specifications written in Natural Language (NL). These documents are divided into several parts. We can distinguish the Introduction and the Overall Description as parts that should be used in the Knowledge Base construction. The information contained in the Specific Requirements Section corresponds to the information represented in the Requirements Base. In order to obtain high-quality software requirements specification the writing norms that define the linguistic restrictions required and the software engineering constraints related to the quality factors have been taken into account. One of the controls performed is the lexical analysis that verifies the words belong to the application domain lexicon which consists of the Required and the Extended lexicon. In this sense a synonym management process is needed in order to get a quality software specification. The aim of this paper is to present the synonym management process performed during the Knowledge Base construction. Such process makes use of the Spanish Wordnet developed inside the Eurowordnet project. This process generates both the Required lexicon and the Extended lexicon that will be used during the Requirements Base construction.Postprint (published version