If they did, they'd have seen a lot of weird changes going on in real-time concerning some XML code in a recent post.

Basically, I've been playing around with various WordPress plugins that support syntax highlighting, which is a fancy way of color-coding code examples with color-coding specific to various scripting and markup languages like PHP, Python, XML, etc.

Anyway, after playing around with several, I was running into the same issue with the indent stripping as talked about here. The use of indentation is paramount to making one's code readable and in some languages, like Python, indentation is required.

In other words, this is valid Python code:

if a == a:

print "The 'a' variable is equal to itself!"

But this is invalid:

if a == a:

print "The 'a' variable is equal to itself!"

because the print statement is dependent on a condition.

Anyway, what was happening was that I'd put code into WordPress, the indentation and highlighting would look good, but if I wanted to edit my post later all the indentation would be lost when I'd reopened the post in the editor (btw: I use Dean's FCKEditor).

So here's what appears to fix it:

• I installed my preferred WordPress syntax highlighter: Syntax Highlighter Compress Syntax Highlighter Evolved.
• I wrote my post and pasted my code directly into the Visual Editor.
• I then highlighted only the code and from the Visual Editor's "styles" drop-down menu I chose "Computer Code".
• I then edited the post in Source mode.
  • The indentations had now been converted to the proper HTML entity names.
• I replaced the <code> tags with <pre> tags.
  • The opening <pre> tag needs a "class" attribute to specify the type of code (i.e. Python, XML, etc.)
  • For example, I'd use this for Python:
    • <pre class="brush:python">
  • and this for XML:
    • <pre class="brush:xml">

From then on, everything seems to be OK. That is to say, I can edit my post at a later time with the Source or Visual Editor and all my indentations are intact.

Here's the earlier Python code using the technique just described:

if a == a:
	    print "The 'a' variable is equal to itself!"

And that's that … I hope.

Having said that: anything I offer up is to be downloaded and run at your own risk.

Some time ago - exactly a year ago, actually! – I shared a post on how to use XSLT to turn a PubMed XML file into an HTML table and in turn paste that into Microsoft Excel or OpenOffice Calc.

That's fine and all but that's still too "techy" for the average bear who just wants to get a list of articles into a spreadsheet. So, I've been working on some software called PubMed2XL to make the job super simple.

PubMed2XL's a GUI program written in Python and it uses PyQT:

… a set of Python bindings for Nokia's Qt application framework and runs on all platforms supported by Qt including Windows, MacOS/X and Linux.

Since the program's still in early stages there's no real documentation but if you want to just play around with it and you use Windows you can get it here. If it doesn't work, it's probably because you need a file called MSVCR71.dll which I can't legally distribute but I think you can find it if you are resourceful.

Basically all you need to do is this:

1. Conduct searches in PubMed.
2. Send your articles to the Clipboard.
3. Send the results to "File" as XML.
4. Save the file as "pubmed_results.txt" which is the default name – of course, you can call the file something else if you want as long as it ends in ".txt" or ".xml".
5. Click on the file called PubMed2XL.exe and then choose FILE>SELECT PUBMED FILE as below:

    

   

6. Then "open" the file you downloaded from PubMed (pubmed_results.txt).
7. You should now see an XLS (Microsoft Excel) file in the same folder as pubmed_results.txt.

That should pretty much be it. And by the way the Help currently just points your browser to blog.humaneguitarist.org because, um, there's no help documentation yet.

If you're curious how this all works in the very general sense, I'm using a home-grown XML setup file (see below) that tells PubMed2XL which element or attribute value to extract from the pubmed_results.txt file. Then, the script uses the awesome pyExcelerator module to write the data to an XLS file.

By using this XML file advanced users can change the data as well as the spreadsheet column names that are generated in the resultant XLS file. I'm trying to make this software as open and mutable as possible but casual users won't have to worry about anything since the defaults should eventually work just fine.

Right now, the main work I have left to do is to overcome one glaring weakness. PubMed2XL can currently only retrieve data from non-repeating XML elements. In other words, elements like an author's <LastName> can't be extracted because there may be more than one author. What I'll eventually do is incorporate something in the setup file that tells PubMed2XL which occurrence of a repeating element to get data from: i.e. the last name of the primary author, etc.

If you are bored enough to download the zip file containing the program files, you'll notice the main executable file, PubMed2XL.exe, but also another file called PubMed2XL_CL.exe. Now this is exactly the same application but if you click on it you will see an ugly console window pop up in addition to PubMed2XL. The only reason I've included that file is to demonstrate that PubMed2XL can support command line arguments. In other words if you were to go to the command line and type in

 $ PubMed2XL_CL -h 

you would see a message pop up on the command line showing you the options for passing arguments to the software via the command line.

Basically what this means is that you can tell PubMed2XL which PubMed file to process and what to call the resultant spreadsheet while bypassing the program's graphical interface. Now if you're working on just one file, the GUI version is definitely the way to go, but by incorporating command line functionality the program becomes instantly usable for batch-processing multiple files and also becomes a viable tool to incorporate on a server. In other words, it could be used on the back end of a website. For example,  users could just upload their PubMed file to a website while having the XLS file emailed to them or something like that.

Anyway, there's still lots to do and when I've taken care of the issues I mentioned I'll release the source code if anyone's interested – or if Linux or MAC users want to get this up and running on their systems.

Ideally, I'd like this to become a nifty tool reference librarians could use to help their patrons with. Now if something like this is already out there, please let me know. No need to re-invent the wheel.

<?xml version="1.0" encoding="UTF-8" ?>
	<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PubMed2XL-0.8.9.xsd">
	    <spreadsheetHeader>
	        <column xPath="PubmedArticle/MedlineCitation/PMID" type="element" linkPrefix="http://www.ncbi.nlm.nih.gov/pubmed/">PMID</column>
	        <column xPath="PubmedArticle/MedlineCitation" type="attribute" attributeName="Owner" linkPrefix="none">Owner</column>
	        <column xPath="PubmedArticle/MedlineCitation/Article/Journal/JournalIssue/PubDate/Year" type="element" linkPrefix="none">Publication Year</column>
	        <column xPath="PubmedArticle/MedlineCitation/Article/Journal/JournalIssue/PubDate/Month" type="element" linkPrefix="none">Publication Month</column>
	        <column xPath="PubmedArticle/MedlineCitation/Article/Journal/Title" type="element" linkPrefix="http://www.ncbi.nlm.nih.gov/pubmed?term=">Journal</column>
	        <column xPath="PubmedArticle/MedlineCitation/MedlineJournalInfo/NlmUniqueID" type="element" linkPrefix="none">NLM ID</column>
	        <column xPath="PubmedArticle/MedlineCitation/Article/ArticleTitle" type="element" linkPrefix="none">Article Title</column>
	        <column xPath="PubmedArticle/MedlineCitation/Article/Abstract/AbstractText" type="element" linkPrefix="none">Abstract</column>
	        <column xPath="PubmedArticle/MedlineCitation/Article/Language" type="element" linkPrefix="none">Language</column>
	    </spreadsheetHeader>
	</config>

Call for articles: Music information retrieval (MIR) special issue

_OCLC Systems & Services: International Digital Library Perspectives_ (OSS:IDLP) will be publishing a special issue on music information retrieval (MIR) and libraries. The editor is looking for articles that articulate the planning, development, testing, systems work, marketing, etc. related to MIR, as well as the challenges of providing access to MIR materials. Articles can be of any length, and figures and screen shots are encouraged. OSS:IDLP is a peer-reviewed journal.

If you are interested in contributing, please send the editor your name, a short proposal of the topic, and a tentative title for the article. Deadline for proposals is September 1, 2010. Articles would be due to the editor by February 1, 2011. Any questions and proposal should be directed to the editor, not to this listserv. Thank you.

Dr. Brad Eden
Editor, _OCLC Systems & Services: International Digital Library Perspectives_
Associate University Librarian for Technical Services and Scholarly Communication
University of California, Santa Barbara
eden@library.ucsb.edu

If you're hosting your own WordPress site, Noteflight integrates with WordPress in a couple of exciting ways. First, we now support single-signon between WordPress and Noteflight Learning Edition. This means you can set up a Learning Edition community with Noteflight, and let every user on your WordPress site seamlessly access a matching account on Learning Edition without ever needing to sign in separately. All your WordPress users will also be able to see scores shared within that community. Second, Noteflight supports a nifty standard called OEmbed, that allows you to simply paste a Noteflight score link into WordPress and have the embedded score appear as if by magic. (You have to configure your WordPress site to tell it that this is OK.)

When I test this out, I'll post on this topic again. But for now I really just needed to put this on my blog to have a record of this news, given that I'd already forgotten that it was in my email box.

The article is a little overview of AudioRegent and SimpleADL and how they are utilized at the University of Alabama Libraries, where I work.

from http://journal.code4lib.org/mission:

"The Code4Lib Journal exists to foster community and share information among those interested in the intersection of libraries, technology, and the future."

Therefore, if anyone's linked to or bookmarked any graphics, PDF, or XML files, etc. offered on this blog, your old links will be broken.

In other words, a file called "foo.txt" that had been at

http://blog.humaneguitarist.org/wp-content/uploads/foo.txt

would now be located at

http://blog.humaneguitarist.org/uploads/foo.txt

All links to these files within my blog posts themselves should now be correctly updated.

I'm sorry for any inconvenience.

MXMLiszt is a web-based delivery and search/retrieval environment for MusicXML files and their manifestations.

MXMLiszt was created in order to complete a Master’s in Library and Information Science at the University of Alabama under the direction of Dr. Steven L. MacCall.

The documentation and source-code download links are available here.

The accompanying research paper, “Beyond Images: Encoding Music for Access and Retrieval” can be accessed here.

As of June, 2010 the live demo of MXMLiszt can be accessed at:

http://opensourcelibrarian.org/MXMLiszt

MXMLiszt is licensed under the BSD software license.

Conference sightings!

(by Valentin Villenave)

Reinhold appeared at the Linux Audio Conference in Utrecht / Netherlands, presenting two papers:

• R. Kainhofer: A MusicXML Test Suite and a Discussion of Issues in MusicXML
• R. Kainhofer: OrchestralLily: A Package for Professional Music Publishing with LilyPond and LaTeX

Kainhofer wrote the musicxml2ly Python script that comes bundled with Lilypond.

This morning I read the first paper:

R. Kainhofer: A MusicXML Test Suite and a Discussion of Issues in MusicXML 2.0, Proceedings of the LAC 2010 Conference, Utrecht, 2010.

It was great. Although I would really need to known MusicXML 2.0 from memory to pick up on everything, the paper discusses some tests regarding MusicXML 2.0 and discusses some of its current limitations and the effect on import/export from other notation applications. He also discusses how  some of the format’s ambiguities create problems in trying to convert MusicXML to Lilypond.

Anyone who’s worked with MusicXML and several GUI notation apps probably knows that there are some rendering inconsistencies across different GUI music notation apps and it was good to get a better idea of the reasons behind this.

Also of interest was, from what I can gather, the limitations that the original DTD for MusicXML has imposed on MusicXML 2.0 which using an XSD schema – as backwards compatibility with earlier incarnations of MusicXML is desired. That is to say limitations of the DTD are inherited by the XSD.

Kainhofer offers some suggestions regarding any upcoming incarnations of MusicXML to deal with some of the aformentioned rendering problems as well as programmatic difficulties that arise in the occasional cases where MusicXML isn’t as explicit as it perhaps could be.

Far from a landslide of criticism however, Kainhofer concludes with this:

MusicXML is a very useful format for the extremely hard and complex task of music notation exchange. As the OSF specication has already shown, one can expect that future versions of MusicXML will clarify, solve or at least soften most of the issues we discuss here.

ps: OSF refers to the Open Score Format: http://openscoreformat.sourceforge.net/

In the past I’ve used the W3C’s Amaya editor to write the HTML documentation for AudioRegent but that’s a really laborious process and requires a good bit of coding by hand even as I worked with the WYSIWYG environment.

So this time I just decided to use OpenOffice. Problem is when I did a Save As to HTML, the W3C’s Validator was giving me nearly 300 errors. Even worse is that the export was exporting the .html file and all the images in the document to the same directory. Boo. Ideally, the images should be in a subfolder for compartmentalization purposes.

Here’s what worked better: instead of saving to HTML, I used the File>Preview in Web Browser option in OpenOffice. Since Firefox is my default browser, it opened in Firefox. Then I just Firefox’s Save Page As option using the Web Page, complete type. Firefox saved the file (let’s call it "foo") as foo.htm and created a folder called "foo" that contained all the images. Sweet!

This time: only 13 errors from the WC3s’ p.o.v., all very minor errors – who knows where the other ~275 went?!

One way to cut down on errors is to make sure any image you embed in your OpenOffice .odt document has an alternative (alt) text attribute since that attribute is technically required for all images in HTML docs.

I should mention that it’s better to do this from a Linux box rather than Windows as the former uses the UTF-8 encoding and the latter Windows-1252. That’s no huge deal for non-critical documents, but it’s probably better to go with UTF-8 if you can.

Now I’m not going to waste my time hand-correcting a perfectly "valid" HTML doc for things like this. That’s mistaking the cart for the horse. I’m just an average dude trying to share some info with some folks. I’m not an institution charged with a preservation mindset. These WordPress blog entries aren’t valid either BTW …

I realize the importance of standards and sustainability but the Open Document format (foo.odt) is what I would argue is the thing to save, the HTML version being just a convenient manifestation. Secondly, if all major browsers have no trouble with the document, then from a certain p.o.v. the HTML is valid. In a sense, it’s much ado about nothing.

ps: If you’re wondering about exporting to xHTML, don’t.

… that’s a much bigger pain.

If anyone out there knows anything about this, please post a comment or drop me a line.

It just seems to me that a couple of things are happening that create major problems:

1. so called "best practices" often seem to be born more out of individualistic grant-receiving concerns than they are of truly getting several institutions on-board with effective, affordable, and shared approaches to workflows

and

2. an industry so concerned with standards and organization seems to have such little concern for organizing a do-able approach to ensure certain standards – and those "best" practices – get met in a relatively easy and affordable way.

So if there isn’t already, why isn’t there major activity to develop a Linux distro specifically for digital library functions?

If that were the case, couldn’t some of these "best" practices actually get built into the very OS people use?

All the scanning, audio-video, metadata, and delivery applications could be integrated within the OS, ensuring compatibility for whatever institutions use it.

Lists of compatible scanners and A/V equipment could get published, ensuring that people will buy equipment that will run on the OS.

Software updates could me made and get implemented in real-time across institutions.

Using all open-source software could standardize technical metadata outputs and save institutions lots of time/money – allowing them to pay for better and more talented employees.

Etc, etc, etc.

You could even call it LibOS* and use an image of Tux making a libary-shushing pose!

Maybe it’s time to stop paying lip service to collaboration and really get things moving.

"It’s the operating system, Stupid!"

*BTW: MIT appears to have had a late 90’s project that used the term LibOS, but it’s something totally different.