Experience Project iOS Android Apps | Download EP for your Mobile Device

Similar To My Other Post...

What if there was sometype of software development -library- where you had classes for and could instantiate various types of 'objects' representing different types of meanings for nouns, verbs, pluralization, etc, and then you could set properties on them to clarify things.  Like you got a cat, so you can set breed, and so this makes the system able to distinguish between housecat, tiger, etc... and since Cat is decendent form an Animal "class", you also have like a gender property, which defaults of course to "unknown" (as does pretty much every property)...  Then say you have another library containing a class called "EnglishTranslator" or whatever... And you feed a method of this object a linked list (probably some other more complicated "collection" object actually) of the above objects which mean some certain concept "together"... In the practical world this might be screen instructions on how to use some piece of software or I dunno, some error message or something...  And EnglishTranslator might implement an "inteface" called LanguageTranslator, of which there'd also be other decendant classes like "FrenchTranslator" that also implement this...  And these LanguageTranslator objects would be solely responsible for converting that string of objects into spoken text according to said grammar.  And perhaps there'd even a method in these objects to go the other way (from words into a set of general, language-independent software objects)....

lesshissMORECAT lesshissMORECAT 31-35 4 Responses Dec 28, 2009

Your Response


Of course going from meaning ob<x>jects to natural language is -a lot easier- than the reverse. This is because the meaning ob<x>jects 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.<br />
<br />
I dub this ob<x>ject 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 ob<x>ject/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 "ob<x>jects" with distinct meanings and a distinct set of properties/standard property values. Now these ob<x>jects/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-ob<x>ject" library would rely on similar linking and modifying notions (similar to adjective modifiers in spoken language) as well for such special cases.<br />
<br />
2) It is rediculous to assume that even if we had an ever-growing hardcoded library of "concept (meaning) ob<x>jects" that the authors of the various LanguageTranslator implementations would be willing to add more programmatic (class) code everytime we add new such ob<x>jects. What they'd probably realistically do is have xm<x>l 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 (ob<x>ject 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).<br />
<br />
3) For that matter, the generic language "meaning ob<x>jects" might actually themselves have xm<x>l code describing them. It's possible that an XSLT "stylesheet" could take an xm<x>l file describing such ob<x>jects, 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 ob<x>ject, the property names, and the list/range/meaning of acceptable property values.<br />
<br />
Really, the idea of a language-neutral "concept meaning ob<x>ject 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 ob<x>jects 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 "ob<x>ject meaning language".

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

And these "language-neutral" software ob<x>jects 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)...