On 21 Dec 2010, at 10:42, Francis Tyers <fty...@prompsit.com> wrote: > Hi! > > The problem with this is that there are so many different metadix > formats that it will be impossible to come up with one that covers > them > all. For example if I remember correctly how the "alt" works is > different in es-pt and in oc-es. I think it was decided that it was > desirable to have them functioning differently, or at least would > require substantial changes in either language pair to get a unified > format -- changes that without some push (and let's face it, cash) are > not going to get made.
Nah. Majority rules. There's one dominant flavour of 'alt', that one wins; the other can still be transformed in exactly the same way as it is currently without anything being lost, so where's the problem? 'alt' and 'v' are relatively easy - they're not much different to 'r' (though the 'r'-ness would have to be taken into account, which can get confusing). That much could be done by a GCI student. The slightly difficult parts are prm and sa, and I'd really rather see those be extended to a templating mechanism, but haven't been able to find a way of specifying the parameters that isn't worse to use than just copying a modifying pardefs manually. > On the other hand, implementing compound words gives us the chance to > strike while the iron is hot! We can make a (fairly innocuous change > -- > any language pair that does not have compounding will be unaffected) > before getting a plethora of different options and thus avoiding the > metadix problem for another set of issues. > > Btw, thinking about metadix I have some probably unpopular ideas, > thatwould preclude any standardisation. I think that maybe we should > not > have one format, but rather many _codified_ formats depending on the > language(group). For example how to include a verb would be > different in > Tajik and Dutch, because different things are important. Unnecessary > examples: > See, the difference is that metadix is a generic set of extensions, while you describe a set of language specific extensions. Not that there's anything wrong with that (other than that it creates a situation where existing knowledge of dix files is less transferable, which is not a major obstacle) - you're just not talking about metadix, don't mix up the issues. Both of your examples seem to be predicated on magic happening - pulling secondary paradigm names from the ether. You'd either need to have hard coded values in the transformation process, or a set of forward declarations that define the mappings. Go for the latter, that would involve less name calling on my part. > <e lm="aanzitten"><par n="z/itten__vblex" prefix="aan" > pp="aangezeten"/></e> > > Giving: > > <e lm="aanzitten"><i>aanz</i><par n="aanz/itten__vblex_sep"/></e> > <e lm="aanzitten"><p><l>z</l><r>aanz</r></p><par > n="z/itten#_aan__vblex_sep"/><p><l><b/>aan</l><r></r></p></e> > <e lm="aanzitten"><p><l>aangezeten</l><r>aanzitten</r></p><par > n="gesproken__vblex_sep"/></e> > > Or in Tajik: > > <e lm="харидан"><par n="кард/ан__vblex" stem1="харид" stem2="хар"/>< > /e> > > Which would give (after transformation) something like: > > <e lm="харидан"><p><l>харид</l><r>харидан<s n="vblex"/></r></p><par > n="кард/ан__vblex"/></e> > <e lm="харидан"><p><l>хар</l><r>харидан<s n="vblex"/><s > n="prs"/></r></p><par n="к/ард.ан__vblex"/></e> > <e lm="харидан"><p><l>нахар</l><r>харидан<s n="vblex"/><s > n="neg"/><s n="prs"/></r></p><par n="к/ард.ан__vblex"/></e> > <e lm="харидан"><p><l>нахарид</l><r>харидан<s n="vblex"/><s > n="neg"/></r></p><par n="кард/ан__vblex"/></e> > <e lm="харидан"><p><l>мехарид</l><r>харидан<s > n="vblex"/></r></p><par n="ме.кард/ан__vblex"/></e> > <e lm="харидан"><p><l>мехар</l><r>харидан<s n="vblex"/><s > n="pri"/></r></p><par n="к/ард.ан__vblex"/></e> > <e lm="харидан"><p><l>намехарид</l><r>харидан<s n="vblex"/><s > n="neg"/></r></p><par n="кард/ан__vblex"/></e> > <e lm="харидан"><p><l>намехар</l><r>харидан<s n="vblex"/><s > n="neg"/><s n="pri"/></r></p><par n="к/ард.ан__vblex"/></e> > > Fran > > PS. Wasn't the election to be organised by Unhammer, Pasquale and > Nic ? > > El dt 21 de 12 de 2010 a les 06:31 +0100, en/na Mikel Forcada va > escriure: >> Hi Apertiumers, >> >> Before any more patches to the dictionary format are made, a general >> agreement should be reached. Remember that we have different >> dialects of >> metadix and an unification would be desirable before fiddling anymore >> with dictionary formats.... >> >> Mikel L. Forcada >> >> P.S. By the way, as the mandate of the current Project Management >> Committee has long expired and we haven't been able to run a proper >> election, I understand I could stage a coup d'etat, put on my BDFL >> cap, >> and word the above as a command instead of as an opinion. I'm >> tempted... >> anyone interested in >> >> On 12/19/2010 09:57 PM, Francis Tyers wrote: >>> El dg 19 de 12 de 2010 a les 18:28 +0000, en/na Jimmy O'Regan va >>> escriure: >>>> On 19 Dec 2010, at 17:39, Francis Tyers<fty...@prompsit.com> >>>> wrote: >>>> >>>> >>>>> It would be nice to get this done before Christmas, are there any >>>>> comments ? >>>> It would probably be best to use a character other than '+'. In the >>>> event of the final part of the compound being analysed as a >>>> multword >>>> with inner inflection, the queue will be attached to the first >>>> part of >>>> the compound. As you're talking about a syntax change anyway, is >>>> there >>>> any reason to not insert the break directly? >>> I guess we could use '~' and then change pretransfer.cc to output >>> $^ for >>> '~' instead of '$ ^' for '+'... >>> >>> Anything else ? >>> >>> Fran >>> >>> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>> Lotusphere 2011 >>> Register now for Lotusphere 2011 and learn how >>> to connect the dots, take your collaborative environment >>> to the next level, and enter the era of Social Business. >>> http://p.sf.net/sfu/lotusphere-d2d >>> _______________________________________________ >>> Apertium-stuff mailing list >>> Apertium-stuff@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff >> >> > > > > --- > --- > --- > --------------------------------------------------------------------- > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Apertium-stuff mailing list > Apertium-stuff@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/apertium-stuff ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
