[04:27:54] *** Joins: drbean (~drbean@TC210-63-209-56.static.apol.com.tw) [08:34:24] nice that it worked out! [08:34:38] and I agree, the gf module system can get confusing quickly [08:35:01] if your application is just monolingual, it's often much easier to skip all the weird stuff [08:39:18] sorry about silence, I honestly thought I'd have more time this week, but the two free evenings I had, first I had to do emergency graphical design for choir because the original person didn't have time, and then redo it because the original wasn't right :-P [09:34:40] *** Quits: daherb (~daherb@cse-principia.cse.chalmers.se) (*.net *.split) [09:38:15] *** Joins: daherb (~daherb@cse-principia.cse.chalmers.se) [10:55:12] *** Quits: daherb (~daherb@cse-principia.cse.chalmers.se) (*.net *.split) [10:55:13] *** Quits: freeside (~ubuntu@ec2-52-58-69-57.eu-central-1.compute.amazonaws.com) (*.net *.split) [10:55:14] *** Quits: drbean (~drbean@TC210-63-209-56.static.apol.com.tw) (*.net *.split) [10:55:21] *** Quits: inariksit (~inari@ksit.fixme.fi) (*.net *.split) [11:01:56] *** Joins: drbean (~drbean@TC210-63-209-56.static.apol.com.tw) [11:03:50] *** Joins: daherb (~daherb@cse-principia.cse.chalmers.se) [11:04:03] *** Joins: freeside (~ubuntu@ec2-52-58-69-57.eu-central-1.compute.amazonaws.com) [11:04:35] *** Joins: inariksit (~inari@ksit.fixme.fi) [12:31:18] no worries [12:31:44] "build one to throw away" has been good advice for so many areas of my life [12:31:57] it is a good lesson in Zen non-attachment [12:32:31] I wonder if I should just skip the resource modules and cram everything into the abstract/concretes [12:32:34] as you say [12:32:45] but will that make it super difficult later to go multilingual? [12:34:00] i noticed that all the mk* constructs that http://www.grammaticalframework.org/lib/doc/synopsis/index.html says are "Lexical category, constructors given in lexical paradigms" need to be defined in interface/instance, because they're not available to abstract/incomplete [12:34:15] is that generally true or should i be more diligent with my "open in"? [12:57:55] I'm now having a problem where I ... don't know enough grammar to confidently break down an NP into a bunch of N(CN) V NP elements. Is there some short-hand way for me to just define all the words and parts of speech as { s : Str } so I can get a basic parser working fast? [12:58:29] or is there some quick way for me to boot up a wide-coverage grammar and have GF do a parse of arbitrary input? [12:58:56] I remember doing something like that before. I will try to load up DictEng [13:28:35] <- < freeside> i noticed that all the mk* constructs that synopsis says are "Lexical category, constructors given in lexical paradigms" need to be defined in interface/instance, because they're not available to abstract/incomplete [13:28:44] yes, because they are language-dependent [13:29:28] e.g. french mkA needs {singular, plural}, {masculine, feminine} combinations, whereas english has no gender or number, but has comparative [13:29:45] such constructors don't make sense to define in a common abstract [13:30:50] on the other hand, something like mkAP of, say, AdA -> A -> AP, has the same type signature for all languages [13:31:30] you've already constructed the A in the language-specific constructors, and the higher-level operation, adding an AdA such as 'very' into an A such as 'warm', is abstract enough to be language-independent [14:11:21] gotcha [14:12:16] that's what i thought. but i still need a language-independent mkA in the abstract/concrete, so i ended up defining a mymkA = mkA in the language-specific resource module [14:12:22] is that a common pattern? it feels like a code smell. [14:13:08] in related news, taking your advice to skip past the interface/instance lexical modules, and just do it monolingually with abstract/concrete, i can report that i have more or less followed in the footsteps of https://pdfs.semanticscholar.org/7907/507cec8663e531d7cae924f01d71b546d3e5.pdf [14:13:20] do you know any of the authors? [14:32:18] haha yes, all of them [14:33:21] laurette was one of the organisers of the previous summer school and she was in the board of my phd defence, ramona was a postdoc when I started my phd but she left academia and works for microsoft now [14:33:40] jeroen was in this eu project that aarne had 2010-2013, I haven't heard of him since [14:33:50] and brian is one of the cnl people [14:34:16] what do you need a mymkA for? [14:35:47] or more like, what do you need a mkA for in the abstract? if its arguments are only strings or GF parameters (e.g. for "is premodifier/postmodifier"), it often shouldn't be in the abstract [14:55:27] i've got a lin function that builds my mkS out of smaller pieces, and one of those smaller pieces needs to be an A [14:56:46] it looks like there's active work happening in ontology verbalisation -- https://www.w3.org/2019/09/lexicog/ was just published in september [15:08:35] well, that's not exactly ontology verbalisation, but close enough, coming from RDF-world [15:28:58] okay, for example. suppose we look at a couple of utterances: "Who is?" "Bob is." How does one parse "Bob is" into a tree of Utt S Text ... ? [15:29:07] er, Utt Text S ... [15:29:13] it's some kind of Cl [15:30:40] so far i have MkText (mkS (mkCl (mkNP (mkPN "Bob")) (mkV ...)))) [15:31:06] can i pull some existing "to be" V out of some *Eng.gf so i don't have to roll my own? [16:01:36] yes, certainly! you can e.g. take LexiconEng, that's a small file [16:02:07] sorry nevermind, you wanted the verb to be and not just any verb [16:05:12] but yeah, DictEng has it for instance. you can always do restricted inheritance, e.g. MyGrammar = Foo, Bar, DictEng [be_V], Baz [16:06:16] (if you do that and find weird unification errors, here's a solution :-P https://inariksit.github.io/gf/2018/08/28/gf-gotchas.html#restricted-inheritance ) [16:12:33] btw, this could be interesting as well, since you're writing application grammars https://inariksit.github.io/gf/2019/02/17/beyond-API.html