2026 SIG‐notes (Presentation, maintenance, and demos for DELPH‐IN grammars) - delph-in/docs GitHub Wiki

DELPH-IN Demos discussion (Lightly scribed by Luis; unrevised)

Dan: There were some concerns about the demo Francis presented earlier this week. this demo is designed to preserve grammars; some grammars; the grammars needed to have some extra work to make them compile and parse a sentence; Among the objections include: we don't do much to set expectation about what we expect each grammar to do (i..e, parse) -- e.g., "there are only 5 sentences that parse with this grammar". And then people will meet frustration if they need to do this by trial and error. the LTDB tells them what is in the lexicon; also rule names, but not if/how they are used; One solution is to write a few page intro about each grammar; maybe use existing testsuites. Also if it is domain specific; etc. Maybe some links through phenomena specific (e.g. using the grewmatch machinery Francis uses). We have 18 languages (23 grammars, many are shared -- ERG has a few versions). We also didn't talk with the different authors and ask permission and or inform them that this grammar exists. For example the Swedish grammar had defaults and we needed to remove that so it could be compiled with ACE. There was also a wildcard in some strings that we also removed without knowing what it did. We should probably set some communication channel with these grammarians. Also, someone could go through the grammars to make them generate.

Emily B.: the Wambaya grammar should generate;

John: Hausa grammar should also generate...

Dan: At a higher level we might wan to enumerate what these publicly visible grammars should say about themselves; If they should all be there in the first place (i.e., Russian grammar being an example for being very tiny); And then this other question about how much we should add.

Ann: Target used? Before going into detail, we need to know what the target user should be. If a specific phenomena is sufficiently well represented it doesn't matter how tiny a grammar is...

Dan: The problem currently is mostly the setting of expectations that we do not provide;

Ann: could we have 4 categories from "tiny" to "resource" and then say something like "Russian (tiny)".

Emily B.: And we could even have an English tiny (from the textbook)

Dan: maybe multiple tiny ones (points to some other implementation);

Emily: the Matrix Customisation system also has another tiny;

LMC: back to target group?

John: could you put one sentence next to each grammar?

Dan: yes; Francis did mention;

Ann: If you think of some types of target user then we can be interested in this sort of thing;

Dan: that's a good point, we will want to guide people on how to use the tool; As there are quite a few of the grammars that use the compound rules (other apposition). So there is some occasional harmony.

LMC: I like that idea that you avoid showing a large number of grammars (as it could be overwhelming for a user to read 20-30-50 grammars)

Spencer: we could also have a default, e.g. for medium and large...

Ann: How about linking some of these phenomena to one of Emily's books?

Dan: This also links to the the Cambridge grammar idea...

Emily B.: I don't think I link to the ERG too frequently, there are also not only English sentences, but I can provide you with the list of sentence

Ann: I'm specifically thinking about people who may want to go over these books by themselves...

Emily B: There may be problems with license for some of these sentences...

Ann: I would put them up and let them complain and then remove them I can also see it being useful for people putting the examples sentences in and checking if it's the same

