#6 Development status

[ram]

I open this ticket because I want to know the status of this project in order to see how to get involve.

I work as independent contractor for the Mexican Academy of Language. Part of my job is the development and maintenance of a Contemporary Spanish Corpus. For this, we decided to use CWB thanks to the recommendation of the North American Academy of the Spanish Language.

But our user and admin experiences have been rocky. Part of this is because we are learning about the technicalities required for this kind of projects, another part is because we had difficulties to understand the documentation available in the official webpage. After review several examples, another repositories and papers, we were able to fill some gaps in our understanding.

At the moment, our course of action would be the development of a web platform with Django. Unfortunately, we don't use PHP in our developments, so we haven't been able to modify CQPweb for our requirements. That is why we decided to try a different approach by developing a web platform with Python.

So, part of our interest it to know the status and the focus of the following developments:

1. Status of CWB
2. Status Ziggurat (great paper, btw)
3. Status of CQPweb
4. Status of CWB/Perl
5. Status of CQi (which according to this ticket, is currently inactive)

This information could help us to know what to prioritize in our own development. But also, it would help us to know which kind of Spanish documentation we should make (we decided to document our experiences in our MediaWiki so other people or institutions can benefit from our work).

Thank you for all the attention, specially to @schtepf.

[Andrew Hardie]

1. Status of CWB -- v3.5 is feature complete, actively maintained.
2. Status Ziggurat (great paper, btw) -- under active development, in early stages (thank you)
3. Status of CQPweb -- under active development, v3.2 branch is stable, 3.3. is where new features are added.
4. Status of CWB/Perl -- v3.5 is feature complete, actively maintained.
5. Status of CQi -- as Stephanie noted on the other ticket, not being developed further due to apparent lack of need, but actively maintained.

A note re "active development" -- active does not mean fast, since neither me nor Stephanie nor anybody else has a whole lot of free time to devote to the project (we're both full-time academics with many other calls on our time). "Actively maintained" means that all reported bugs are fixed as soon as we can (and that normally doesn't take very long).

Also, this sort of discussion normally happens on the mailing list rather in tickets ; I'd recommend that you join in any case.

http://devel.sslmit.unibo.it/mailman/listinfo/cwb

best

Andrew

[ram]

Thanks for the response. We don't have any hurry since we are probably going slower than these developments!

I will joint to the mailing list, thanks.

[Andrew Hardie]

Unfortunately, we don't use PHP in our developments, so we haven't been able to modify CQPweb for our requirements.

Have you considered using the CQPweb API as a back-end? It's higher-level than interacting directly with CQP. On the other hand it's not finished, but I'd be willing to prioritise which bits get attention on the basis ofyour needs.

[ram]

Well, we are considering cwb-ccc since it is also in Python, would you recommend CQPweb API over cwb-ccc for our use case (Django development)?

[Stephanie Evert]

cwb-ccc should give you most (if not all) of what you can get from the CQPweb API, and it will be faster (as everything is directly in Python and doesn't need to be serialised and de-serialised) and more directly under your control. I think CQPweb is useful for your use case only if you need its GUI.

[Andrew Hardie]

This is one of those rare occasions when I have to disagree with Stephanie - there are some things you can get from CQPweb via API that direct CWB access won't get you: collocations, distribution, linking queries to text or item metadata (and getting same in results...), user accounts, query history, case-folded frequency lists, saved and categorised queries, character set standardisation, ...

See https://sourceforge.net/p/cwb/code/HEAD/tree/gui/cqpweb/trunk/lib/api-lib.php for where I'm at so far. Functions commented out aren't implemented. Functions not commented exist and work but may contain bugs.

API client object libraries exist for various languages in assorted stages of completion (to save assembling the GET requests manually). The Python one is not much more than a stub at present; the PHP and JavaScript ones are rather more complete. All the client objects are meant to implement as close to the same interface as manageable. See https://sourceforge.net/p/cwb/code/HEAD/tree/gui/cqpweb-client/trunk/

I should add that the whole idea of the API is to allow people to implement GUIS according to their own preferences in terms of user interface, etc., while offloading the "guts" of the program - i.e. the actual code that grubs around with databases, CQP syntax etc. onto a CQPweb server in the backend. Pretty much exactly your use case, thus why I'd be happy to prioritise your needs, since then I would have a user helping to find bugs.

[ram]

Thanks for the response. I checked the api-lib.php because some days ago I tried to use the run_query function that in my current version is not implemented, but I see that right now it is implemented.

I am going to report all this info, and since we stopped having issues with CQPweb, with my team we are going to see if we actually have to implement a whole new web platform with Django, or if we better work on a nice minimalist template for CQPweb.

Thanks!