Category Archives: Uni Hamburg

Alles, was in Zusammenhang mit der Uni Hamburg steht.

Schall & Rauch

I have just fixed a bug for the library’s database of the Musical Insitute of the University of Hamburg. The bug was introduced with an update to a new php version on the server side of the university. When solving their issue I also fixed an issue that prevented my Schall & Rauch iPhone app from working correctly. So for everyone who is using the app – it’s back to life!

Happy searching to everyone : )

Tuning Search Results [part I]

A short overview of steps to be taken to improve the display of search results within EDsync.

There have been complaints about the usability/usefulness of EDsync’s search. As I wasn’t happy with the search myself I have disabled the feature with one of the earlier versions. I left the choice upon the users to decide whether to reenable the search and take it as it was. In this post I want to explain how searching the GBV catalogues works and how I am implementing it while getting ready an improved version of the search feature for a future version of EDsync.

Good news first:

  • All libraries within the GBV are using the same schema to search their catalogues.
  • There is an xml interface to retrieve search results. It is described in a wiki page of the GBV. The state of the interface is said to be “experimental” and “in development”
  • Yes, it’s xml!

Bad news:

  • The API you may talk to in order to get down to the search results is rudimentary.
  • The xml values are intended to be displayed in a browser recognising the values’ encoding or require you to be at least aware of the values’ string encoding (multiple encodings in different libraries)
  • There is exactly one relevant value within the xml.
  • This one relevant value is the grand concatenation of all values you’d wish to be separate ones

Now let’s not monkey around but get into the matter.

To get a list of results, the GBV wiki suggests to make a call on the servers in the following format:

The DB is the library’s database you want to search in (here a cached example for Hamburg – in case they move it again). The  XML=1.0 indicates that xml output is activated. The Action ACT is a search. The IKT (whatever it may stand for) is decoded here for the university of Hamburg. We’re sorting SRT by YOP, the year of publication and the search term TRM is ‘linux’.

This is a real life example.

As a result we receive something like this:
<?xml version="1.0" encoding="UTF-8" ?> // this looks good
<SESSIONVAR name="SID">989d11c0-3</SESSIONVAR>

<SESSIONVAR name="TITLE">Campus-Katalog+Hamburg</SESSIONVAR>
<SET nr="12" type="0" hits="577" >

<SHORTTITLE nr="1" PPN="642805822" matstring="MAT_B" matcode="Aaua"
format="text" available="no">SOFSEM 2011 : theory and practice of computer science : 37th Conference on Current Trends in Theory and Practice of Computer Science, Nový Smokovec, Slovakia, January 22-28, 2011 ; proceedings
<br />
// IMHO, this is marmelade
/ Ivana Černá. - Heidelberg [u.a.] : Springer, 2011</SHORTTITLE>

<SHORTTITLE nr="2" PPN="633913847" matstring="MAT_B" matcode="Aaukf"
format="text" available="no">Multicore application programming : f ...

I said this:

<?xml version="1.0" encoding="UTF-8" ?>

looked good. Except, in other libraries it may — look like this:

<?xml version="1.0" encoding="ISO-8859-1" ?>

That’s not so good. It reminds me of Switzerland. At best you speak German, French and Italian and if you want to be a good citizen please take Rhaeto-Romanic lessons, too. As a matter of fact, to get back to searching, it forced me to introduce a new attribute to my library objects, holding the string encoding. Each library object is now aware of the encoding it has to apply to its search result lists.

To summarise, by now we have all information from <SHORTTITLE nr="1" PPN="642805822" matstring="MAT_B" matcode="Aaua"
format="text" available="no">
and some arbitrary text containing html tags. The attributes of SHORTTITLE will have great importance when it comes to retrieving the details for a given search result item in the list and well, the text will be used as the title of each result in our result list. As I just mentioned the attributes are of special interest. We have the PPN as well as the nr, which I will refer to as the index in the following. We could search for the PPN to fetch a single search result for further information retrieval but the index comes in very handy as I will show you now.

When you search for a term in the catalogue, it will try to place some cookies. These cookies contain the database you were searching and it also remembers the search itself. This is when a prominent role is assigned to the index. We can now use SHW?FRST=index to obtain the detail page for the given index.

