Very cool. What about contextually-dependent characters? For example when tokenizing English, an contraction apostrophe is actually part of the word, but an ending single quote is not. Would this be up to the parser to disambiguate?
Weston On Mon, Apr 5, 2010 at 1:29 PM, James Tauber <jtau...@jtauber.com> wrote: > As it happens, I was working on a tokenizer last night (was the reason for > this tweet: http://twitter.com/jtauber/status/11611451291 ). I had planned > to put it up on GitHub (as part of a general "text tools" project) but here > is the current state: > > > The core of it is just a two-line python function: > > -------------------- > > from itertools import groupby > > def tokenize(stream, chr_classes): > """ > tokenize the given stream based on the given character classes. > > chr_classes should be a dictionary mapping character class label to a > string of member unicode characters:: > { > "numbers": u"0123456789", > "whitespace": u" \n", > } > """ > # build reverse index from character to character class > idx = dict((ch, chr_class) for chr_class, chrs in chr_classes.items() > for ch in chrs) > > # tokenize text > return groupby((ch for line in stream for ch in line.decode("utf-8")), > idx.get) > > -------------------- > > So, for example you set up your character classes (yes, I could have just > defined ranges but, in my code last night, I was being explicit about the > character appearing in the particular text I was tokenizing) > > > -------------------- > > def u(s): > """ > convert utf-8 encoded string to unicode. > """ > return s.decode("utf-8") > > > CHR_CLASSES = { > "editorial": u("[]‹›()"), > "letters": u( > "ΒΓΔΖΘΚΛΜΝΞΠΣΤΦΧΨ" "ΑΕΗΟ" "Ῥ" > "ἈἊἉἌἍἙἘἝἜἚἩἨἬἭἹἸἽἼὍὉὊὈὌὙὩὭὫὨ" > "βγδζθκλμνξπρσςτφχψ" "αεηιουω" "ῥῤ" > "ἀἁάὰᾶἄἅἂᾳᾷἃἆᾴᾄ" "ἐἑέὲἔἕἓ" "ἡήὴῆἢἤῃῄῇἥἦἧᾐἠᾖἣᾗ" > "ἰἱίὶῖἶἷἴἵϊἳΐῒ" "ὀὁόὸὅὃὄὂ" "ὐὑύὺῦὔὖὕὓ" > "ὡώὼῶὧὥῳᾠῷῴᾧὦὤὠὢᾡὣ" > "΄" > ), > "whitespace": u(" \n"), > "numbers": u("1234567890"), > "punctuation": u(".,·;“”"), > "temp": u("†-"), > } > > -------------------- > > and then you're good to go... > > > -------------------- > > import sys > FILENAME = sys.argv[1] > > for chr_class, token in tokenize(open(FILENAME), CHR_CLASSES): > print "".join(token).encode("utf-8"), chr_class > > -------------------- > > > James > > > On Apr 5, 2010, at 1:44 PM, Weston Ruter wrote: > > > DM: > > > > But what we really need is not a parser but a tokenizer. I'm thinking > about writing one (my degree work was in compiler writing). Basically, we > repeat the same tokenization code in several places. It should be trivial to > write a complete, accurate one. > > > > I've also been wanting to work on a tokenizer. At Open Scriptures, the > text of a work is currently represented by two models (database tables): > Token and Structure. Tokens are the smallest divisible units of text, such > as words, punctuation, and whitespace; and structures are the spans of > tokens that form logical units, such as verses, paragraphs, quotes, etc. The > structures are standoff-markup for the tokens. With the underlying data > stored in this way, it can then be serialized in whichever hierarchy desired > (book-section-paragraph, book-chapter-verse, all-milestoned, etc) or > whichever data format is needed (OSIS, SWORD Module, XHTML, etc.) > > > > So what I'm currently rumenating on is the process of importing the raw > data into the Token and Structure models. I wrote an importer for the > Tischendorf GNT data which does everything both tokenizing and parsing, but > obviously there is going to be a lot of code in common with other importers > that are written. So I too am thinking about how these importers can be > reduced to the bare minimum to handle the unique aspects of the raw data > (i.e. normalize it), and then stream the tokens back to a central importer > that parses the input and stores it into the Token and Structure models. > This central importer facility could be a web service. > > > > I've love to collaborate with you on this. We could come up with a common > tokenizer that can be used by both SWORD and Open Scriptures. The importer > web service could take tokens as input and as output generate a SWORD module > and also populate the Open Scriptures models at the same time. > > > > Thoughts? > > > > Weston > > > > > > > > On Mon, Apr 5, 2010 at 10:24 AM, Daniel Owens <dhow...@pmbx.net> wrote: > > Yes, I agree, and if there were a feedback mechanism for the module > creator to let them know how to start fixing an OSIS file or conf file, it > would save Chris (or whoever else approves modules) time on the basic stuff. > > > > Daniel > > > > > > On 4/5/2010 11:09 AM, DM Smith wrote: > > This is a great idea. Rather than emailing source to modules at crosswire > dot org, one could upload it via a web service. We could have stages of > validation (xmllint) and construction (osis2mod). Such a service could > evaluate the quality of the submission. > > > > In Him, > > DM > > > > On 04/05/2010 12:01 PM, Weston Ruter wrote: > > Why not turn osis2mod into a web service? Then it wouldn't matter how it > is implemented since it would be abstracted away by the web service > interface. It could use the best XML libraries available today and written > in the programming language of choice, both of which would make maintenance > and the addition of new features much easier. > > > > Weston > > > > > > > > On Mon, Apr 5, 2010 at 9:05 AM, DM Smith <dmsm...@crosswire.org> wrote: > > On 04/05/2010 09:03 AM, Dmitrijs Ledkovs wrote: > > On 5 April 2010 13:55, Manfred Bergmann<manfred.bergm...@me.com> wrote: > > > > Hi DM. > > > > Am 05.04.2010 um 13:21 schrieb DM Smith: > > > > > > Regarding using a "real" parser, it is a good idea. But we don't want > SWORD to be dependant on an external parser. > > > > What's the reason for that? > > I could understand if it would mean for the user to install certain > libraries manually but when the sources can be integrated into the project > and has the appropriate licence then why not? > > > > > > Manfred > > > > > > IMHO there is no harm in bringing in libxml or a much more lightweight > > parser like GMarkup. The build system just needs to be adjusted to > > link e.g. libxml for the osis2mod binary and not shared sword library. > > in can be even called a new tool osisxml2mod for example and make it > > be build optionally such that you can still have full sword dev > > environment without libxml. > > > > Tools for creating modules do not have be linked with sword or even > > live in sword taball / svn. Although it does help consistent > > distribution of tools. > > > > I don't remember all of Troy's reasoning when I argued for a true parser. > > > > From what I recall: > > o To maintain freedom to re-license SWORD (e.g. for some other Bible > society) we need to be able to keep 3-rd party library dependencies well > managed. The license needs to be compatible with the GPL but cannot be GPL. > > > > o The parser that we have is minimal and simple, sacrificing accuracy and > completeness for speed. Regarding accuracy, e.g. the parser allows for > spaces around = in attribute declarations. Regarding completeness, e.g. it > does not handle namespaces, cdata, dtds/schemas, .... Significantly, it does > not require a well-formed document, allowing for fragments. Rather than an > error, it continues when an xml parser is required to stop. > > > > o This parser has better error reporting in that it is based upon > knowledge of the input. E.g. it reports the verse having the problem. > > > > o By SWORD having the parser, we are not dependent on finding an > implementation for every platform (e.g. Windows). > > > > There may be other reasons. I'm willing to live with it. > > > > But what we really need is not a parser but a tokenizer. I'm thinking > about writing one (my degree work was in compiler writing). Basically, we > repeat the same tokenization code in several places. It should be trivial to > write a complete, accurate one. > > > > In His Service, > > DM > > > > > > _______________________________________________ > > sword-devel mailing list: sword-devel@crosswire.org > > http://www.crosswire.org/mailman/listinfo/sword-devel > > Instructions to unsubscribe/change your settings at above page > > > > > > -- > > You received this message because you are subscribed to the Google Groups > "Open Scriptures" group. > > To post to this group, send email to open-scriptu...@googlegroups.com. > > To unsubscribe from this group, send email to > open-scriptures+unsubscr...@googlegroups.com<open-scriptures%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group at > http://groups.google.com/group/open-scriptures?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Open Scriptures" group. > To post to this group, send email to open-scriptu...@googlegroups.com. > To unsubscribe from this group, send email to > open-scriptures+unsubscr...@googlegroups.com<open-scriptures%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/open-scriptures?hl=en. > >
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
