Similar To My Other Post...

Of course going from meaning objects to natural language is -a lot easier- than the reverse. This is because the meaning objects contain -the actual meaning-. Only -natural language- (e.g. French, English, German, or any other) gets potentially ambiguous. Maybe what she'd have to do when going that way is return an -array- of all the likely combinations when translating an ambigous sentence, and the "though processor" or whatever app this is being furnished to would use what she knows about -the actual context- to "throw out" interpretations that obviously do not apply for any potentially ambiguous sentence.



I dub this object library idea with the name "Rachel". The original Rachel idea was to have this be a "language independent" -textual- language for describing concepts, but the object/class library is simply just better because these puppies are gonna need to be processed at highspeed by a computer and few people will ever see the raw Rachel representations anyway (so doesn't need to be "pretty for the people"-- and we can have like a way to dump them out on debug reports of course...)

1) Most things in life are generally "understood". "Running" is a general understood concept when it comes to say mammals for example. "Cat" is a generally understood concept. They all have fur and four legs. Now they don't all meow and they don't all have tails. Therefore it's conceivable that some languages may have special words which distinuguish these types of cats... It conceivable that most things in life could be boiled down to "objects" with distinct meanings and a distinct set of properties/standard property values. Now these objects/property sets would only represent "common cases". You would not have a property for number of legs on a cat cause though three-legged cats unfortunately do exist, they are fortunately not a common case. Therefore most spoken languages simply have additional adjectives you can add to depict such a notion. This "meaning-object" library would rely on similar linking and modifying notions (similar to adjective modifiers in spoken language) as well for such special cases.



2) It is rediculous to assume that even if we had an ever-growing hardcoded library of "concept (meaning) objects" that the authors of the various LanguageTranslator implementations would be willing to add more programmatic (class) code everytime we add new such objects. What they'd probably realistically do is have xml input files (or databases) to tell their implementation what words correspond to what class names/property values (and the formats for these might well probably vary depending on which human language the translator was for-- which wouldn't be a problem). Due to a feature in Java called "reflection", software doesn't need to be aware of all classes (object types) a program will ever encounter or use "at runtime" at the time a software program is built for shipment (or even before is shipped).



3) For that matter, the generic language "meaning objects" might actually themselves have xml code describing them. It's possible that an XSLT "stylesheet" could take an xml file describing such objects, their properties, and their property values and use this information to actually generate the source code these corresponding Java .class files are compiled from. It's just that every translator implementation would have to agree on each class name, the "universal meaning" of that object, the property names, and the list/range/meaning of acceptable property values.



Really, the idea of a language-neutral "concept meaning object library" that can then be translated to any human language isn't "the unwieldly concept" that this sounds like at first. What gets unweildly is making a machine use these objects to actually 'think', but then maybe some very basic/primitive concepts are defined (e.g. walking, sound, and similar basic ideas) in actual "hard code" and everything else is simply defined as a sort of "Webster's(R) dictionary" of sorts written in terms of the rest of the "object meaning language".

LOL! I'm surprised there isn't a Sun Microsystems Java API for this already :-D

And these "language-neutral" software objects could of course be more easily processed in a simulated brain of sorts than say -words- would :-) cause no ambiguous meanings, etc (e.g. no words like "lift" or "car" which can actually mean different things depending on context)...