Emily B: with the grewmatch, how close are we to finding things that look similar to others (this is Ned's stuff TypeDiff)

Dan: I don't think Francis has this machinery running... I would like to have the capability for Emily's book and for the Cambridge Grammar; I don't want to write 2000 pages of documentation, being able to point to the a grammar/chapter etc. This is true for other languages... most languages do have some reference grammar

Emily B: Jacy has its own book but there are also other grammars that could be pointed to;

LMC: And maybe link this to the docstrings in some way??

Emily B: there is too much lack of alignment; maybe one phenomena also needs multiple types to interact with each other (e.g. Noun Incorporation);

Dan: maybe there are multiple ways we would want to provide this alignment (not maybe a single pattern); I was conceiving the enumeration working with grew; the docstrings are a different endeavour;

Ann: Having a pointer to a DOI for a specific grammar could be useful in other ways

-- Everyone agrees that we are talking about two slightly different things ---

Ann: I think it would be good create some example of best practices in docstrings, so we could subsequently do some post-processing to get the info you want;

LMC: I've mentioned this relating to the Grammarium;

Emily B: I'm very excited to trying this idea of getting the sentences from the books; Maybe running the language index as well

Dan: We have talked at previous delphin summits that we could work towards a test suite for semantic phenomena; Ann and I worked on this (on a train ride to/from Edinburgh); We didn't put too many constraints about what needs to be present, not all languages will have exactly those; And we have those MRS suites and their behaviour drift around into this ecosystem. Most grammars have this test suite. It's not an enormous amount of work; It is possible maybe to think of a student project where some student can help create these for all languages (if they are missing). I believe most of these could probably do pretty well.

LMC: it could also be used evaluation (next to the tag "tiny" through "resource");

EMily B: the size of the lexicon and whether they can generate would would be quite nice indicators;

Dan: it would also be nice to have multiple indicates, because generation is not "yes or "no". I can now generate generic;

Emily B: I was going to ask if we wanted to reprise the discussion we tabled in a previous SIG -- about batch processing. The first suggestion is to create a container of sort container (whether that is named for AWS or Google Cloud). We did something like that

Ann: apparently there are many services within AWS. Can I ask whether we really want to do this at AWS?

Emily B: Is there an European cloud provider? Something more environmentally friendly and not enriching the tech We should identify the cloud provider and then

Dan: Let's imagine that this exists: what is missing? I guess sentence segmentation is one of these. This is also domain specific. But it has always seemed fairly simple.

Ann: We do need to use the grammar because time people have used something like the ERG with their own sentence segmentation they have complained about coverage because they don't know what the ERG needs;

Dan: as a grammarian I want to decide on these sentence boundaries; Maybe the Norwegian grammar is also quite good at that. Would you (Petter) be willing to tackle this?

Petter: it struggles on long sentences, but fine

Emily: So would the idea that these containers would be for one or multiple language? (Maybe something to deal with later); So the main idea would be to have a container that takes text that would have been cleaned (e.g. from HTML) and some flags, e.g., top N, and get the fully parsed.

Ann: this would allow many more people to set up other (Student) projects using delph-in grammars; without this we couldn't use this for an undergraduate project

Emily B: 2 questions: we need to think about the release cycle for each grammar (e.g. ERG); and the second grammar woudl be how much support do we provide to help dealing with he output

Ann: Pydelphin does a good job at that.

Dan: We may still want to show a few examples.... And include Pydelphin in that container;

Ann: I can imagine that a lot of what people would wnat to do would eb to add things to pydelphin;

LMC: we should not focus on pydelphin because the goal is to sent some text and receive some container (e.g. JSON) with the primary objects that the grammar produces (trees, MRS, dmrs) and just provide examples (outside these containers) where you could read these JSON.

Ann: I think the data output should be simple... Wikiwoods was too complicated

Dan: AGREES;

--- people agree that a simple version should be minimal, but could be more complex with the use of parameters ----

Dan: how many languages could we hope to do that for?

Emily B: Maybe JACY?

Dan: Francis tells me that for running text it would be a challenge due to preprocessing;

Emily B: One of the things we could do about that is to run a NER and substitute every named person by Tanaka-san.

Dan: Chasen is still part of the need for JACY

--- some discussion about YY mode ---

John: there is a a difference here about the pipeline, the problem with Freeling is that it runs as a server; it enables a protocol that goes beyond line by line input;

Ann: For quite a lot of application e would want to regard the DMRS as an annotation of the surface string -- this means that you need a CFROM and CTO to remain stable. But with some of these preprocessing you may get misalignments; We were trying very hard to keep things aligned, and it's really horrible. I want to flag this a problem we want to try to keep away. With XML not respecting white space (which is also a problem with other things as well) does make it a problem to keep CFROM and CTO aligned at all time.

Dan: would you want to have the Wambaya grammar?

Emily B: I think it's not a lot of uses for it...

Ann: that brings up another class of user: group of people who are trying to work with endangered and/or extinct languages. We could think about what we want to support.

Emily B: do you have David Innman's grammar yet?

Dan: Not yet. We have contacted him. But we have Woodley's grammar of Ancient Greek.

Emily B: there is also a Joshua Crowgey's grammar, which someone else took over. I could contact him.

Ann: Was there ever a Plattdeutsch (Low German)?

Dan: I met someone at LREC from Hamburg (?).

Ann: There is funding to do this... I think there may be funding to work on these small scale languages. Local funding (e.g., local states).

Emily: Grammar Kalaallisut (Chia-hsiang). And also Antske's Climb grammar (German, Dutch, Frisian).

Emily: As we are thinking about parsing... how do we think about GIG and HAG?

Dan: Hausa grammar is good enough to be interesting; the German grammar causes the MRS rendering to not work; It's more mysterious about what it is supposed to be able to do;

Emily: When Antske was developing GClimb, she was doing so against someone else's German grammar

Dan: Some grammar designed to be efficient and not very linguistic

Ann: was it "Yet another German grammar"?

Dan: it was something like "Cheetah"; it was robust; It was reminds me that for each of these grammar we can serve a canonical publication and I don't have good publications for all the publications of the 18/23 grammars that are there; I guess I could point the grammarians to that desire and ask them for a couple quick references. They would know what best to;

LMC: why only 3?

Dan: I need links... Someone should do them all but not

Emily: Antske has a a Cheetah test set; There is also the notion of the grammar catalogue. Maybe that page should point to LTDB for more up to date information.

Dan: I agree. I think there is nothing that would not be superseded by LTDB.

Emily: Do you (Luis) would want to have them in Grammarium.

Luis: Yes, but I need GitHub repositories

Dan: We should ask the grammarians because this exposes old work that then becomes searchable;

Luis: Maybe this means we can have them as "private fork repository" -- this also aligns with Emily's request for letting Grammarium compile private repositories.