Natural Language Corpus Data: Beautiful Data
norvig.com
norvig.com
The later Google Books Ngrams [1] data sets are cleaner, but that comes at a cost. You lose spam, but also a lot of other uses of language, when you only consider text that has been published in print. It's all in the formal register. And then you also get correlated OCR errors, as in [2], and you still get data whose collection ended in 2008.
So what am I suggesting you should use, if data from the Web is bad for some things and data from books is bad for others? Well, both of them, and a lot of other things too. An analysis that depends on word frequencies should use the consensus of many sources.
I've been working on compiling together many of those sources, in many languages, in the Python package wordfreq [3]. Now I'm working on an update to include excellent corpus data just released by the OPUS project, including OpenSubtitles 2016 [4].
[1] http://storage.googleapis.com/books/ngrams/books/datasetsv2....
[2] http://drhagen.com/blog/the-missing-11th-of-the-month/
[0] https://en.wikipedia.org/wiki/Unicode_equivalence#Normalizat...
[1] https://en.wikipedia.org/wiki/UTF-32#Use
[2] https://en.wikipedia.org/wiki/Character_encoding#Terminology
In general I use tokenization rules that follow the Unicode standards in [UAX 29], with language-specific external libraries for Chinese, Japanese, and Korean, and with some language-specific tweaks to handle cases the Unicode Consortium didn't go into. [0]
I use Python 3 strings, and it's a peculiar bit of abstraction-busting to worry about what they look like inside the Python interpreter. It's only UTF-32 for strings that contain high codepoints. See [PEP 393], "Flexible String Representation".
I don't think there is such a thing as "multi-character code points". At no point do I use UTF-16 (which has code points made of multiple surrogate code points, which are not characters), if that's what you're asking about.
[0] https://github.com/LuminosoInsight/wordfreq/blob/master/word...
[UAX 29] http://unicode.org/reports/tr29/ (fixed link)
One idea is to make a lattice of unicode characters that builds up to combination of words a la Formal Concept Analysis [1] -- on one level, the characters compose into words that represent properties (key/value pairs), and then the KV pairs compose into higher-level objects. Each property and higher-level object is encoded with an integer derived from its constituent objects/properties, and each object is encoded in such a way that its constituent objects/properties can be determined algorithmically from the integer without having to traverse the structure [2] -- ANS encoding [3] embedded into a space with a VI metric (https://en.wikipedia.org/wiki/Variation_of_information) [4] might make this work. Have you played with this type of design?
[0] http://blog.christianperone.com/2015/08/googles-s2-geometry-...
[1] https://www.youtube.com/watch?v=Xuxm929tIRY
[2] http://www09.sigmod.org/sigmod/record/issues/0506/p47-articl...
[3] https://en.wikipedia.org/wiki/Asymmetric_Numeral_Systems
[4] http://www.sciencedirect.com/science/article/pii/S0047259X06...
Also...
http://about.reuters.com/researchandstandards/corpus/
[0] https://en.wikipedia.org/wiki/Arithmetic_coding#Defining_a_m...
You're not going to find many public datasets on SMS or other emoji-using entities regardless of language. Twitter or Instagram are your best bet, but building your model on those will only work best on those types of input.
* http://www.emojitracker.com/
* http://github.com/mroth/emojitrack
* https://medium.com/@mroth/how-i-built-emojitracker-179cfd823...
* https://medium.com/@mroth/how-i-kept-building-emojitracker-c...
Just noting this content is from 2008-2009 and the related book was published in 2009.