gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] SOAP - Edit Area - Parser - some thoughts


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] SOAP - Edit Area - Parser - some thoughts
Date: Fri, 2 Jul 2004 13:42:24 +0200
User-agent: Mutt/1.3.22.1i

> Personally I don't beleive that is silly as it sounds, except I'd hasten 
> to agree with Karsten that at this stage of evolution we should 
> definately not try and parse natural language. However, parsing has a 
> place. I do it extensively in my program on a very simple level - e.g to 
> spell check all the words, to remove additional blanks, to separate test 
> names etc which are separated on thes screen by my delimiter (eg 
> FBC;ESR;UEC;LFT;)
Which I would call sanitizing/normalizing and which of course
needs to be employed heavily.

> Now, getting back to my comments from a previous posting about having 
> purpose build 'edit area' editor, which auto-expands the available lines 
> as one runs out of space, this is a situation where simply parsing comes 
> into its own. It is then used to parse out and link the lines opposite 
> the labels which are embedded in the edit area, but can also be used to 
> parse out say a tag the user has insert using control keys eg hitting 
> Ctrl(whatever) to insert the visual (different coloured tag) BP=. The 
> parser assumes what comes after this tag must be in the format nnn/nnn. 
> It both in real time validates the input is a digit (I do this very 
> simply in the measurement part of my program), and later, when the user 
> clicks the OK button to save  the data, assigns any BP measurements to 
> the appropriate measurment fields. Hence later one could simply review 
> all the BP's in the medical records with dates.
Surely, all this is (mostly) syntactic parsing. The parsers
knows nothing about what the data is to *mean*. Which it would
have to if we expect it to understand by itself that p/ starts
plan text. What you show here is all very useful.

> I think the mistake is to try and make it complex.
Yes !!

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]