wanted: RGL world map

[Aarne Ranta]

Dear All,

I wonder if anyone could contribute a world map of the Resource Grammar Library coverage. What I have in mind is a world map with the following properties

- shows in colours the regions/countries whose languages are covered in the RGL

- dark colours for full coverage, pale for partial; cf. the table in http://www.grammaticalframework.org/lib/doc/status.html 

  - dark: Lang and Dict 

  - normal: Lang

  - pale: anything else in the table

  - white: nothing in the table

- viewable both in colour and b/w (for instance, to include in published papers)

- open source, free distribution and modification

- easy to edit e.g. add new languages and change their status

- if possible, interactive: clicking and/or hovering gives more information on the language, its GF implementation, etc

- if possible, scalable

- more ideas welcome

This would be great documentation for the future Summer School (http://school.grammaticalframework.org/2013/) but also in general.

If you have skills and experience in producing such maps, you contribution will be greatly appreciated!

With best regards

  Aarne.

[Tommi Nieminen]

Hi,

I can help with this. We could use one of wikimedia's SVG maps (like this one http://upload.wikimedia.org/wikipedia/commons/8/80/World_map_-_low_resolution.svg) and then use the Raphael JS library to do the effects (like here http://raphaeljs.com/australia.html).

I've done a small project with Raphael recently (http://www.postcrashgames.com/finitris), so it's relatively fresh in my mind. It's not big job, so I could get the map ready by the end of December.

-Tommi

---

Date: Mon, 19 Nov 2012 11:08:53 +0100
Subject: [GF] wanted: RGL world map
From: aa...@chalmers.se
To: gf-...@googlegroups.com

[Aarne Ranta]

Hello Tommi,

Thanks for the quick reply! And yes, these look like very good tools to me.

And anyone else, if you have other tools to suggest, please bring them to discussion here!

It would be great to have a simple draft map before 8 December, to show in some events in Coling in Mumbai. Do you think this would be possible?

With best regards

  Aarne.

[Tommi Nieminen]

Hi,

I can definitely get a draft together by 8 December, that will probably just take a few hours (just connect map to data and add some hover handlers etc.), and I can always find that much time.

-Tommi

---

Date: Mon, 19 Nov 2012 11:41:41 +0100
Subject: Re: [GF] wanted: RGL world map

[Tommi Nieminen]

Hi,

The first draft of the RGL world map is now live here: http://www.postcrashgames.com/gf_world/index.html

The color coding is intended to show how comprehensive the RGL coverage is in each country: bright green countries have total coverage, dark green partial coverage, and white countries no coverage. When counting the coverage, we need to take into account the languages which are not included in the RGL. I've not added these languages separately, instead there's a dummy language "UnimplementedMajorLanguage", which is added to each country that has a major language not included in the RGL. This dummy language will lower the coverage score of the country and make it's shade darker.

If you'd like to see some feature added or notice mistakes (there's bound to be plenty), let me know.

[Krasimir Angelov]

Hi Tommi,

This looks great. It looks like we have already conquered most of the
world ;-). What is the meaning of the tag "Darcs" in the popups? It
seems to be everywhere. Also it would be nice to have some description
for the other tags although I can decipher them.

Regards,
Krasimir


2012/11/26 Tommi Nieminen <niemin...@hotmail.com>:

[John J. Camilleri]

Looks good!

I would suggest changing the colours though, to me the white seems more intense than the green.

Perhaps you could use white for the sea, and grey for unimplemented languages, like in Google Analytics (see screenshot).

I think it looks that little bit cleaner!

[Tommi Nieminen]

The Darcs tag is from the status page, I just copied the tags from there. Is darcs no longer used for version control?

I've added a legend for the tags and changed the color scheme as John suggested. I also tinkered a bit with the country scores, so that non-western countries with many implementations are more visible (i.e South Africa, India and Pakistan) and non-western countries with only English or French are less visible (i.e. most of Africa).

