Speaking as a language developer,¹ I prefer concise, textual tags. E.g., I don't think <surfaceform:hargle> is good—it clogs the stream with verbosity, as Fran points out.
On the other hand, I don't mind symbols here and there, like <§agent>. But I don't think this is a good secondary tag, unless we make it very explicit which unicode spans/classes can be used to define secondary tags. I don't like tags like <:human>, unless we are explicit about considering this a special way of encoding *semantic category* information in secondary tags. Fran, regarding these last two points, could you define what each symbol in your example tags stands for, and what range/class of symbols can continue to be used for secondary tags? ¹ Qualification: not one that's developed a released pair from start to finish, but that's mostly because my attention is too divided... I do have decent amounts of experience with the entire pipeline, though, and experience working on all pipeline stages in several individual pairs (including one approaching release / "in nursery"). -- Jonathan 8 may 2020, C. tarixində 14:02 tarixində Hèctor Alòs i Font <hectora...@gmail.com> yazdı: > > Missatge de Francis Tyers <fty...@prompsit.com> del dia dv., 8 de maig 2020 a > les 18:05: >> >> El 2020-05-08 15:50, Tino Didriksen escribió: >> > For khannatanmai's GSoC project, secondary tags will be implemented in >> > a backwards compatible manner. That it in itself indisputable. But, >> > there is a question of how the initial batch of secondary tags should >> > look. >> > >> > I feel they should be in the form of <sf:cdefg>, as in a very short >> > textual lower-case prefix, followed by :, followed by whatever value >> > there is. Or even an upper-case prefix, as in <S:cdefg> or <SF:cdefg>. >> > >> > spectie wants symbol prefixes in the form of <%:cdefg>. >> > >> >> [snip] >> >> > From a technical and scientific basis, textual prefixes are just >> > better. And yet, spectie wants symbol prefixes because he likes them. >> > I disagree. Hence, this mail asking for opinions. >> > >> > Do you language developers actually prefer symbol prefixes? >> > >> >> Tino misrepresented me slightly. I never proposed using the pound sign. >> >> My proposal was for: >> >> >> отец<n><sg><gen><@subj><§agent><%:отца><:human><:kin><!:aef31><!:fcd32> >> >> If we have to have these "secondary tags"... which I have yet to be >> completely convinced of, >> I would like to have them be readable and not clutter the stream with >> unnecessary >> verbosity. There are a lot of rule-based formalisms out there that are >> impossible to read, >> having been dreamt up by people who don't actually spend a lot of time >> writing language >> data, and I would like to avoid that happening with Apertium. > > > Well, from a developer's point of view, I'd like very much if I could get > information like "human", "construction", "denonym", "material", "musical > instrument", etc. which I have to use for lexical selection and also > sometimes for transfer. It seems logical to me that this data would be some > day placed in the dictionary or in a kind of secondary dictionary. In fact > the trend is already to add more semantic information to words: for example > in proper names we now often distinguish between first names, surnames, place > names, hidronyms, etc. > > Personally, I don't have any preference in the syntax. I'm fine with any > method that is short, easy to type on any keyboard and that identifies a tag > as secondary. > > Hèctor > > >> >> Again, and again I want to see a translation and a linguistic >> motivation. In an _actual_ >> language pair, not in someone's imagination. >> >> We have a lot of modules that have been made but not reached use in a >> released pair, >> so I don't see how this should be different. >> >> Fran >> >> >> >> >> >> _______________________________________________ >> Apertium-stuff mailing list >> Apertium-stuff@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/apertium-stuff > > _______________________________________________ > Apertium-stuff mailing list > Apertium-stuff@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/apertium-stuff _______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