It outputs something like this:
...<TR>PPN: <TD>585163421<a href=‘/DB=1/PPNSET?PPN=585163421’ target=_blank><img src=”” style=”margin-left:10px;” alt=”Zitierlink” title=”Zitierlink” border=”0″></a><br /><TR>Titel: <TD>Linux Hochverfügbarkeit : Einsatzszen

aal 1: TI - Technische Informatik<TR>Signatur: <TD>TIH-800
<br />

<TR>Ausleihstatus: <TD>Ausleihbestand></a><entliehen...

Actually <TR> and <TD> look like &lt;TR&gt; and &lt;TD&gt; as we receive them.  The <a href=’/DB=1/P is something like &lt;a href=’/DB=1/P. We can also observe that many <TR> tags are preceded by <br /> which is actually received like that. Anyone familiar with html will recognise the <table> elements of table row (<tr>) and table data (<td>) tags as well a hyperlink starting with <a href=… So we ask ourselves: how come? And why for gods sake? Especially, what’s the matter with some tags having a cryptic form like &lt;TR&gt; and other ones looking like <br />. To be true to you – I have no clue (yes I do, but leave it like this for now ;)). But I guess all data is processed at least twice. Once when it is retrieved from the database and a second time when the xml is produced. I have reasons to believe that the <br /> are introduced in the latter process.

However, we have to assume that someone has hacked the information of a media item into a database. We would assume that there is some kind of a form the librarian fills out and submits it to the database. This form may define fields detailing the title, the isbn, the author, and so on. Let’s name this form or application that is used to gather these infos winIBW and the language used to specify the entries in the form PICA. So all information is stored into  separate database fields in their pure beauty. Of course, it would be a lot of overhead to request an xml containing all possible fields for each single search result. Instead I would suggest either an API to ask for specified fields or a xml containing field values as a stack of key/value pairs for each relevant (not empty & relevant for display) database field. It might look like this:

<?xml version="1.0" encoding="UTF-8" ?>
......<DESCRIPTION>This is some info about the author</DESCRIPTION>
......<CONTENT>Neal Stephenson</CONTENT>
......<DESCRIPTION>This is some info about the title</DESCRIPTION>

We could easily generate tableview cells, for example.

do Create tableview cell: "FIELDNAME: CONTENT"

At this point I should stop dreaming and get back to reality. I’ll call it the nasty xml reality.

Next time I’ll tell about my current efforts to make the search result details a bit more comforting in EDsync.

Schall & Rauch available on the App Store [update]

Schall & Rauch is now available to everyone on the App Store. The Institute for Music Studies of the department of Philology of the University of Hamburg has granted permit to access their databases. What a pleasure!

Schall & Rauch allows you to search in the 3 different music databases of the Schallarchiv, the institute’s library. You can find shelf marks and create local copies of search results as bookmarks. These are then available to you even if you don’t have access to the internet.

The app is free of ads and can be yours for €0.79. Have a look on the App Store:

[update] His highness has set the price to free just before christmas 2010.

EDsync SKU 001 go for Version 1.1

So then, it’s October. My journey to south east asia is over but the problems that need solutions stay the same (South east asia is still the same too by the way). So the time came to find the solutions and it’s even better than this. New features are being introduced. Only resolving problems after a (self) rejected binary upload can’t be the goal. It was my duty to not only make the binary working but to improve the whole version.

At a point when everything actually did work as I had wanted it to work I began thinking about a new feature. A very cool feature indeed. As you might not be familiar with EDsync I will shortly explain. In EDsync you can sync your libraries account with the App. This means you will be able to see all your loans and charges in the App. If you choose to view a loan in the loan detail view you can tap on the library row and EDsync will display the library on a MKMapKit map. A few weeks ago I wrote elbedev bib item parser (more about elbedev bib item parser can be found here), a small mac application that reads in a html page with a list of links to libraries and accumulates any information about those libraries into a xml file. This xml file can be used directly to identify the library a book was loaned from in EDsync. So I put that xml containing all the information about the libraries into EDsync and let EDsync do the connection between the library info and the loan. BUT – bib item parser does fail at certain times during its short uptime. At this time bad latitudes & longitudes are being exposed to EDsync… This means there are 200 or so libraries available in Edsync of which ‘some’ may contain wrong data. As I can only check on each one by one I wanted to provide myself a way to maintain the libraries at any time. This is where the new feature comes into play. It allows me to update the data of each single library whenever (actually from wherever) I want to. I am now able to update a server based xml file to make changes to or to add new libraries in EDsync. The App will check on each launch for an update of its libraries. An update will of course only occur if there is an internet connection and as I do versioning of the libraries, only libraries that have actually changed will be updated. As a minimum about 3 kb have to be downloaded from the internet to check for an update. I think this is very fair regarding the connection might be detached from within a mobile network.