New version in the same place: http://www.postcrashgames.com/gf_world/

-Tommi

> Date: Mon, 26 Nov 2012 16:08:49 +0100
> Subject: Re: [GF] RGL world map
> From: kr.an...@gmail.com
> To: gf-...@googlegroups.com

[Krasimir Angelov]

2012/11/27 Tommi Nieminen <niemin...@hotmail.com>:

> The Darcs tag is from the status page, I just copied the tags from there. Is
> darcs no longer used for version control?

We use Darcs but since all complete RGLs that I know are in the
repository, I don't see much use for this tag. Anyway, I don't have
strong objections against it.

> New version in the same place: http://www.postcrashgames.com/gf_world/

Now it is really awesome.

[Michal Boleslav Měchura]

Excuse me for being a nitpicker but I think the map is problematic
because it ignores the existence of many languages. That makes some
countries come up as full coverage when in fact they're not fully
covered.

For the United Kingdom, I would suggest the map account for the fact
that neither of the British regional languages (Irish, Welsh, Scottish
Gaelic and others) have been implemented in GF. Many of these
languages have co-official status in parts of the UK. If you discount
them, the UK will come up as complete coverage (as it does now) while
the Republic of Ireland comes up as partial coverage, which appears
inconsistent. The two countries have about the same level of coverage
in GF in fact. Alternatively, divide the UK into its constituent
countries and labels them separately. (None of this is to preclude or
predict the results of the upcoming independence referendum in
Scotland! :-)

You will run into lots of issues like this in other countries in
Europe, even more so in Africa and Oceania where the language map is
much more speckled than the political map. For example, the map seems
to make no account of Breton in France, Saami in Scandinavia, Berber
in North Africa. My apologies if all this sounds discouraging but I
thought it was important to mention this now before the map is shown
at a big conference somewhere and somebody with an axe to grind
objects indignantly!

Michal

[Olga Caprotti]

:) Malta has become very big in this map.

--olga

[John J. Camilleri]

Unfortunately I tend to agree with Michal, we should be sensitive to such issues.

With regards to Malta, it seems to have been replaced by a circle which remains the same size regardless of zoom level. I don't really like this to be honest, perhaps the underlying map should be updated to include Malta as a regular land mass, despite its size.

[Jyrki Nummenmaa]

It might be easiest just to show in the map what has been done and

to avoid being specific about what has not been done. 

The easy way out seems to be to remove the comments about

missing (major or not) languages. It might be worth noting, though, 

if there is nothing about no official language of some country.

Regards, 

Jyrki

[Kaarel Kaljurand]

Hi,

On Tue, Nov 27, 2012 at 12:09 PM, Jyrki Nummenmaa
<jyrki.n...@gmail.com> wrote:
> It might be easiest just to show in the map what has been done and
> to avoid being specific about what has not been done.

the basic problem is that in the real world the country borders do not
match language borders. So it would be better to use a
language-border-map as the basemap, although I haven't come across
one.

Another option is to go with the countries map but provide alternative
language->country-list mappings that the user can switch between. E.g.
you currently use http://www.postcrashgames.com/gf_world/status.js
which seems to map language codes to country codes which have this
language as an official language. You could have a set of additional
mappings where the country list accounts for regional, semi-official,
immigrant etc. languages.

Best regards,
Kaarel

[Tommi Nieminen]

Hi,

I appreciate all the concerns you have, in fact I had most of them myself. The current map is a compromise, but I agree that it could be better. I think I have the ideal solution, though: select the country's color by the number of L1 speakers of RGL languages divided by total population (add some extra for lingua francas). The information should be easily available through Ethnologue and demographic sources.

Just in case, does anyone see a problem with this approach?

-Tommi

[peter ljunglöf]

Yes, I don't think we can use "number of L1 speakers" -- in Sweden we have several official languages, but the others have so few L1 speakers that it wouldn't show any difference. This is the case in many other countries too.

