On Fri, Dec 15, 2017 at 5:18 AM, Mindey I. <[email protected]> wrote:
> Linas, > > >> It would be easiest to work out some examples. Suppose your KR language >> has relations for "is-a", "has-part" -- these are two relations in WordNet. >> [...] But, in atomese, I can also write: >> >> EvaluationLink >> PredicateNode "has-similar-color" >> ListLink >> Variable "$X" >> Variable "$Y" >> >> Since WordNet does not have a "has similar color" relation, that's it, >> game over. >> > > There is a database (Wikidata), that stores common relations, https://www. > wikidata.org/wiki/Wikidata:List_of_properties/all , with their > multilingual definitions. > Atomese defines exactly zero of relations/properties. It allows the user to define as many a they want, as long as they fit into RAM. It provides tools for defining relations in terms of other relations; for example, there is a way to define "is an electrical part of a car" in terms of "part of", "electrical" and "car". Similarly, one can define "car" intensionally, as a concept that has wheels, a motor, etc. See https://wiki.opencog.org/w/EquivalenceLink In practice, we have dozens of relations that we use informally, on a regular basis: for example, a "Word" - but these are not formally defined - the Word is currently a "string of utf8 characters from a text sentence" but we might someday bend this definition in the future, to include spoken words, or words with inflections, phonemic markup, its not rigid, we hack as we go along. > > > >> or perhaps >> >> EvaluationLink >> PredicateNode "runs on hardware made from PowerPC" >> ListLink >> Concept "IBM Watson" >> >> which would evaluate to "true" or "probably true". >> > > In such scenario, the relation "runs on hardware made from PowerPC" would > also go to the compendium of relations, and the concept "IBM Watson", > actually, may have concept identifier. > Yes, and we have a formal syntax by which one can define "runs on hardware made from PowerPC" in terms of "PowerPC", "made from", "hardware" and "runs on". So there are two ways to create new relations: just write down a string of utf8 characters, from thin air, and don't explain what they mean, or provide a definition in terms of previous relations. See https://wiki.opencog.org/w/EquivalenceLink > > From what I understand, I could use atomese links like so: > > EvaluationLink > PredicateNode P1547 <https://www.wikidata.org/wiki/Property:P1547> > ListLink > Concept Q28817884 <https://www.wikidata.org/wiki/Q28817884> > We use this indented white-space style in emails, and in books (there are 3-4 books on atomese) and published papers. > > But I could use lisp, to say smth like: > > (EvaluationLink (List (PredicateNode P1547 > <https://www.wikidata.org/wiki/Property:P1547>) (ListLink (Concept > Q28817884 <https://www.wikidata.org/wiki/Q28817884>))) > > which would be equivalent, but less human-readable. > We have scheme bindings, which use the above form. We also have python, haskell and c++ bindings. If you think that the scheme bindings are not human-readable, then be aware that the python, haskell an c++ bindings are far worse. I suppose, the indentation syntax is part of atomese, > Atomese does not have a canonical syntax. It only has scheme, c++ python, haskell bindings, and if you want to create more, that's fine. There is no pre-defined way of writing it down. You can write it however you want to. > which makes it more human-readable. > > So, what remains that I wanted to know about "downloading" link > definitions, is -- what is the full list of definitions of the generic > symbols of atomese (like, *EvaluationLink, PredicateNode, ListLink, > Concept, Variable*, etc.) > These are not symbols, they are types. Types in the sense of type theory. https://wiki.opencog.org/w/Atom_types > with their definitions, > Almost all of the atom types are not "fundamental". See for example, the very bottom of https://wiki.opencog.org/w/Atom_types to see how new types can be defined, at least formally. However, we have not bothered to give most of the atom types any kind of formal definition. They are loosey goosey, and we create a dozen new ones every year, and retire/discard a dozen others. > and the additional syntax, > There is a mechanism for the definition of syntax. See for example, https://wiki.opencog.org/w/Type_constructor and https://wiki.opencog.org/w/DefinedTypeNode Most atoms do not have a well-defined syntax. None of them have a formal syntax definition. I have experimented with syntax definitions, they are used in the type checker, but the deployment of the type checker is very ad hoc. Anyway, very few people use any of the higher-order type constructors in practical code. There's very little interest in this. Defining a syntax for atomese is an ongoing area of research, but basically, almost no one, except for Nil and I, are interested in pursuing this, so it proceeds in a very ad-hoc fashion. > like the percent sign before the variables ($X). > That's a convention for human readability. you can use any utf8 string that you wish. > > Think of it this way: atomese is kind-of-like json, or kind-of-like >> javascript, or kind-of-like prolog or kind-of-like SQL -- it is a little >> bit like all of these. >> > > Yes, I see, and grounding the EvaluationLinks, makes it possible to > satisfy conditions defined in atomese. > > If your email asked: can I translate atomese into prolog, or atomese into >> javascript, I would have said, yes, sort-of-maybe with various >> difficulties. If you asked "can I translate prolog into atomese" or "can I >> translate javascript into atomese" I would have said "yes, with various >> difficulties". >> >> But instead you compared it to KIF and OpenCyc. Can random prolog or >> javascript programs be converted to KIF or OpenCyc? I don't think so, not >> in any normal sense. >> > > I see now, why. So, what I'd like to "download" so to speak, is the > definition of the metalanguage in a single document (e.g., in > model-theoretic sense, set of symbols and rules of language, with their > definitions), rather than translating it. > Can you download the definition of python in a single document, in a model-theoretic sense? What about prolog? or SQL or haskell or F# or C++ or javascript or scheme? That's actually an interesting question, and its been hotly discussed over the decades. See, for example, lambda-the-ultimate. Atomese is like a psychedelic mashup of F#, SQL and prolog. In principle, it could be self-describing; its a principle we are moving towards very very slowly, but its unlikely to happen any time soon. At any rate, the only "model theory" of atomese is written in C++, and its buggy, and changes every day. --linas > > Mindey > >> -- > -- *"The problem is not that artificial intelligence will get too smart and take over the world," computer scientist Pedro Domingos writes, "the problem is that it's too stupid and already has." * -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA36dHjT%3DAW9iN2BFrzHvRy%2BM0tVhNcH5aGtP-WqUzPckBA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
