Software Needs for a Language Documentation Project

In this post I take a look at some of the software needs of a language documentation team. One of my ongoing concerns of linguistic software development teams (like SIL International's Palaso or LSDev, or MPI's archive software group, or a host of other niche software products adapted from main stream open-source projects) is the approach they take in communicating how to use the various elements of their software together to create useful workflows for linguists participating in field research on minority languages. Many of these software development teams do not take the approach that potential software users coming to their website want to be oriented to how these software solutions work together to solve specific problems in the language documentation problem space. Now, it is true that every language documentation program is different and will have different goals and outputs, but many of these goals are the same across projects. New users to software want to know top level organizational assumptions made by software developers. That is, they want to evaluate how software will work in a given scenario (problem space) and to understand and make informed decisions based on the eco-system that the software will lead them into. This is not too unlike users asking which is better Android or iPhone, and then deciding what works not just with a given device but where they will buy their music, their digital books, and how they will get those digital assets to a new device, when the phone they are about to buy no-longer serves them. These digital consequences are not in the mind of every consumer... but they are nonetheless real consequences.
Continue reading

Network Needs for Poly-lingual Language Documentation Project

Network Diagram

Mephaa LangDoc Project Network Diagram

The diagram above roughly illustrates our network setup. This set-up might be typologically rare in terms of language documentation field stations for several reasons. But we had reasonable power (both in quality and quantity), though there were some power outages. And we had high-speed internet.

In terms of network set up there was the need for an internet direct out, so that we could have a team network, and then a separate network for language consultants, who would bring their own computers to have a “drop box with us”. To fill this need we could open our network to each of the consultants or we could use an outside service like Dropbox. – I am not sure why we did not use DropBox. Eventually we did use google spread sheets for collection word frames. Our consultants might have been atypical in that they also had their own computers and had some familiarity with computer use.

Single FLEx Datastore for all languages

MicrosoftSQL Server for running FLEx on the Network. This is achieved through running XP in a virtual machine via Virtualbox on the OSX Server. We have multi-able entry points of data to the “FLEx System”. We also did not completely solve the network access to the data bases. That is one person could access the database at a time with write access. Since this project the current version of FLEx has moved from a MicrosoftSQL Server Backend to an XML backend. But perhaps what would have been better was to use FLExBridge or LiftBridge.

Server and data store Backup

Best practice for backup calls for a three way backup plan.

  • An onsite backup.
  • An “across town” backup. Where a (at least weekly) backup is held by a friend or colleague across town.
  • And an out of country back-up.

This three way backup is to:

  1. Protect from mistakes or equipment failure.
  2. Protect from theft.
  3. Protect from catastrophic events.

Our onsite backup was handled by Time Machine.

We would switch out our Backup drive every week and give it to a colleague across town.

We attempted to use KKoncepts for our offsite backup. (KKoncepts did not work out because it was based on a simple rsync script and every time we tried to re-organize folders in our corpus it would try and re-sync all of the Gigabytes of data which lived under the folders.) The DropBox service is much more efficient and looks at the block level (inside the file) and only updates things that have changed. It then looks at the tree structure and mirrors what is currently on the clients computer, rather than re-uploading the content.

Not yet well defined are the network settings needed to run WindowsXP in the virtual machine, OS X, and Windows 7, establish a DNS server with AirPort Extreme.Note: Although the title/URL says “Multi-lingual” this is to be understood that multiple languages are being documented. The term poly-lingual also fits this particular project because the language of communication and authorship was Spanish, yet many of the network issues were resolved in English.

Merging iLife Libraries

The Problem:
One user on in a small business / family network can’t use (with metadata) all the media in a colleague’s or family member’s iTunes or iPhoto Library.

In our family there are three Macs (2 everyday machines and a server). On many work and personal tasks we function as a small workgroup. Unfortunately iTunes and iPhoto do not facilitate the sharing of media libraries (or for that matter the merging of media libraries). For instance, my wife had her own music and photo collection before we got married. Now if I want to browse that collection from my machine, there is iPhoto & iTunes sharing. But I can not add tags or other metadata to photos on her Mac. I can not create smart folders which we both can use.

For our music we moved my collection to the Server and made it like a “media center”. When we get new music we add it to the server. If we want a copy on our own machines we pull it as needed. i.e. for an iMove project. This solution has not allowed my wife to add her collection to the server, nor has it solved the manny duplicates which exist because we like many of the same songs. Now I have found a solution to this: PowerTunes.

Now the same problems exist for our photos. However, there is no real advantage (or software) for hosting the family photos on our sever. But we still need to define a photo capture strategy.

  • When we take new photos, to which computer are we going to download the photos?
  • Where will we have the master library?

I don’t have a complete solution to our photo capture, retention and access needs but iPhoto Library Manager is the only software out there that will let us maintain the metadata and merge our iPhoto Libraries. However, This is a fantastic first step strategy:

  • Consolidate the iPhoto Libraries.
  • Designate an computer to be the Master Library holder.
  • Share that iPhoto library across the network.
  • Back that computer up.