/Peter

[Olga Caprotti]

how about something with spikes similar to http://workshop.chromeexperiments.com/globe/ ?

it is for chrome afaik.

--olga

[Tommi Nieminen]

Hi,

The effect of the small languages wouldn't show, but in principle they would make a difference (no matter how small), and I think that's enough. The worry was that with my earlier way of measuring RGL coverage (based on the amount of languages) people are going say "what about language X, why isn't that accounted for?" (and they would be justified in doing that). If the coverage is measured by proportion of population, that's no longer a problem (all other languages are accounted for, as they are included in the difference between the total population and RGL language speaking population).

I think if the purpose of the map is to show RGL coverage for practical purposes (such as deciding whether to use GF for a commercial multilingual application), per capita coverage is actually a much more useful metric than per language coverage. But above all it simplifies the task immensely, as doing justice to per language coverage would mean counting the languages in each country with at least one RGL language (that's a big task with lots of boundary issues).

To Olga: I've done the map with jVectorMap, which can't do spikes, unfortunately. I also imagine it would be quite a job to collect the information for the spikes :)

-Tommi

> Yes, I don't think we can use "number of L1 speakers" -- in Sweden we have several official languages, but the others have so few L1 speakers that it wouldn't show any difference. This is the case in many other countries too.

>
> /Peter
>

[Inari]

Hi! Could this map be updated to reflect all the new languages since 2012? :-D Or alternatively, should we (≈GF core team) host this map and update it ourselves?

Inari

[Peter Ljunglöf]

Hej!

The RGL is really nice and useful, but I'm a bit worried about how it has been evolving lately. From the start it has been growing quite organically, which worked fine in the beginning when there were few implementors and it wasn't used in practical applications. But I don't think the anarchist model works anymore.

There are two main issues currently, as I see:

1. New languages: there is almost no moderation when someone suggests to implement a new language. This means that someone can "hijack" a language simply by being the first who suggests it. This is exactly what was done with the Bantu functor and the Swahili language a coupe of months ago, see the following two issues:

https://github.com/GrammaticalFramework/gf-rgl/issues/105
https://github.com/GrammaticalFramework/gf-rgl/issues/106

The Bantu functor was a pull request that was directly adopted without any discussion, even though I know there are other people working on Bantu implementations. We need a more critical discussion when it comes to new languages, and in particular new functors.

