Bibliographic record
Abstract
Use Python to demystify Open Document Format files. The Open Document Format (ODF) Alliance is designed for sharing information between different word processing applications. This article highlights the basic structure of ODF files, some internals of the underlying XML files and shows how to use Python to read the contents to perform a simple search for keywords. The code also can be the basis for more-advanced operations. In the spirit of openness, we use open-source software to read the ODF files, which in this case are Python and the OpenOffice.org package. If you are running a recent version of Linux or OS X, you already should have Python and OpenOffice.org installed on your machine. If you need the latest versions, Python is available for free from http://www.python.org for both the Windows and Linux platforms. The OpenOffice.org package also is available for free from http://www.openoffice.org. Installing OpenOffice.org on an XP desktop is relatively painless. Download the packages from their respective sites and run the installer. Once installed, simply run the application from the desktop with a click on the installed icons. Tip: Most folks do have Microsoft Office installed. If that's the case, the solution is to use a plugin for Microsoft Word (http://sourceforge.net/projects/odf-converter). You can install both the OpenOffice.org and Microsoft packages on the same machine without causing any conflicts. Please read the Bugs section on the SourceForge site for any incompatibilities before you install the plugin. I used the OpenOffice.org suite to save the files for this article, because it was easier. Once you have confirmed that you have the prerequisites, you can create an ODF file. Open up the Writer, type some text in a document and save it. You can read in a file and save it as an .odt file. A quick look at extensions in the Save dialog reveals a lot. An ODF file can have many extensions, which provide a clue as to the type of information stored in it and the application that stored it. See Table 1. Table 1. Table 1. ODF File Types and Their Extensions Document Format File Extension OpenDocument Text *.odt OpenDocument Text Template *.ott OpenDocument Master Document *.odm Extract and Parse ODF Files with Python http://0-delivery.acm.org.innopac.lib.ryerson.ca/10.1145/1250000/12... 2 of 8 8/27/2007 8:09 PM Document Format File Extension HTML Document *.html HTML Document Template *.oth OpenDocument Spreadsheet *.ods OpenDocument Spreadsheet Template *.ots OpenDocument Drawing *.odg OpenDocument Drawing Template *.otg OpenDocument Presentation *.odp OpenDocument Presentation Template *.otp OpenDocument Formula *.odf OpenDocument Database *.odb So, what's in an ODF file? An ODF file is basically a zipped archive with several XML files. The actual files and directories in a file will vary depending on the type of information and the system on which the document was created. The first step in picking out the names of the files in an ODF file requires unzipping the file itself. Fortunately, Python has built-in support for dealing with this endeavor with the zipfile module. Type python on the command line to run an interactive shell. Running a shell allows you to examine the contents of objects returned from the modules. Because you'll probably be doing this only once per type of data, there is really no need to write and execute a script at this time. If you want to preserve the work for future use, it's better to write a script in a text editor or use the IDLE editor that comes with Python and save the script. See Listing 1 on how to show the member functions in a class or module. Listing 1. Showing the Member Functions in a Class or Module Python 2.4.1 (#65, Mar 3
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.014 |
| Meta-epidemiology (narrow) | 0.003 | 0.002 |
| Meta-epidemiology (broad) | 0.001 | 0.003 |
| Bibliometrics | 0.006 | 0.004 |
| Science and technology studies | 0.002 | 0.001 |
| Scholarly communication | 0.005 | 0.005 |
| Open science | 0.003 | 0.005 |
| Research integrity | 0.001 | 0.003 |
| Insufficient payload (model declined to judge) | 0.136 | 0.171 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".