Now come on review team, hit it!

25%, one baby returned

Yesterday or the day before yesterday I had to reject the EDsync Update‘s binary on iTunesConnect. I was happily playing with the catalog search when I recognised that displaying a search result detail once makes the search always showing this single detail for any selected search result. This mistake has slipped through as I am not testing on the searchresults’ contents but only on certain parameters passed by the interacting objects. Well the bug could be fixed very fast but as I fixed the bug I suddenly felt uncomfortable with the overall architecture of the search. In the binary I sent to Apple there was one class handling a holy lot of things. It was a god class being responsible for displaying the main menu’s items and also responding to delegate methods of UISearchbar and UISearchDisplayController. It is Apple’s intention (see the overview) that a TableViewController will also serve as a searchDisplayController but in my case one class being capable of all these delegate methods is making it too confusing. As a tableView delegate it has to differentiate between being in search mode or in the usual tableView mode each time and for all the delegate methods. This is annoying. The more time I spent separating each functionality to its own class the more I  got convinced that I should implement the whole searchUI by myself as I had done it in Schall & Rauch. So this is what it is going to be for now.

Ok, 25%… as I just explained 50% of submitting 2 Apps are already gone. So there is 50% left for Schall & Rauch. Apple has started reviewing it and I am very exited about the results… it’s been at the reviewers hands for 36 hours now :b


My babies have been sent away

I have sent both an update for EDsync for iPhone and Schall & Rauch to Apple today and yesterday respectively. Let’s see what the friendly guys at the App Review department will say this time. Both Apps are currently in “waiting for review” state. For EDsync for iPhone it took about a week (9 days, to be precise – burnt deep into my memory) to get the App approved. Including a little fix. At that time they complained about an iAd banner view displaying a error condition in one of the marketing screenshots.

As I mentioned in this note I wanted to sleep over a night or two for rethinking wether to return a simple xml file or a Apple .plist kind of xml file when retrieving search results on the server side. I preferred to take the plist as it is way easier to handle ( [plist valueForKey:SOME_KEY_CONSTANT]; ) than an NSXMLParserDelegate without the ability to apply xPath queries to the xml on iOS (Yes, there is a great library called touchXML that is doing good for EDsync).

Testing on the device revealed some performance issues with Schall & Rauch which were quite easy to fix. No big deals while testing which are making me feel a bit uneasy about the app review process…

For the interested ones – A page about EDsync for iPhone can be found here (german) as well as a page about Schall & Rauch (unofficial/preliminary and also german language). Have a look. Download it and push the button ;p

Schall und Rauch ready for Testing / Preview

After ten days of heavy development Schall und Rauch has reached a state of being ready to be sent to Apple. The following video (it’s flash. Happy Android users. Happy iPhone users – for having an iPhone, not for watching the video) will give you  an impression of the application’s capabilities. There are two main tasks left which are writing more unit tests/application tests and integrating iAd (the less time consuming+more comfortable task ;p)

Schall und Rauch Preview

Selection of a database

Entering search text


Displaying the results

Loading additional results

Showing result one result's details

Introducing Schall & Rauch

Startet a new iPhone project named Schall & Rauch.

It will be a mobile counterpart of the existing browserbased search for media held in the Schallarchiv library of the University of Hamburg.

The following features are planned so far:

– Search for media

– Bookmarking media and storing it in a favourites list

Work that has been done until now:

– php script that takes library name, searchstring, number of results, fields to search in as parameters, converts the request into a sql query and outputs the results as a xml file. Actually the file is kept in apples .plist format that can be easily read in. I don’t know whether to keep this format or switch to a usual xml and read it in with the NSXmlParser that is available on iOS… will sleep about it another night…