El dt 09 de 10 de 2012 a les 14:14 +0000, en/na Francis Tyers va escriure: > El dt 09 de 10 de 2012 a les 15:14 +0200, en/na [email protected] va > escriure: > > On Tue, Oct 09, 2012 at 09:41:41AM +0200, Per Tunedal wrote: > > > Hej Keld, > > > I liked your algo but had to think it over. After I've slept on, it a > > > few things got into my mind: > > > > > > "My initial go on an algorithm is then: I found a homonym. > > > Each of the homonyms have a placement in the meaning tree via its father > > > and mother relations." > > > > > > Unfortunately, I've no idea what's the father relation. Maybe you should > > > follow only the mother relations? > > > > The father relation is meant to discriminate between the same mother > > relations. > > So maybe it can be of help. I don't know. I take it into account to > > generalize > > wordnet-like structures, there may be more than one relation from a given > > homonym > > And a general Apertium wordnet module and algoritm should be able > > to handle more than one upwards relation, In the monodix markup > > this could be then marked with a "rel" tag, and more > > "rel" tags may be present. I need input from people more in the know if > > this could be > > the recommended way to mark up such meaning relations in the monodix. > > As a first pass, I would try adding semantic information in a new > module. It is the easiest way to not step on anyone's toes. If you make > something that works, and we have a language pair that can make use of > it, then we can see how to integrate it. > > > > "Each of the above terms in the trees will then be recorded with the > > > distance in links > > > to the specific homonym." > > > > > > Seems alright, so far. > > > > > > "If a term has been visited before then link count is modified > > > if the new link count is less - and also modified for all links above > > > this node." > > > > > > I don't understand this. > > > > there may be different paths from the homonym to a specific term. And one > > path > > would be shorter than another. if we find a path that is shorter than a > > previously found path, > > then the path to all terms above the found term would also be shorter, and > > thus the > > link count to those terms need to be adjusted too. > > I have no idea how this would work. > > > > Maybe there are other ways too. If you test your algo you might find a > > > pattern of links likely to be less fruitful than others. Or someone > > > might come up with a theoretical way to figure it out? > > > > yes, that is a possibility. Maybe the linguists here know more about such > > algos? > > See below. > > > > Maybe there are similar algos around for related applications, like > > > spell checking, statistical translation (tree model or even factored > > > translation, look at Moses), speech recognition or even artificial > > > intelligence? And you mentioned finding the shortest way. Someone might > > > have an idea of where to look for algos? There might be some open source > > > code to copy or be inspired by. > > http://ixa2.si.ehu.es/ukb/
You can google this paper too: Š. Vintar et. al. (2012) "Were the clocks striking or surprising? Using WSD to improve MT ..." Fran ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