(Note: I don't blame kitukb (the implementor) for issuing the PR, but there should have been a larger discussion on this list before accepting it)

2. Documentation: there is way too little documentation of the RGL, both for users and for implementors. I know that is's boring and tedious and difficult to get paid to do this, but it's really important if we want GF and the RGL to be used by more than a handful of people.

3. Finally, the structure of the RGL is difficult in itself. There are the "traditional" modules in 'abstract/' and 'your-language/', but then there are the "newer" ones in 'api/'. And in api, there are the Combinators, Constructors, Symbolic, Syntax and some more. It's not clear to me how they relate to each other or to the "traditional" modules. There is also the 'experimental/' and 'parametric/' modules, which I have no idea how they fit with the others.


I'm really impressed by the development of the RGL the last years, and now I think it has reached a level where we have to discuss how to ensure its quality in the future. In short: we need a roadmap, and this is a call for a discussion about this roadmap. Questions to be discussed:

- what should be the process for including new languages, and for making larger changes to existing languages?
- how can we improve the documentation? e.g., guidelines for implementing new languages, example use cases for all(most) RGL constructions
- is there a need for cleaning up the RGL? now some language specific things are in 'your-language/' and some in 'api/'
- should we add support for test cases? e.g., enforce RGL implementors to create a small corpus that can be tested automatically

best,
Peter

[John J. Camilleri]

Great post, Peter. Here are my quick reactions:

On Wed, 2 Jan 2019 at 10:50, Peter Ljunglöf <peter.l...@heatherleaf.se> wrote:

Hej!

The RGL is really nice and useful, but I'm a bit worried about how it has been evolving lately. From the start it has been growing quite organically, which worked fine in the beginning when there were few implementors and it wasn't used in practical applications. But I don't think the anarchist model works anymore.

There are two main issues currently, as I see:

1. New languages: there is almost no moderation when someone suggests to implement a new language. This means that someone can "hijack" a language simply by being the first who suggests it. This is exactly what was done with the Bantu functor and the Swahili language a coupe of months ago, see the following two issues:

        https://github.com/GrammaticalFramework/gf-rgl/issues/105
        https://github.com/GrammaticalFramework/gf-rgl/issues/106

The Bantu functor was a pull request that was directly adopted without any discussion, even though I know there are other people working on Bantu implementations. We need a more critical discussion when it comes to new languages, and in particular new functors.

(Note: I don't blame kitukb (the implementor) for issuing the PR, but there should have been a larger discussion on this list before accepting it)

2. Documentation: there is way too little documentation of the RGL, both for users and for implementors. I know that is's boring and tedious and difficult to get paid to do this, but it's really important if we want GF and the RGL to be used by more than a handful of people.

3. Finally, the structure of the RGL is difficult in itself. There are the "traditional" modules in 'abstract/' and 'your-language/', but then there are the "newer" ones in 'api/'. And in api, there are the Combinators, Constructors, Symbolic, Syntax and some more. It's not clear to me how they relate to each other or to the "traditional" modules. There is also the 'experimental/' and 'parametric/' modules, which I have no idea how they fit with the others.


I'm really impressed by the development of the RGL the last years, and now I think it has reached a level where we have to discuss how to ensure its quality in the future. In short: we need a roadmap, and this is a call for a discussion about this roadmap. Questions to be discussed:

- what should be the process for including new languages, and for making larger changes to existing languages?

I think we should continue to accept anything, but the quality of every language needs to be better shown. This relates a lot to point 4 below.

In the case of major updates, or rival implementations, the natural thing is for them to be discussed on this list (or a PR thread) and then let the repository owners decide whether to accept the PR.

 

- how can we improve the documentation? e.g., guidelines for implementing new languages, example use cases for all(most) RGL constructions

I don't disagree, but I don't have any ideas here. Maybe Aarne and Inari, who have implemented many languages and tutored many RG implementors have a better sense of what's needed.

Two other aspects of documentation:

- Instructions for how to document one's GF code so that it works with the RGL synopsis-generation, plus the notpresent flags

- Every language should at least have a README which describes how things work on a high level, the main contributors, etc.

 

- is there a need for cleaning up the RGL? now some language specific things are in 'your-language/' and some in 'api/'

Probably.

- should we add support for test cases? e.g., enforce RGL implementors to create a small corpus that can be tested automatically

We should absolutely have tests for all RGs, and be able to produce a table of the coverage/correctness of every RG wrt its test corpus. This will also help in making decisions about updates/rewrites as mentioned above. But testing isn't cool, academically, and no one has been motivated to take on this task. Can we make a student project out of it?

 

best,
Peter

--

---
You received this message because you are subscribed to a topic in the Google Groups "Grammatical Framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gf-dev/YWajYB5CcEg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gf-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aarne Ranta]

Hej Peter,

Thanks for raising these important issues! I agree with most things you say, and they have to do with the distinction between stable and experimental parts of the RGL. However, I still have the impression that using the stable part is easy enough and widely practiced: you import SyntaxLang and ParadigmsLang, and use the API documentation that covers them. This practice is described both in the GF book and in the online tutorial, and hasn't changed in the last 10 years.

The difficulties lie in knowing the exact limits of the stable part. This includes:

- knowing which languages are stable and reliable

- knowing what to do when Syntax and Paradigms are not sufficient for a project

What is needed is, as you say, better documentation and better discipline. 

The documentation was recently improved a bit in connection with the latest release, but there is more to be done, in particular  outside the stable part, but also inside it. For instance, some Paradigms files are very poorly documented. Since we want the documentation to be generated from the code, it is mainly up to the implementors to make sure the documentation is there. And I think we need better guidelines to support this.

Much of the discipline has to do with unfinished and experimental projects. I am myself guilty of this: for instance, I started in 2017 a project of creating ExtendLang modules as a more disciplined version of Extra modules, but didn't have time to carry it through to a really useful degree yet.

Since we want to keep the project open and collaborative, we want to continue allowing experimental work. But we should perhaps introduce more guidance: instead of just waiting for initiatives from developers, we could maintain a list of TODOs, where one could contribute and over the time slowly improve the resources. Some things that are high on my list include:

- smart paradigms for Bulgarian and Polish, perhaps for other languages as well

- Explanations of other paradigms as well

- further work on the Extend modules: exporting them to new languages and adding more things at need

- documentation of Extend 

- better support for automatic document generation, similar to haddock

- an updated (and hopefully automatically generated) Status document http://www.grammaticalframework.org/lib/doc/status.html to keep track of languages, developers, stages of development. Also to manage the program of hi-jacking languages.

And a special new thing, also high up:

- large monolingual morphological dictionaries in a predictable format. Just inflections and parts of speech, with predictable monolingual function names of form 'horse_N', 'cheval_N'. No attempt to cover word senses, subcategorizations, or translation equivalents, which are not hard facts in the way inflections are. In the projects I'm working on right now, I would need these every day, but have to realize that we don't have it

There's much more to say about these issues, so I welcome further discussion and contributions! And thanks for all the great contributions so far!

Regards

  Aarne.

 

--

---
You received this message because you are subscribed to the Google Groups "Grammatical Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gf-dev+un...@googlegroups.com.

[Aarne Ranta]

Thanks for your points, John! It seems we were both so eager to reply that we started writing immediately and in parallel. And also overlapped quite a bit, and didn't contradict each other.

Just a few more comments:

- The READMEs per language is a great idea. Clearly a mission for everyone who feels responsible for a language. It should contain concise practical information. But I would also love to read a bit of history, pointers to applications and publications, and so on. GitHub now gives us some of the later history, but does not reach very far.

- GitHub can also take care of some functions of the Status page, e.g. which people have contributed recently. If we are careful with the commit messages, GitHub history together with README would be a great documentation. 

- Test cases: the main one for me has been the set of RGL API phrases, plus the application grammars that have used the RGL. But now that we have Inari's gftest tool, one could generate more fine-grained and accurate test cases for all languages semiautomatically. This has already lead to substantial improvements, some documented in Inari's thesis. Another usage of the tool is to compare different versions of a grammar. Maybe we could develop this into a routine that has to be followed after each update of a resource grammar module?

  Aarne.

You received this message because you are subscribed to the Google Groups "Grammatical Framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gf-dev+un...@googlegroups.com.

[John J. Camilleri]

- The READMEs per language is a great idea. Clearly a mission for everyone who feels responsible for a language. It should contain concise practical information. But I would also love to read a bit of history, pointers to applications and publications, and so on. GitHub now gives us some of the later history, but does not reach very far.

See the issue for this here: https://github.com/GrammaticalFramework/gf-rgl/issues/120

John

[Tommi Nieminen]

Hi,

It would be best if you could take over the hosting and updating, since I can't really guarantee that the domain is going stay active. You can download all the auxiliary and data files by following the links from the source code of the map, it should be fairly self-explanatory. I can help, but I don't actually remember that much about the implementation.

-Tommi

Lähettäjä: Outlook

---

Lähettäjä: gf-...@googlegroups.com <gf-...@googlegroups.com> käyttäjän Inari <inari.l...@gmail.com> puolesta
Lähetetty: keskiviikko 2. tammikuuta 2019 8.32
Vastaanottaja: Grammatical Framework
Aihe: [GF] Re: RGL world map

 

--

[Peter Ljunglöf]

Thanks for your reactions!
I agree to most of your suggestions, however there are some points here and there.

> On Wed, Jan 2, 2019 at 12:05 PM John J. Camilleri <jo...@johnjcamilleri.com> wrote:
>

> I think we should continue to accept anything, but the quality of every language needs to be better shown.

This is self-contradictory, and one of the reasons I started this thread. Now that we have moved to Github I don't see a reason for automatically accepting anything, because anyone can develop their own RGL language in a fork of the main repo. That's the normal way of doing things in most software development projects on Github.

I would like some kind of quality threshold for including languages in the main repo. At least that there is good documentation, including README and comments that conform to our specifications (that we have to come up with), and test cases.

We should also have a real review process for including things in the repo, e.g. by discussing the PR thoroughly. And this process should be clear and transparent -- e.g., that at least two different persons have to review the PR, and/or that it has to have been advertised/discsused in the mailing list. Currently the decision order is very opaque -- even I don't know who has the right to accept PRs, and how acceptance/rejection is decided.

Another suggestion to make GF more "Github-friendly" is that all developers have their own personal fork, including the core ones (Aarne, John, Inari, etc). All development (except perhaps simple bug fixes) should be in the personal fork and then one can issues PRs when things are ready to dispatch.

(I opened a Github issue #117 about this)

> We should absolutely have tests for all RGs, and be able to produce a table of the coverage/correctness of every RG wrt its test corpus. This will also help in making decisions about updates/rewrites as mentioned above. But testing isn't cool, academically, and no one has been motivated to take on this task. Can we make a student project out of it?

I think we can start out simple: every language (starting with new ones) should have a small corpus with positive examples. The corpus can consist of lines of the following kind:

1. "jag sover i huset -- LangEng: I sleep in the house"
2. "huset är stort -- Lang: PhrUtt NoPConj (UttS (UseCl (TTAnt TPres ASimul) PPos (PredVP (DetCN (DetQuant DefArt NumSg) (UseN house_N)) (UseComp (CompAP (PositA big_A)))))) NoVoc"
3. "ibland sover jag inte"

Testing should be fairly easy, and can be done automatically (perhaps part of Travis CI?):

1. Translate the sentence into (LangEng) and test if any of the translations is the given one
2. Parse the sentence, and test if any of the parse trees is the given one
3. Parse the sentence

(I opened a new issue #118 about this)

> 2 jan. 2019 kl. 12:05 skrev Aarne Ranta <aa...@chalmers.se>:
>
> The difficulties lie in knowing the exact limits of the stable part. This includes:
> - knowing which languages are stable and reliable
> - knowing what to do when Syntax and Paradigms are not sufficient for a project
>
> What is needed is, as you say, better documentation and better discipline.

> (...)

>
> Much of the discipline has to do with unfinished and experimental projects. I am myself guilty of this: for instance, I started in 2017 a project of creating ExtendLang modules as a more disciplined version of Extra modules, but didn't have time to carry it through to a really useful degree yet.

Here's a concrete suggestion, that is in the spirit of Github: Why not moving the experimental parts to a fork? Alternatively to have them as a branch in the main repo.

So, how do we decide if something should be a branch in the main repo, or a fork of its own? Suggestion: if it's the work of one single person, then it should be a fork, but if several persons work on a feature together, then it can be a branch.

(The new issue #119 is about this)

> Since we want to keep the project open and collaborative, we want to continue allowing experimental work. But we should perhaps introduce more guidance: instead of just waiting for initiatives from developers, we could maintain a list of TODOs, where one could contribute and over the time slowly improve the resources.

Good idea, and why not make them issues? That's one of the reasons why we moved to Github...

best,
Peter