[developers] Abstract Wikipedia

[Emily M. Bender]

I think the closest thing to an analog to GF with DELPH-IN materials would
be an 'API' for authoring
MRS representations that is user friendly for non-linguists + some set of
transfer rules that take
those MRSes into ones that work in each language-specific grammar.

The Grammar Matrix itself is not conceived of as a tool for making grammar
engineering easier for
non-linguists (though people frequently seem to want that).

Emily

On Wed, Sep 9, 2020 at 7:54 AM Alexandre Rademaker <arademaker at gmail.com>
wrote:

>
> Yes, definitely. Regarding the unified API for multiple languages, I
> mentioned MATRIX as having a similar goal: in the end, it is all about
> speed up the development of grammars and provides similar analysis of
> similar linguistic constructions (reuse and interoperability), right? Aarne
> Ranta replied to me today in the GF mailing list. Since it is a public
> list, I am copying here (also at
> https://groups.google.com/g/gf-dev/c/A6lNwZ813b0/m/c0r2Lm0eAgAJ) for
> hearing from this community.
>
> He admitted the coverage of GF is years behind, anyway. If so, maybe it is
> one more opportunity to demystify the complexity of real uses of HPSG
> grammars. The previous projects should be enough evidence, but not
> everybody knows about http://moin.delph-in.net/OldProjects. My personal
> experience is that things are not always ready to use out-of-the-box, but I
> find my way through the HPSG/DELPHI-IN universe during the last 4-5 years!
> ;-)
>
>
> > Hello Alexandre,
> >
> > Thanks for pointing this out. This reminds me that I should write a
> little summary of what would be involved in reproducing the RGL, and what
> our starting point was back in 2001. So here it is:
> >
> > The main inspirations of GF-RGL were
> >
> > - XFST, Xerox Finite State morphologies for several languages
> > - CLE, Core Language Engine, an SRI-Cambridge-Telia etc project for
> building syntax modules for some languages to be used in applications
> >
> > The main lesson learned was
> >
> > - make it open source and involve a community. CLE in practically
> disappeared because nobody had the rights to continue with it, and XFST was
> increasingly replaced by open-source variants
> >
> > This brings us to
> >
> > - the LinGO matrix, using HPSG, an open-source project
> >
> > also an inspiration for the RGL, just a bit later, but still alive and
> active. The difference we wanted to make was
> >
> > - think about non-linguist programmers as the majority of users
> >
> > This led us to
> >
> > - design GF and its module system in a way similar to programming
> languages, rather than grammar formalisms
> > - separate the linguist's view (the internals of the RGL) from the
> application programmer's view (the RGL API)
> >
> > The closest GF counterpart of the LinGO matrix is thus the internal
> abstract syntax of the RGL. But when looking at the LinGO/DELPH-IN
> documentation back in 2003 and still today, I cannot see anything
> corresponding to the API. It is more of a linguists' project than of
> programmers'. And I think it would be quite a job to develop it into an API
> direction similar to GF. Not only is the starting point less friendly to
> that (with GF's formal distinction between abstract and concrete syntax),
> but even in the GF world, it took several years to bring the module system
> and the compiler into a state that smoothly supports the division of labour
> between linguists and application programmers in the way we do.
> >
> > This said, HPSG has reached longer in their linguistic coverage in many
> languages, in particular in the English RGL: GF has nothing like that, and
> again it would take years of work to build it.
> >
> > Of course, the nicest thing would be to share resources in a formalism
> independent way. This looks quite feasible in the case of morphological
> lexica, and is an ongoing practice already. But when it comes to syntax, I
> am less sure. Syntax code in GF and HPSG and other higher-level (above
> context-free) formalisms is essentially like code in different programming
> languages. There the practice is that each language has to build their
> standard libraries from scratch (think about for instance collections and
> generics in Java, C++, Haskell,...) An alternative is to enable foreign
> function interfaces (like from Python to C), but I cannot see very
> concretely right now how this would look for instance between GF and HPSG -
> and how much there would really be to gain. But of course we have mutual
> communication, for instance by co-organizing GEAF workshops (Grammar
> Engineering Across Frameworks), and see each other as allies rather than
> enemies.
> >
> > ParGram (in LFG) could also be mentioned, but it used to be a
> proprietary system that was more difficult to learn from.
> >
> > Regards
> >
> >   Aarne.
>
>
> Anyway, the abstract wikipedia project is about language generation and it
> seems very interesting.
>
> Best,
> Alexandre
>
>
>
> > On 9 Sep 2020, at 10:47, Emily M. Bender <ebender at uw.edu> wrote:
> >
> > Dear Alexandre,
> >
> > The ERG has been under continuous development since 1993, with
> definitely more than 27 person-years in it at this point. I guess the
> question is whether the GF resources are comparable in scale...
> >
> > Emily
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20200909/9632243f/attachment-0001.html>