File Information
File: 05-lr/acl_arc_1_sum/cleansed_text/xml_by_section/abstr/88/c88-2140_abstr.xml
Size: 4,640 bytes
Last Modified: 2025-10-06 13:46:35
<?xml version="1.0" standalone="yes"?> <Paper uid="C88-2140"> <Title>g~ ~he X~ltc=~.-PS'aC/~t:.i~}~:x of Syrrta~c and Semantics ir~ a S-T--nta.~<tica, i.\]:y Gxai~led (;~tsef.~-ame .Parser</Title> <Section position="2" start_page="0" end_page="0" type="abstr"> <SectionTitle> Austria </SectionTitle> <Paragraph position="0"> Abs%ract: in this )~aper we describe a parser for German based on semantic caseframe instantiation guided by a syntactic analyzer o Pure casefra,m~ parsers lack the ability to capture syntactic ~=egularities~ which leads to ~:edundancy :I.n the lexicon and/or poor syntactic coverage, By combining caseframe matching with an explicit syntactic analysis our parse:c overc',omo;:~ this problemdeg Approach~)s w~l\] su:Lted fox.&quot; l~nq'lish are not ~\]asiiy :transported to German with its z'ich ltlorpholo,(\]y and its If:CO0 constituent order at tho c\].atlse J_e, Ve!o Our parser which :{nco:r.'.~ex'ates two d:i fferen% interacting parsing stx'ategios is we\].\], adapted to the needs posed bv German C/~rammaro we believe that the present understanding of structural differences between languages does not yet allow for a single parsing algorithm, at least if one wants both good coverage and efficiencydeg As a consequence we developed a parser which is specifically designed to cope with the peculiarities of the German language.</Paragraph> <Paragraph position="1"> Nevertheless, since our approach is based on sound linguistic principles, most of the solutions found could be applied to other languages with a similar structure as well.</Paragraph> <Paragraph position="2"> In this paper' we will focus on the core of the system's parsing component and neglect other features like spelling correction, treatment of anaphoric or elliptic utterances, quantifier seeping and the transformation into SQL. The overall system architecture is deDicted in \[, ..o~o~.,,: I .....</Paragraph> <Paragraph position="3"> relational data basesdeg Our objectives were: to design a system which has good language capabilities and which at the same time is easily portable. The system has bee~ developed on a SYMBOLICS 3600 and up to no~ has been transported to a PRIME-550II~ a DEC -i VAX 730, and a NIXDORF TARGON-35o DB-DIALOG translates user-queries given in the fo~m of written German sentences into structured SQL statementsdeg Since SQL is the de-facto standard query language for relational database systems, a wide range of database systems is accessible. The only adaptation to be done is a transformation uf the structured SQL output by DB-DIAI.OG into the special SQL used by the spscific DBMSo At the moment versions for ORACLE, REFLEX and MIMER are implementedo null in some other ways the interface is also designed to be as portable as possibledeg Adaptatlon -to new domains is facilitated by keepin q the linguistic, coverage separate from the actual domain knowledge which rests solely in the \].exlcon. Independence from the modeling of the domain in the data base is achieved by distinguishing between a linguistically motivated description of the domain and a database~,orlented one. Tllsre is an explicit &quot;translation step between these two parts. Language independence is not aimed at, because figure io For a description of the interface as a whole see Buchberger et ai./1987/.</Paragraph> <Paragraph position="4"> We have chosen to base our parser on semantic caseframe instantiation. Such an approach is well suited for a restricted domain parser, because of its efficiency (by avoiding useless parses in case of syntactic ambiguity) and its robustness in the case of ungrammaticality (see eog. Grishman et a\]./1986/). On the other hand, relying solely on that method, it would be difficult to capture syntactic generalities (Cog.active-passive transformation), because syntactic as well as semantic restrictions must be specified explicitly for each slot of overycaseframe. This means that for every different syntactic realization of the same statement a different caseframe has to be provided in the lexicon. There are two severe drawbacks to this kind of realization: First, general syntactic properties of the language are implicitly stated in the lexicon entries instead of explicitly in the grammar leading to a possibly inconsistent and patchy syntactic coveragedeg' Second, the lexicon is inflated because for a single word (meaning) a number of different caseframes is needed.</Paragraph> <Paragraph position="5"> To illustrate the problem let's have a look a% an example: 'liefern' (= to deliver) could have the following caseframe:</Paragraph> </Section> class="xml-element"></Paper>