hedayat / link-grammar Goto Github PK
View Code? Open in Web Editor NEWThis project forked from opencog/link-grammar
The CMU Link Grammar natural language parser
License: GNU Lesser General Public License v2.1
This project forked from opencog/link-grammar
The CMU Link Grammar natural language parser
License: GNU Lesser General Public License v2.1
Link Grammar Parser ------------------- Version 5.3.4 The Link Grammar Parser implements the Sleator/Temperley/Lafferty theory of natural language parsing. This version of the parser is an extended, expanded version of the last official CMU release, and includes many enhancements and fixes created by many different developers. This code is released under the LGPL license, making it freely available for both private and commercial use, with few restrictions. The terms of the license are given in the LICENSE file included with this software. Please see the web page http://www.abisource.com/projects/link-grammar/ for more information. This version is a continuation of the original parser posted at http://www.link.cs.cmu.edu/link CONTENTS of this directory: --------------------------- LICENSE The license describing terms of use link-grammar/*.c The program. (Written in ANSI-C) link-grammar/corpus/*.c Optional corpus statistics database. link-grammar/minisat/* Optional SAT Solver. (Written in C++) link-grammar/sat-solver Optional SAT Solver. (Written in C++) link-grammar/viterbi Experimental Viterbi algorithm parser. bindings/autoit/* Optional AutoIt language bindings. bindings/java/* Optional Java language bindings. bindings/lisp/* Optional Common Lisp language bindings. bindings/ocaml/* Optional OCaML language bindings. bindings/python/* Optional Python language bindings. bindings/swig/* SWIG interface file, for other FFI interfaces. data/en/* English language dictionaries. data/en/4.0.dict The file containing the dictionary definitions. data/en/4.0.knowledge The post-processing knowledge file. data/en/4.0.constituents The constituent knowledge file. data/en/4.0.affix The affix (prefix/suffix) file. data/en/4.0.regex Regular expression-based morphology guesser. data/en/tiny.dict A small example dictionary. data/en/words/* A directory full of word lists. data/en/4.0*.batch These files contain sentences (both grammatical and ungrammatical ones) that are used for testing the link-parser These can be run through the parser with the command "./link-parser < 4.0.*.batch" data/ru/* A full-fledged Russian dictionary data/ar/* An Arabic dictionary data/fa/* A Persian (Farsi) dictionary data/de/* A small prototype German dictionary data/lt/* A small prototype Lithuanian dictionary data/id/* A small prototype Indonesian dictionary data/he/* An experimental Hebrew dictionary data/tr/* An experimental Turkish dictionary morphology/ar An Arabic morphology analyzer morphology/fa An Persian morphology analyzer COPYING The license for this code and data ChangeLog A compendium of recent changes. configure The GNU configuration script autogen.sh Developer's configure maintenance tool msvc9, msvc12 Microsoft Visual-C project files UNPACKING and signature verification: ------------------------------------- The system is distributed using the normal tar.gz format; it can be extracted using the "tar -zxf link-grammar.tar.gz" command at the command line. The files have been digitally signed to make sure that there was no corruption of the dataset during download, and to help ensure that no malicious changes were made to the code internals by third parties. The signatures can be checked with the gpg command: gpg --verify link-grammar-5.3.4.tar.gz.asc which should generate output identical to (except for the date): gpg: Signature made Thu 26 Apr 2012 12:45:31 PM CDT using RSA key ID E0C0651C gpg: Good signature from "Linas Vepstas (Hexagon Architecture Patches) <[email protected]>" gpg: aka "Linas Vepstas (LKML) <[email protected]>" Alternately, the md5 check-sums can be verified. These do not provide cryptographic security, but they can detect simple corruption. To verify the check-sums, issue "md5sum -c MD5SUM" at the command line. CREATING the system: -------------------- To compile the link-grammar shared library and demonstration program, at the command line, type: ./configure make To install, change user to "root" and say make install ldconfig This will install the liblink-grammar.so library into /usr/local/lib, the header files in /usr/local/include/link-grammar, and the dictionaries into /usr/local/share/link-grammar. Running 'ldconfig' will rebuild the shared library cache. Editline -------- If libedit-dev is installed, then the arrow keys can be used to edit the input to the link-parser tool; the up and down arrow keys will recall previous entries. You want this; it makes testing and editing much easier. Note, however, most versions of editline are not UTF8-capable, and so won't work, for example, with the Russian dictionaries. A UTF8-enabled version of libedit can be found here: http://www.thrysoee.dk/editline/ If you use the above, be sure to say: ./configure --enable-widec when building it, otherwise you won't actually get the UTF8 support! Attention: the above configure is for libedit, not for link-grammar! (In addition, you will need to uninstall the system default editline in order to get the above. You may also need to set the environment variable PKG_CONFIG_PATH to include /usr/local/lib/pkgconfig) Use of editline in the link-parser can be disabled by saying: ./configure --disable-editline Note: utf8 support for libedit is still missing in Ubuntu 1404 and Mint 17 Qiana See https://bugs.launchpad.net/linuxmint/+bug/1389438 https://bugs.launchpad.net/ubuntu/+source/libedit/+bug/1375921 Java Bindings ------------- By default, the Makefiles attempt to build the Java bindings. The use of the Java bindings is *OPTIONAL*; you do not need these if you do not plan to use link-grammar with Java. You can skip building the Java bindings by disabling as follows: ./configure --disable-java-bindings If JAVA_HOME isn't set, if jni.h isn't found, or if ant isn't found, then the java bindings will not be built. Python Bindings --------------------- The python bindings are NOT built by default. To enable this, run configure as follows: ./configure --enable-python-bindings The use of the Python bindings is *OPTIONAL*; you do not need these if you do not plan to use link-grammar with python. If you do enable the python bindings, be sure to install the python-devel package. The linkgrammar.py module provides a high-level interface in Python. The example.py script provides a demo. and tests.py runs unit tests. Install location ---------------- The /usr/local install target can be over-ridden using the standard GNU configure --prefix option, so for example: ./configure --prefix=/opt/link-grammar By using pkg-config (see below), non-standard install locations can be automatically detected. Configure help -------------- Additional config options are printed by ./configure --help The system has been tested and works well on 32 and 64-bit Linux systems, FreeBSD, MacOSX, as well as on many Microsoft Windows systems, under various different Windows development environments. Specific OS-dependent notes follow. BUILDING on MacOS: ------------------ Plain-vanilla Link Grammar should compile and run on Apple MacOSX just fine, as described above. At this time, there are no reported issues. The language bindings for python and java may require additional packages to be installed. A working editline is nice, since it allows you to use the arrow keys in the command-lne client. See http://www.macports.org/ to find these. You almost surely do not need a Mac portfile; but you can still find one here: http://trac.macports.org/browser/trunk/dports/textproc/link-grammar/Portfile It does not currently specify any additional steps to perform. If you do NOT need the java bindings, you should almost surely configure with ./configure --disable-java-bindings By default, java requires a 64-bit binary, and not all MacOS systems have a 64-bit devel environment installed. If you do want Java bindings, be sure to set the JDK_HOME environment variable to wherever <Headers/jni.h> is. Set the JAVA_HOME variable to the location of the java compiler. Make sure you have ant installed. BUILDING on Windows ------------------- There are three different ways in which link-grammar can be compiled on Windows. One way is to use Cygwin, which provides a Linux compatibility layer for Windows. Unfortunately, the Cygwin system is not compatible with Java for Windows. Another way is use the MSVC system. A third way is to use the MinGW system, which uses the Gnu toolset to compile windows programs. Link-grammar requires a working version of POSIX-standard regex libraries. Since these are not provided by Microsoft, a copy must be obtained elsewhere. One popular choice is TRE, available at: http://laurikari.net/tre/ Another popular choice is PCRE, 'Perl-Compatible Regular Expressions', available at: http://www.pcre.org/ Recent 32 and 64-bit binaries can be found at: http://www.airesoft.co.uk/pcre Older 32-bit binaries are at: http://gnuwin32.sourceforge.net/packages/regex.htm See also: http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/regex.README By default, the library is configured to create a DLL. If you want to instead build a static library, the macro LINK_GRAMMAR_STATIC must be defined before the inclusion of any header files for both the compiling of the link-grammar library and for the application that uses it. Other compiler settings will also have to be changed to create a static library of course. The different build methods below are NOT regularly tested, and some link-grammar versions may have build issues. If you are an experienced Windows developer who knows how to make things work in the Microsoft environment, your help would be appreciated! BUILDING on Windows (Cygwin) ---------------------------- The easiest way to have link-grammar working on MS Windows is to use Cygwin, a Linux-like environment for Windows making it possible to port software running on POSIX systems to Windows. Download and install Cygwin from http://www.cygwin.com/ Unfortunately, the Cygwin system is not compatible with Java, so if you need the Java bindings, you must use MSVC or MinGW, below. BUILDING on Windows (MinGW) --------------------------- Another way to build link-grammar is to use the MinGW/MSYS, which uses the Gnu toolset to compile Windows programs for Windows. This is probably the easiest way to obtain workable Java bindings for Windows. Download and install MinGW, MSYS and MSYS-DTK from http://mingw.org. Then build and install link-grammar with ./configure make make install If you used the standard installation paths, the directory /usr/ is mapped to C:\msys\1.0, so after 'make install', the libraries and executable will be found at C:\msys\1.0\local\bin and the dictionary files at C:\msys\1.0\local\share\link-grammar. In order to use the Java bindings you'll need to build two extra DLLs, by running the following commands from the link-grammar base directory: cd link-grammar gcc -g -shared -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at \ .libs/analyze-linkage.o .libs/and.o .libs/api.o \ .libs/build-disjuncts.o .libs/constituents.o \ .libs/count.o .libs/disjuncts.o .libs/disjunct-utils.o \ .libs/error.o .libs/expand.o .libs/extract-links.o \ .libs/fast-match.o .libs/idiom.o .libs/massage.o \ .libs/post-process.o .libs/pp_knowledge.o .libs/pp_lexer.o \ .libs/pp_linkset.o .libs/prefix.o .libs/preparation.o \ .libs/print-util.o .libs/print.o .libs/prune.o \ .libs/read-dict.o .libs/read-regex.o .libs/regex-morph.o \ .libs/resources.o .libs/spellcheck-aspell.o \ .libs/spellcheck-hun.o .libs/string-set.o .libs/tokenize.o \ .libs/utilities.o .libs/word-file.o .libs/word-utils.o \ -o /usr/local/bin/link-grammar.dll gcc -g -shared -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at \ .libs/jni-client.o /usr/local/bin/link-grammar.dll \ -o /usr/local/bin/link-grammar-java.dll This will create link-grammar.dll and link-grammar-java.dll in the directory c:\msys\1.0\local\bin . These files, together with link-grammar-*.jar, will be used by Java programs. Make sure that this directory is in the %PATH setting, as otherwise, the DLL's will not be found. BUILDING on Windows (MSVC) -------------------------- Microsoft Visual C/C++ project files can be found in the msvc12 and msvc9 directories. MSVC6 build files are also provided; however, this compiler is deprecated due to the lack of locale support. In particular, the Russian dictionaries cannot work with MSVC6! Please note that the regex package, which includes libraries and header files, must be separately downloaded and installed, as described above. The MSVC project files *MUST* be modified to indicate the correct location of the regex libraries. The build files make use of two environment variables, GNUREGEX and JAVA_HOME. -- GNUREGEX must be pointing to an unzipped gnuwin32-regex distribution. -- JAVA_HOME must be pointing to a locally installed JDK. Those two can be set either as system environment variables (Windows users are supposed to know how to do this :) or as MSVC12/MSVC9 user macros. But just in case you don't, here's how: 1) Start > Control Panel > System (Remember, in Vista or Windows 7, you need to switch to "Classic View" or "Large icons", respectively to see the System icon). 2) "Advanced system settings" (or "Advanced" tab under XP) 3) On all versions you will see a button with the caption "Environment Variables", press it.... (ALL REMAINING STEPS CORRELATE ON XP, VISTA, AND 7) 4) You now see two lists of environment variables... the top one says "User variables for <yourusernamehere>" and is localized to your user account, the other says "System variables" and applies to ALL user accounts on that computer. 5) Press the "New ..." button corresponding to whether or not you want the variables to be valid on ALL accounts or just your own (either way the following steps remain the same) 6) In the "Variable name:" box, enter "GNUREGEX". 7) In the "Variable value" box, enter the path to your installation of GNUREGEX (on my system this is "C:\Program Files (x86)\GnuWin32" as I am on Windows 7 Ultimate x64) then press "OK" 8) Press the same "New ..." button and this time in the "Variable name" box enter "JAVA_HOME", and in the "Variable value" box enter the path to your Java SDK root folder. (IMPORTANT NOTE: On some systems this variable may already be defined automatically by the JAVA SDK installation! You should check the variables lists before creating a new one to avoid any conflict). 9) Press "OK" and close all Windows opened during the above steps. If you were running MSVC++ or your chosen development environment whilst performing the above steps, you should restart it! Once restarted you should be able to build the latest version of the code. RUNNING the program: -------------------- To run the program issue the Unix command: ./link-parser This starts the program. The program has many user-settable variables and options. These can be displayed by entering !var at the link-parser prompt. Entering !help will display some additional commands. The dictionaries contain some utf-8 punctuation. These may generate errors for users in a non-utf-8 locale, such as the "C" locale. The locale can be set, for example, by saying export LANG=en_US.UTF-8 at the shell prompt. By default, the parser will use dictionaries at the installed location (typically in /usr/local/share). Other locations can be specified on the command line; for example: link-parser ../path/to-my/modified/data/en When accessing dictionaries in non-standard locations, the standard file-names are still assumed (i.e. 4.0.dict, 4.0.affix, etc.) The Russian dictionaries are in data/ru. Thus, the Russian parser can be started as: link-parser data/ru If you see errors similar to this: Warning: The word "encyclop" found near line 252 of en/4.0.dict matches the following words: encyclop This word will be ignored. then your UTF-8 locales are either not installed or not configured. The shell command `locale -a` should list en_US.utf8 as a locale. If not, then you need to `dpkg-reconfigure locales` and/or run `update-locale` or possibly `apt-get install locales`, or combinations or variants of these, depending on your operating system. TESTING the program: -------------------- The program can run in batch mode for testing the system on a large number of sentences. The following command runs the parser on a file called 4.0.batch ./link-parser < 4.0.batch The line "!batch" near the top of 4.0.batch turns on batch mode. In this mode sentences labeled with an initial "*" should be rejected and those not starting with a "*" should be accepted. The current batch file does report some errors, as do the files "4.0.biolg.batch" and "4.0.fixes.batch". Work is ongoing to fix these. The "4.0.fixes.batch" file contains many thousands of sentences that have been fixed since the original 4.1 release of link-grammar. The "4.0.biolg.batch" contains biology/medical-text sentences from the BioLG project. The following numbers are subject to change, but, at this time, the number of errors one can expect to observe in each of these files are as follows: en/4.0.batch: 61 errors en/4.0.fixes.batch: 401 errors lt/4.0.batch: 17 errors ru/4.0.batch: 31 errors The bindings/python directory contains a unit test for the python bindings. It also performs several basic checks that stress the link-grammar libraries. USING the parser in your own applications: ------------------------------------------ There is an API (application program interface) to the parser. This makes it easy to incorporate it into your own applications. The API is documented on the web site. USING CMake: ------------ The FindLinkGrammar.cmake file can be used to test for and set up compilation in CMake-based build environments. USING pkg-config: ----------------- To make compiling and linking easier, the current release uses the pkg-config system. To determine the location of the link-grammar header files, say `pkg-config --cflags link-grammar` To obtain the location of the libraries, say `pkg-config --libs link-grammar` Thus, for example, a typical makefile might include the targets: .c.o: cc -O2 -g -Wall -c $< `pkg-config --cflags link-grammar` $(EXE): $(OBJS) cc -g -o $@ $^ `pkg-config --libs link-grammar` JAVA bindings: -------------- This release includes Java bindings. Their use is optional. The bindings will be built automatically if jni.h can be found. Some common java JVM distributions (most notably, the ones from Sun) place this file in unusual locations, where it cannot be automatically found. To remedy this, make sure that JAVA_HOME is set. The configure script looks for jni.h in $JAVA_HOME/Headers and in $JAVA_HOME/include; it also examines corresponding locations for $JDK_HOME. If jni.h still cannot be found, specify the location with the CPPFLAGS variable: so, for example, export CPPFLAGS="-I/opt/jdk1.5/include/:/opt/jdk1.5/include/linux" or export CPPFLAGS="-I/c/java/jdk1.6.0/include/ -I/c/java/jdk1.6.0/include/win32/" Please note that the use of /opt is non-standard, and most system tools will fail to find packages installed there. The building of the Java bindings can be disabled by configuring as below: ./configure --disable-java-bindings Using JAVA ---------- This release provides java files that offer three ways of accessing the parser. The simplest way is to use the org.linkgrammar.LinkGrammar class; this provides a very simple Java API to the parser. The second possibility is to use the LGService class. This implements a TCP/IP network server, providing parse results as JSON messages. Any JSON-capable client can connect to this server and obtain parsed text. The third possibility is to use the org.linkgrammar.LGRemoteClient class, and in particular, the parse() method. This class is a network client that connects to the JSON server, and converts the response back to results accessible via the ParseResult API. The above-described code will be built if Apache 'ant' is installed. Using the Network Server ------------------------ The network server can be started by saying: java -classpath linkgrammar.jar org.linkgrammar.LGService 9000 The above starts the server on port 9000. It the port is omitted, help text is printed. This server can be contacted directly via TCP/IP; for example: telnet localhost 9000 (Alternately, use netcat instead of telnet). After connecting, type in: text: this is an example sentence to parse The returned bytes will be a JSON message providing the parses of the sentence. By default, the ASCII-art parse of the text is not transmitted. This can be obtained by sending messages of the form: storeDiagramString:true, text: this is a test. Spell Checking: --------------- The parser will run a spell-checker at an early stage, if it encounters a word that it does not know, and cannot guess, based on morphology. The configure script looks for the aspell or hunspell spell-checkers; if the aspell devel environment is found, then aspell is used, else hunspell is used. Spell checking may be disabled at runtime, in the link-parser client with the !spell flag. Enter !help for more details. Corpus Statistics: ------------------ The parser now contains some experimental code for using corpus statistics to provide a parse ranking, and to assign WordNet word senses to word, based on their grammatical usage. An overview of the idea is given on the OpenCog blog, here: http://brainwave.opencog.org/2009/01/12/determining-word-senses-from-grammatical-usage/ It is planned that the Corpus statistics database will be used to guide the SAT solver. To enable the corpus statistics, specify ./configure --enable-corpus-stats prior to compiling. The database itself can be downloaded from http://www.abisource.com/downloads/link-grammar/sense-dictionary/ or http://gnucash.org/linas/nlp/data/linkgrammar-wsd/ The data is contained in an sqlite3 database file, disjuncts.20090430.db.bz2 Unzip this file (using bunzip2) rename it to "disjuncts.db", and place it in the subdirectory "sql", in the same directory that contains the "en" directory. For default unix installations, the final location would be /usr/local/share/link-grammar/sql/disjuncts.db where, by comparison, the usual dictionary would be at /usr/local/share/link-grammar/en/4.0.dict After this is installed, parse ranking scores should be printed automatically, as floating-point numbers: for example: Unique linkage, cost vector = (CORP=4.4257 UNUSED=0 DIS=1 AND=0 LEN=5) Lower numbers are better. The scores can be interpreted as -log_2 of a certain probability, so the lower the number, the higher the probability. The display of disjunct scores can be enabled with the !disjuncts flag, and senses with the !senses flag, at the link-parser prompt. Entering !var and !help will show all flags. Multiple parses are sorted and displayed in order from lowest to highest cost; the sort of can be set by saying !cost=1 for the traditional sort, and !cost=2 for corpus-based cost. Output similar to the below should be printed: linkparser> !disjunct Showing of disjunct used turned on. linkparser> !cost=2 cost set to 2 linkparser> !sense Showing of word senses turned on. linkparser> this is a test Found 1 linkage (1 had no P.P. violations) Unique linkage, cost vector = (CORP=4.4257 UNUSED=0 DIS=1 AND=0 LEN=5) +--Ost--+ +-Ss*b+ +-Ds-+ | | | | this.p is.v a test.n 2 is.v dj=Ss*b- Ost+ sense=be%2:42:02:: score=2.351568 2 is.v dj=Ss*b- Ost+ sense=be%2:42:05:: score=2.143989 2 is.v dj=Ss*b- Ost+ sense=be%2:42:03:: score=1.699292 4 test.n dj=Ost- Ds- sense=test%1:04:00:: score=0.000000 this.p 0.0 0.695 Wd- Ss*b+ is.v 0.0 7.355 Ss*b- Ost+ a 0.0 0.502 Ds+ test.n 1.0 9.151 Ost- Ds- Note that the sense labels are not terribly accurate; the verb "to be" is particularly hard to tag correctly. MULTI-THREADED USE: ------------------- It is safe to use link-grammar for parsing in multiple threads, once the dictionaries have been loaded. The dictionary loading itself is not thread-safe; it is not protected in any way. Thus, link-grammar should not be used from multiple threads until the dictionary has been loaded. Different threads may use different dictionaries. Parse options can be set on a per-thread basis, with the exception of verbosity, which is a global, shared by all threads. It is the only global, outside of the Java bindings. For multi-threaded Java use, a per-thread variable is needed. This must be enabled during the configure stage: ./configure --enable-pthreads The following exceptions and special notes apply: utilities.c -- has global "verbosity". Memory usage code (disabled by default) also has a global, and so requires pthreads for tracking memory usage. jni-client.c - uses per-thread struct. This should somehow be attached to JNIEnv somehow. A Java JNI expert is needed. malloc-dbg.c - not thread safe, not normally used; only for debugging. prefix.c - not thread-safe, but doesn't need to be; used only during initialization, and only if binreloc turned on. But binreloc is never used by anyone !? pp_lexer.c -- autogened code, original lex sources lost. This is only used when reading dictionaries, during initialization, and so doesn't need to be thread safe. BioLG merger: ------------- As of version 4.5.0 (April 2009), the most important parts of the BioLG project have been merged. The current version of link-grammar has superior parse coverage to BioLG on all texts, including biomedical texts. The original BioLG test suite can be found in data/en/4.0.biolg.batch. The following changes in BioLG have NOT been merged: -- Part of speech hinting. The BioLG code can accept part-of-speech hints for unknown words. -- XML I/O. The BioLG code can output parsed text in a certain idiosyncratic XML format. -- "term support". Link-grammar does support "entity placeholders", which provides an equivalent function. -- The link type CH. This was a large, intrusive, incompatible change to the dictionary, and it is not strictly required -- there is a better, alternative way of handling adj-noun-adj-noun chains commonly seen in biomedical text, and this has been implemented. All other BioLG changes, and in particular, extensive dictionary fixes, as well as regex morphology handling, have been incorporated. Medical Terms Merger -------------------- Many, but not all, of the "medical terms" from Peter Szolovits have been merged into version 4.3.1 (January 2008) of link-grammar. The original project page was at: http://groups.csail.mit.edu/medg/projects/text/lexicon.html The following "extra" files were either merged directly, renamed, or skipped (omitted): /extra.1: -- merged /extra.2: -- skip, too big /extra.3: -- skip, too big /extra.4: -- /en/words/words-medical.v.4.2: /extra.5: -- /en/words/words-medical.v.4.1: /extra.6: -- /en/words/words-medical.adj.2: /extra.7: -- /en/words/words-medical.n.p /extra.8: -- skip, too big /extra.9: -- skip, random names /extra.10: -- /en/words/words-medical.adv.1: /extra.11: -- /en/words/words-medical.v.4.5: /extra.12: -- skip, too big /extra.13: -- /en/words/words-medical.v.4.3: /extra.14: -- /en/words/words-medical.prep.1 /extra.15: -- /en/words/words-medical.adj.3: /extra.16: -- /en/words/words-medical.v.2.1: /extra.17: -- skip, too big To make use of the "skipped" files, download the original extension, gut the contents of "extra.dict" except for the parts referring to the skipped files above, and then append to 4.0.dict (as per original instructions). Its not at all clear that the "skipped" files improve parse accuracy in any way; they may, in fact, damage accuracy. Fat Links: ---------- As of version 4.7.0 (September 2010), parsing using "fat links" has been disabled by default, and is now deprecated. The function is still there, and can be turned on by specifying the !use-fat=1 command, or by calling parse_options_use_fat_links(TRUE) from programs. As of version 4.7.12 (May 2013), the "fat link" code is no longer compiled by default. To obtain the fat-link version, ./configure must be run with the --enable-fat-links --disable-sat-solver flag. Enabling this will generate a lot of warning messages during compilation. As of version 5.2.0 (December 2014) the "fat link" code has been removed. The fat-link code consisted of about 5 KLOC or about 1/6th of the total code. About 23 KLOC of the core parser code remains. Users of the Russian dicts must use versions prior to this to get Russian sentences with conjunctions in them to parse. Older versions of the link-grammar parser used "fat links" to support conjunctions (and, or, but, ...). However, this leads to a number of complications, including poor performance due to a combinatorial explosion of linkage possibilities, as well as an excessively complex parse algorithm. SAT solver: ----------- The current parser uses an algorithm that runs in O(N^3) time, for a sentence containing N words. The SAT solver aims to replace this parser with an algorithm based on Boolean Satisfiability Theory; specifically using the MiniSAT solver. The SAT solver has a bit more overhead for shorter sentences, but is faster for long sentences. To work properly, it needs to be attached to a parse ranking system. This work is incomplete, although the prototype works. it is not yet well-integrated with the system, and needs cleanup. In particular, it fails to handle morphemes correctly (i.e. to use compute_chosen_words() in SATEncoder::create_linkage() -- this needs fixing. The chosen_disjuncts array is not filled out, and thus, there is no awareness of disjunct costs, which is the most basic parse ranking that we've got ...) The SAT solver is enabled by default. It can be disabled by specifying ./configure --disable-sat-solver prior to compiling. Directional Links ----------------- Directional links are needed for some languages, such as Lithuanian, Turkish and other free word-order languages. The goal is to have a link clearly indicate which word is the head word, and which is the dependent. This is achieved by prefixing connectors with a single *lower case* letter: h,d, indicating 'head' and 'dependent'. The linkage rules are such that h matches either nothing or d, and d matches h or nothing. New feature in version 5.1.0. Phonetics --------- A/An phonetic determiners before consonants/vowels are handled by a new PH link type, linking the determiner to the word immediately following it. Status: mostly done, more testing needed. The rules could be simplified. Many special-case nouns are unfinished. ADDRESSES --------- If you have any questions, or find any bugs, please feel free to send a note to the mailing list: [email protected] Although all messages should go to the mailing list, the current maintainers can be contacted at: Linas Vepstas - <[email protected]> Dom Lachowicz - <[email protected]> A complete list of authors and copyright holders can be found in the AUTHORS file. The original authors of the Link Grammar parser are: Daniel Sleator [email protected] Computer Science Department 412-268-7563 Carnegie Mellon University www.cs.cmu.edu/~sleator Pittsburgh, PA 15213 Davy Temperley [email protected] Eastman School of Music 716-274-1557 26 Gibbs St. www.link.cs.cmu.edu/temperley Rochester, NY 14604 John Lafferty [email protected] Computer Science Department 412-268-6791 Carnegie Mellon University www.cs.cmu.edu/~lafferty Pittsburgh, PA 15213 Mathematical Theory: -------------------- The mathematical theory of link-grammar is deeper and more interesting than the original, foundational papers on it let on. This section provides a random list of remarks about this. -- Although link-grammar links are un-oriented, a defacto direction can be given to them that is completely consistent with a dependency grammar. -- Dependency-grammar arrows are: * anti-reflexive (a word cannot depend on itself) * anti-symmetric (if Word1 depends on Word2, then Word2 cannot depend on Word1) (so e.g. determiners depend on nouns) * anti-transitive (if Word1 depends on Word2 and Word2 depends on Word3, then Word1 cannot depend directly on Word3) The last property means that dependency graphs are always skeletons of limits (in the sense of category theory). Here, by "limit" we mean that the dependency arrow is the universal, unique arrow through which all other dependencies must pass (i.e. limit in the sense of category theory). Note, however: skeletons are not categories: the first property means there are no identity morphisms, the third property says that arrows are not composable. -- Link types can be handled with "type theory". In particular, Link types can be mapped to types that appear in categorial grammars. The nice thing about link-grammar is that the link types form a type system that is much easier to use and comprehend than that of categorial grammar, and yet can be directly converted to that system! That is, link-grammar is completely compatible with categorial grammar, and is easier-to-use. See, for example, the work by Bob Coeke on category theory and grammar; there, it becomes abundantly clear that the category theoretic approach is equivalent to link-grammar, even though this is not stated anywhere. TODO -- Working Notes: ---------------------- Some working notes. Easy to fix: provide a more uniform API to the constituent tree. i.e provide word index. Also .. provide a clear word API, showing word extent, suffix, etc. Capitalized first words: There are subtle technical issues for handling capitalized first words. This needs to be fixed. See tokenize.c circa line 586 for details. Also line 1131. Maybe capitalization could be handled in the same way that a/an could be handled! After all, its essentially a nearest-neighbor phenomenon! Zero/phantom words: Expressions such as "Looks good" have an implicit "it" (also called a zero-it or phantom-it) in them; that is, the sentence should really parse as "(it) looks good". The dictionary could be simplified by admitting such phantom words explicitly, rather than modifying the grammar rules to allow such constructions. Other examples, with the phantom word in parenthesis, include: * I ate all (of) the cookies. * I taught him (how) to swim. * I told him (that) it was gone. * (It) looks good. * (You) go home! One possible solution to the unvoiced-word problem might be to allow the LG rules to insert alternatives during the early culling stages. This avoids the need to pre-insert all possible alternatives during tokenization... See github opencog#224 punctuation, zero-copula, zero-that: Poorly punctuated sentences cause problems: for example: "Mike was not first, nor was he last." "Mike was not first nor was he last." The one without the comma currently fails to parse. How can we deal with this in a simple, fast, elegant way? Similar questions for zero-copula and zero-that sentences. Bad grammar: When a sentence fails to parse, look for: * confused words: its/it's, there/their/they're, to/too, your/you're ... * missing apostrophes in possessives: "the peoples desires" * determiner agreement errors: "a books" * aux verb agreement errors: "to be hooks up" Poor linkage choices: Compare "she will be happier than before" to "she will be more happy than before." Current parser makes "happy" the head word, and "more" a modifier w/EA link. I believe the correct solution would be to make "more" the head (link it as a comparative), and make "happy" the dependent. This would harmonize rules for comparatives... and would eliminate/simplify rules for less,more. However, this idea needs to be double-checked against, e.g. Hudson's word grammar. I'm confused on this issue ... Stretchy links: Currently, some links can act at "unlimited" length, while others can only be finite-length. e.g. determiners should be near the noun that they apply to. A better solution might be to employ a 'stretchiness' cost to some connectors: the longer they are, the higher the cost. (This eliminates the "unlimited_connector_set" in the dictionary). Repulsive parses: Sometimes, the existence of one parse should suggest that another parse must surely be wrong: if one parse is possible, then the other parses must surely be unlikely. For example: the conjunction and.j-g allows the "The Great Southern and Western Railroad" to be parsed as the single name of an entity. However, it also provides a pattern match for "John and Mike" as a single entity, which is almost certainly wrong. But "John and Mike" has an alternative parse, as a conventional-and -- a list of two people, and so the existence of this alternative (and correct) parse suggests that perhaps the entity-and is really very much the wrong parse. That is, the mere possibility of certain parses should strongly disfavor other possible parses. (Exception: Ben & Jerry's ice cream; however, in this case, we could recognize Ben & Jerry as the name of a proper brand; but this is outside of the "normal" dictionary (?) (but maybe should be in the dictionary!)) More examples: "high water" can have A joining high.a and AN joining high.n; these two should either be collapsed into one, or one should be eliminated. WordNet hinting: Use WordNet to reduce the number for parses for sentences containing compound verb phrases, such as "give up", "give off", etc. incremental parsing: to avoid a combinatorial explosion of parses, it would be nice to have an incremental parsing, phrase by phrase, using a Viterbi-like algorithm to obtain the parse. Thus, for example, the parse of the last half of a long, run-on sentence should not be sensitive to the parse of the beginning of the sentence. Doing so would help with combinatorial explosion. So, for example, if the first half of a sentence has 4 plausible parses, and the last half has 4 more, then link-grammar reports 16 parses total. It would be much, much more useful to instead be given the factored results: i.e. the four plausible parses for the first half, and the four plausible parses for the last half. The lower combinatoric stress would ease the burden on downstream users of link-grammar. (This somewhat resembles the application of construction grammar ideas to the link-grammar dictionary). Caution: watch out for garden-path sentences: The horse raced past the barn fell. The old man the boat. The cotton clothing is made of grows in Mississippi. The current parser parses these perfectly; a viterbi parser could trip on these. Other benefits of a Viterbi decoder: * Less sensitive to sentence boundaries: this would allow longer, run-on sentences to be parsed far more quickly. * Could do better with slang, hip-speak. * Would enable co-reference resolution across sentences (resolve pronouns, etc.) * Would allow richer state to be passed up to higher layers: specifically, alternate parses for fractions of a sentence, alternate reference resolutions. * Would allow plug-in architecture, so that plugins, employing some alternate, higher-level logic, could disambiguate (e.g. by making use of semantic content). * Eliminate many of the hard-coded array sizes in the code. * Fixes the word-count problem during spell-guessing. So, for example, if the mis-spelled word "dont" shows up in the input, it could be issued as one word ("done") or two ("do n't") and the current suffix-stripping/word-issuing algo cannot deal with this correctly. By contrast, this should not be an issue for the Viterbi algo, as it could explore both states at once. One may argue that Viterbi is a more natural, biological way of working with sequences. Some experimental, psychological support for this can be found here: http://www.sciencedaily.com/releases/2012/09/120925143555.htm per Morten Christiansen, Cornell professor of psychology. Registers, sociolects, dialects (cost vectors): Consider the sentence "Thieves rob bank" -- a typical newspaper headline. LG currently fails to parse this, because the determiner is missing ("bank" is a count noun, not a mass noun, and thus requires a determiner. By contrast, "thieves rob water" parses just fine.) A fix for this would be to replace mandatory determiner links by (D- or {[[()]] & headline-flag}) which allows the D link to be omitted if the headline-flag bit is set. Here, "headline-flag" could be a new link-type, but one that is not subject to planarity constraints. Note that this is easier said than done: if one simply adds a high-cost null link, and no headline-flag, then all sorts of ungrammatical sentences parse, with strange parses; while some grammatical sentences, which should parse, but currently don't, become parsable, but with crazy results. More examples, from And Rosta: "when boy meets girl" "when bat strikes ball" "both mother and baby are well" A natural approach would be to replace fixed costs by formulas. This would allow the dialect/sociolect to be dynamically changeable. That is, rather than having a binary headline-flag, there would be a formula for the cost, which could be changed outside of the parsing loop. Such formulas could be used to enable/disable parsing specific to different dialects/sociolects, simply by altering the network of link costs. Perhaps a simpler alternative would be to have labelled costs (a cost vector), so that different dialects assign different costs to various links. A dialect would be specified during the parse, thus causing the costs for that dialect to be employed during parse ranking. Imperatives: "Push button" "Push button firmly" Hand-refining verb patterns: A good reference for refining verb usage patterns is: COBUILD GRAMMAR PATTERNS 1: VERBS from THE COBUILD SERIES /from/ THE BANK OF ENGLISH HARPER COLLINS online at https://arts-ccr-002.bham.ac.uk/ccr/patgram/ http://www.corpus.bham.ac.uk/publications/index.shtml Quotations: Currently, tokenize.c ignores all ASCII double-quotes (grep for "quote_found" in the source). However, it does not do this for the various "curly" UTF8 quotes, such as ‘these’ and “these”. This results is some ugly parsing for sentences containing such quotes. (Note that these are in 4.0.affix). no-links-cross: Link Grammar uses a constraint that all linkages must be planar graphs. While this is mostly correct, it would probably be more correct to use "landmark transitivity" as articulated by Hudson in the Word Grammar theory. This might allow the elimination of most or all post-processing rules. This is done by making each link directional: one end of the link is the parent. (e.g. noun, noun-modifier: the noun is the parent). Parents are landmarks for children. Transitivity is applied to parent-child relationships. Specifically, the no-links-cross rule is replaced by two landmark transitivity rules: -- If B is a landmark for C, then A is also a type-L landmark for C -- If A is a landmark for C, then B is also a landmark for C where type-L means either a right-going or left-going link. See http://goertzel.org/ProwlGrammar.pdf for details. See also: http://www.phon.ucl.ac.uk/home/dick/enc/syntax.htm Related notions: http://en.wikipedia.org/wiki/Catena_(linguistics) Places where no-links-cross seems to be violated in English: "He is either in the 105th or the 106th battalion." "He is in either the 105th or the 106th battalion." Both seem to be acceptable in English, but require two different parse trees when no-links is enforced. Similarly: "He is either here or he is there." "He either is here or he is there." Other examples, per And Rosta: "He had been allowed to eat a cake by Sophy that she had made him specially" -- The allowed--by link crosses cake--that "a very much easier book indeed": an--book, very--indeed "an easy book to read": an--book, easy--to "a more difficult book than that one": a--book, more--than "It was announced that remains have been found of the ark of the covenant" that--have crosses remains--of "to be fishing": Link grammar offers four parses of "I was fishing for evidence", two of which are given low scores, and two are given high scores. Of the two with high scores, one parse is clearly bad. Its links "to be fishing.noun" as opposed to the correct "to be fishing.gerund". That is, I can be happy, healthy and wise, but I certainly cannot be fishing.noun. This is perhaps not just a bug in the structure of the dictionary, but is perhaps deeper: link-grammar has little or no concept of lexical units (i.e. collocations, idioms, institutional phrases), which thus allows parses with bad word-senses to sneak in. The goal is to introduce more knowledge of lexical units into LG. Different word senses can have different grammar rules (and thus, the links employed reveal the sense of the word): for example: "I tend to agree" vs. "I tend to the sheep" -- these employ two different meanings for the verb "tend", and the grammatical constructions allowed for one meaning are not the same as those allowed for the other. Yet, the link rules for "tend.v" have to accommodate both senses, thus making the rules rather complex. Worse, it potentially allows for non-sense constructions. If, instead, we allowed the dictionary to contain different rules for "tend.meaning1" and "tend.meaning2", the rules would simplify (at the cost of inflating the size of the dictionary). Another example: "I fear so" -- the word "so" is only allowed with some, but not all, lexical senses of "fear". So e.g. "I fear so" is in the same semantic class as "I think so" or "I hope so", although other meanings of these verbs are otherwise quite different. [Sin2004] "New evidence, new priorities, new attitudes" in J. Sinclair, (ed) (2004) How to use corpora in language teaching, Amsterdam: John Benjamins See also: Pattern Grammar: A Corpus-Driven Approach to the Lexical Grammar of English Susan Hunston and Gill Francis (University of Birmingham) Amsterdam: John Benjamins (Studies in corpus linguistics, edited by Elena Tognini-Bonelli, volume 4), 2000 "holes" in collocations (aka "set phrases" of "phrasemes"): The link-grammar provides several mechanisms to support circumpositions or even more complicated multi-word structures. One mechanism is by ordinary links; see the V, XJ and RJ links. The other mechanism is by means of post-processing rules. However, rules for many common forms have not yet been written. The general problem is of supporting structures that have "holes" in the middle, that require "lacing" to tie them together. For a general theory, see: http://en.wikipedia.org/wiki/Catena_(linguistics) For example, the adposition: ... from [xxx] on. "He never said another word from then on." "I promise to be quiet from now on." "Keep going straight from that point on." "We went straight from here on." ... from there on. "We went straight, from the house on to the woods." "We drove straight, from the hill onwards." Note that multiple words can fit in the slot [xxx]. Note the tangling of another prepositional phrase: "... from [xxx] on to [yyy]" More complicated collocations with holes include "First.. next..." "If ... then ..." 'Then' is optional ('then' is a 'null word'), for example: "If it is raining, stay inside!" "If it is raining, [then] stay inside!" "if ... only ..." "If there were only more like you!" "... not only, ... but also ..." "Either ... or ..." "Both ... and ..." "Both June and Tom are coming" "ought ... if ..." "That ought to be the case, if John is not lying" "Someone ... who ..." "Someone is outside who wants to see you" "... for ... to ..." "I need for you to come to my party" The above are not currently supported. An example that is supported is the "non-referential it", e.g. "It ... that ..." "It seemed likely that John would go" The above is supported by means of special disjuncts for 'it' and 'that', which must occur in the same post-processing domain. See also: http://www.phon.ucl.ac.uk/home/dick/enc2010/articles/extraposition.htm http://www.phon.ucl.ac.uk/home/dick/enc2010/articles/relative-clause.htm "...from X and from Y" "By X, and by Y, ..." Here, X and Y might be rather long phrases, containing other prepositions. In this case, the usual link-grammar linkage rules will typically conjoin "and from Y" to some preposition in X, instead of the correct link to "from X". Although adding a cost to keep the lengths of X and Y approximately equal can help, it would be even better to recognize the "...from ... and from..." pattern. The correct solution for the "Either ... or ..." appears to be this: ---------------------------+---SJrs--+ +------???----------+ | | +Ds**c+--SJls-+ +Ds**+ | | | | | | either.r the lorry.n or.j-n the van.n The wrong solution is --------------------------+ +-----Dn-----+ +---SJrs---+ | +Ds**c+--SJn--+ +Ds**+ | | | | | | neither.j the lorry.n nor.j-n the van.n The problem with this is that "neither" must coordinate with "nor". That is, one cannot say "either.. nor..." "neither ... or ... " "neither ...and..." "but ... nor ..." The way I originally solved the coordination problem was to invent a new link called Dn, and a link SJn and to make sure that Dn could only connect to SJn, and nothing else. Thus, the lower-case "n" was used to propagate the coordination across two links. This demonstrates how powerful the link-grammar theory is: with proper subscripts, constraints can be propagated along links over large distances. However, this also makes the dictionary more complex, and the rules harder to write: coordination requires a lot of different links to be hooked together. And so I think that creating a single, new link, called ???, will make the coordination easy and direct. That is why I like that idea. The ??? link should be the XJ link, which-see. More idiomatic than the above examples: "...the chip on X's shoulder" "to do X a favour" "to give X a look" The above are all examples of "set phrases" or "phrasemes", and are most commonly discussed in the context of MTT or Meaning-Text Theory of Igor Mel'cuk et al (search for "MTT Lexical Function" for more info). Mel'cuk treats set phrases as lexemes, and, for parsing, this is not directly relevant. However, insofar as phrasemes have a high mutual information content, they can dominate the syntactic structure of a sentence. MTT suggests that perhaps the correct way to understand the contents of the post-processing rules is as an implementation of 'lexical functions' projected onto syntax. That is, the post-processing rules allow only certain syntactical constructions, and these are the kinds of constructions one typically sees in certain kinds of lexical functions. Alternately, link-grammar suffers from a combinatoric explosion of possible parses of a given sentence. It would seem that lexical functions could be used to rule out many of these parses. On the other hand, the results are likely to be similar to that of statistical pare ranking (which presumably captures such quasi-idiomatic collocations at least weakly). Ref. I. Mel'cuk: "Collocations and Lexical Functions", in ''Phraseology: theory, analysis, and applications'' Ed. Anthony Paul Cowie (1998) Oxford University Press pp. 23-54. More generally, all of link-grammar could benefit from a MTT-izing of infrastructure. Compare the above problem to Hebrew morphological analysis. To quote Wikipedia: > This distinction between the word as a unit of speech and the > root as a unit of meaning is even more important in the case of > languages where roots have many different forms when used in > actual words, as is the case in Semitic languages. In these, > roots are formed by consonants alone, and different words > (belonging to different parts of speech) are derived from the > same root by inserting vowels. For example, in Hebrew, the root > gdl represents the idea of largeness, and from it we have gadol > and gdola (masculine and feminine forms of the adjective "big"), > gadal "he grew", higdil "he magnified" and magdelet "magnifier", > along with many other words such as godel "size" and migdal > "tower". Dealing with long, ambiguos sentences: These are busted up by humans into smaller sentences that "hang together" as phrase-structures, viz compunded sentences. The most likely parse is then when each of the quasi sub-sentences is parsed correctly. Alternatives: A partial solution to the morphology problem and the idiom problem in link-grammar is to elevate the use of "alternatives" in the Word struct. Originally, these were morphological split alternatives for the Russian dicts, but really, they are a way of hierarchically arranging choices for words... 1) create struct alternative for struct word 2) fix sane_morpheme to use that. Status: A basic design for this has been sketched on the public mailing list. AmirP is working on it. Morphology printing: Instead of hard-coding LL, declare which links are morpho links in the dict. Word-order flexibility: For Lithuanian, the following are desperately needed: -- connectors with * direction, i.e. either left or right. -- symmetric (commuting) version of &. -- DONE! The new symbols are ^ for commuting-& and $ to mean either + or -. This still needs to be documented. Capitalization-mark tokens: The proximal issue is to add a cost, so that Bill gets a lower cost than bill.n when parsing "Bill went on a walk". The best solution would be to add a 'capitalization-mark token' during tokenization; this token precedes capitalized words. The dictionary then explicitly links to this token, with rules similar to the a/an phonetic distinction. The point here is that this moves capitalization out of ad-hoc C code and into the dictionary, where it can be handled like any other language feature. Incremental sentence parsing: There are multiple reasons to support incremental parsing: -- Real-time dialog -- Parsing of multiple streams, e.g. from play/movie scripts -- segmentation of exceptionally long sentences. This could be implemented by saving dangling right-going connectors into a parse context, and then, when another sentence fragment arrives, use that context in place of the left-wall. UTF-8 cleanup: Replace the mbrtowc code with proper language support; it seems that the correct solution is to use ICU http://site.icu-project.org/ ICU pros: runs on windows ICU cons: big, complex Another alternative is libunistring (which seems to be LGPL!?) http://www.gnu.org/software/libunistring/ pros: smaller, simpler than ICU cons: might have problems with MS Windows. Assorted minor cleanup: -- Should provide a query that returns compile-time consts, e.g. the max number of characters in a word, or max words in a sentence -- Should remove compile-time constants, e.g. max words, max length etc. Misc TODO: -- finish sqlite3 work Version 6.0 TODO list: Version 6.0 will change Sentence to Sentence*, Linkage to Linkage* in the API. Perhaps this is a bad idea... A performance diary: -------------------- Time to parse some long sentences: The original results below were for version 5.0.8 (April 2014) The June 2014 results are for version 5.1.0 These are very highly dependent on the aggressiveness of the token splitter, on the short length, on the cost-max and the spell checker. Suggest using flags: -spell=0 -short=10 -cost-max=2.1 25 words + 2 punct, 0.2 seconds (0.7 seconds June 2014) (0.2 secs SAT, June 2014) Hot runners usually make the mold more expensive to manufacture and run, but allow savings by reducing plastic waste and by reducing the cycle time. 38 words + 4 punct: 2.4 seconds (2.6 secs, June 2014) (0.32 secs, SAT, June 2014) The strongest rain ever recorded in India shut down the financial hub of Mumbai, snapped communication lines, closed airports and forced thousands of people to sleep in their offices or walk home during the night, officials said today. 50 words + 9 punct: 14 seconds (3.9 secs June 2014) (0.64 secs, SAT June 2014) In vivo studies of the activity of four of the kinases, KinA, KinC, KinD (ykvD) and KinE (ykrQ), using abrB transcription as an indicator of Spo0A~P level, revealed that KinC and KinD were responsible for Spo0A~P production during the exponential phase of growth in the absence of KinA and KinB. 56 words + 8 punct: 4.5 seconds (1.45 secs June 2014) (0.38 secs, SAT June 2014) New York Post: The new Mel Brooks/Susan Stroman musical extravaganza ... is nearly very good indeed - but it is not the The Producers ... this story ... does not lend itself to stage adaptation in the way of the earlier movie ... Now for the good news ... Brooks and Stroman pull out every stop. 57 words + 10 punct: 7.5 seconds (6.8 seconds June 2014) (0.68 secs, SAT June 2014) However, the few tracts, the poetry, and the novels that embodied the social vision of Young England were directed to a New Generation of educated, religious, and socially conscious conservatives, who, like Young Englanders, were appalled at the despiritualizing effects of industrialization and the perceived amorality of Benthamite philosophy, which they blamed equally for Victorian social injustices. 73 words + 8 punct: 145 seconds Cortes in his various letters again and again claims the Emperor's patronage of his bold defiance of the Emperor's officers on the ground that the latter in their action were moved solely by considerations of their personal gain, whereas he, Cortes, was striving to endow his sovereign with a rich new empire and boundless treasure whilst carrying into the dark pagan land, at the sword's point, the gentle creed of the Christian God.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.