Replying to everything... Is there a possibility to apply SELECT also in any number of context > conditions (fixed and/or relative), something like > SELECT Det (1 Nominal SELECT) (2 Noun SELECT) ; >
Transactions / preconditions for groups of rules. Been thinking about something like that. Haven't figured out how hard it would be to implement, but it would certainly make a lot of scenarios easier to accomplish. * XML based format for rule syntax instead of the bracket stuff Additional alternative rule syntax is certainly on my wishlist as well. The current syntax borrowed and extended from CG-2 is really quite awful for the more complex tasks. Personally, I've wanted to add a Javascript based syntax, since a lot of people know JS these days. * better ways to ensure consistent tagging in and out the pipeline Such as what? This seems beyond the scope of CG. * gently nudge people to encode towards established standards like google > universal poses and stanford dependency tags No. That is absolutely beyond the scope of CG. * probably should output conll-u or whatever nowadays is easiest to evaluate > against the state of the art published stuffs Agreed. More I/O formats is always better. The problem is whether those formats can encode all features. Adding CoNLL-U to cg-conv looks easy enough. * sub-readings should define head per case Sub-readings are...currently special in the speshul way. Nobody yet really knows how they want them to work. * release a standard spec of what is CG-3 full with parsing grammar, test > suite and all A spec and proper manual is definitely needed. A test suite exists, though it should certainly be expanded. most of the work with cg I've needed to do so far is struggling with formatting > of tags and rewriting inputs and outputs to match hfst tags and apertium > stuffs, this is something that really should be done by computer... That's what cg-conv does - it converts between the various used stream formats. If cg-conv isn't doing it correctly, file a bug. google poses and dependencies are the standard of science now You can use both in CG today. You decide what tagset to use, and you can make labelled dependencies with CG named relations. downwards compatibility in the format. I basically won't ever promise that. I aim for not breaking the downwards compat, but when adding a feature it is usually impossible to add it in a downwards compatible way, and I don't want to feature freeze. Loading old grammars into newer CG-3, sure. Having older CG-3 load newer grammars...not guaranteed. it would be good to have an optional "strict" version of the formalism > where all tags used in the rules must be pre-defined in lists. That's a good idea and simple to implement. -- Tino Didriksen -- You received this message because you are subscribed to the Google Groups "Constraint Grammar" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/constraint-grammar. For more options, visit https://groups.google.com/d/optout.
