<?xml version="1.0" standalone="yes"?>
<Paper uid="W04-0904">
  <Title>OntoSem and SIMPLE: Two Multi-Lingual World Views</Title>
  <Section position="6" start_page="3" end_page="3" type="concl">
    <SectionTitle>
5 Conclusions
</SectionTitle>
    <Paragraph position="0"> Although space does not permit us to fully describe the resources, programs and resulting TMRs for sentences (a)-(e), this snapshot of their processing underscores the point that developing resources within an environment where they are tightly coupled with processing has clear advantages over developing resources in the abstract. Of course, in the absence of a full environment, projects like SIMPLE make sense. However, the challenges of resource development outside of an environment are keenly felt by developers: as Calzolari (1999:42) reports: &amp;quot;A dichotomy at stake here is the one between generality of a LR [lexical resource] vs. usefulness for applications. In principle, only when we know the actual specific use we intend to do [sic] of a LR can we build the 'very best' LR for that use, but this has proved to be too expensive and not realistic. In practice, however, there exists a large core of information that can be shared by many applicative uses, and this leads to the concept of &amp;quot;generic&amp;quot; LR, which is at the basis for the EAGLES initiative and of the PAROLE/SIMPLE projects, to be then enhanced and tuned with other means&amp;quot;. The only aspect of this statement that we would dispute is the unrealistic nature of building resources for particular systems. If a system, like OntoSem, creates text-meaning representations that can be used equally effectively for many applications, then there is no reason why they cannot be built specifically for the given environment. In other words, when the result of semantic analysis is a metalanguage-formulated TMR, programs of any profile can exploit this representation. Stated differently, there need not be a direct link between end applications and the input text elements or their lexical representations.</Paragraph>
  </Section>
class="xml-element"></Paper>