God’s Word | our words
meaning, communication, & technology
following Jesus, the Word made flesh
January 31st, 2007

Better Programming Through … Less Programming?

Jeff Atwood has an interesting post, starting from some quotes from Bill Gates, on how to become a better programmer by not programming (yes, you read that right). It’s worth reading the whole thing, but here’s my spin on his bottom line: even if you have the skills and aptitude (of course, many don’t), what you need to get to the next level is not just more of the same, but an understanding of users and their problems, and a passion for solutions.
To me, this is just another application of one of Stephen Covey’s Seven Habits, Sharpen the Saw. At some point, more sawing doesn’t make you more productive: you’ve got to step back and think more broadly about what you’re doing and how to make it more productive (which might include going down to the hardware store for one of those new-fangled gas chain saws!).
(Hat tip to Jeremy Zawodny for the link)

January 25th, 2007

Visualizing Bible Data at Many Eyes

When i presented my work on the Composite Gospel Index at the 2005 SBL meeting, i included a number of treemaps showing different overviews and perspectives on the Gospel data. I put my slides on the web, but i was frustrated that i couldn’t share the treemaps themselves! The excellent Treemap software (from the HCIL group at the University of Maryland) that i used to create them is a desktop application. I could dump screenshots, but interactivity is one of the cool features of a treemap, so not being able to put the treemaps on the web (without a bunch of Java programming i didn’t know how to do) felt like a serious omission. It takes a lot more words to explain what quickly becomes clear when you have the visual (that’s why we do visualization!). (note there was some kind of problem with the data set i put there, which should now be fixed.)

So i was excited to learn about Many Eyes, a new site from some established researchers in infoviz that allows you to experiment with and share visualizations. You upload your data in a tab-delimited format with headers, and Many Eyes guesses the data types (currently just text and number). Once the data is stored, you can try any number of different visualizations, including several that go beyond the usual: bar charts, histograms, bubble charts, network diagrams, and treemaps. The visualizations can be published to their website so others can view and interact with them (or create new ones using your data set).
Here’s a linked graphic to a treemap that shows individual pericopes, grouped across gospels, colored by how many sources include that pericope (1-4 gospels), and sized by the number of verses (for each sources) that make up that pericope. So at the upper left is Pericope.122, “Jesus feeds five thousand”, which has the most verses of all the pericopes (since it occurs in all four gospels, and each gospel has a fairly lengthy description).

The coloring makes it easy to see which pericopes are common or unique among the Gospels: so one column over, 4th down is Pericope.119, “Jesus prepares the disciples for persecution”, the largest pericope source that is unique to an individual Gospel (though of course elements of this occur in the other Gospels: some might consider this particular instance an artifact of my methodology for dividing and grouping pericopes). In the next column to the right are Pericope.264, “Jesus condemns the religious leaders”, and Pericope.213, “Jesus tells the parable of the lost son”, both lengthy pericopes from a single source (and here i don’t think the data are vulnerable to the same criticism about my methodology).
You can also re-arrange the hierarchy and select different attributes for the treemap (though i can’t claim the data labels are obvious enough to make that easy!). Many Eyes doesn’t let you do everything the UMd Treemap software does: for example, i’ve found it helpful to color the individual pericope sources by their source gospel, but apparently you can only color by numeric fields, so that’s not possible with Many Eyes. But in my experience, simpler-yet-web-enabled often beats sophisticated-yet-trapped-on-my-desktop.
I’ve long been interested in information visualization, and in my new position at Logos Research Systems i’m hoping to have more opportunity to explore how visual presentation can people understand the Bible in new ways.

(Thanks to O’Reilly Radar for pointing out the Many Eyes site)

January 13th, 2007

Bible Mapping Sites

The ESV Blog had a post last week about BibleMap.org, a new interactive mapping application that combines the ESV Bible text, a Google Maps display, and articles from the International Standard Bible Encyclopedia (ISBE). So you can find a passage, click on the hyperlinks for place names, and see a satellite picture of e.g. where Nazareth is actually located (unfortunately, Google can’t show you what it looked like 2000 years ago!).
Of course, it’s wonderful that people are making these kinds of applications available: thinking about the place names in the Bible is an essential part of really understanding the context, though i suspect most Bible readers tend to simply gloss over them. This kind of tight integration can help bring the world of the Bible alive to modern readers.
Nevertheless, without faulting the creators of this site, i can’t help but wish for more:

  • This is a classic example of a stovepipe application: while it’s got a lot of useful data (linking verses to place names, place names to lat-longs, and place names to ISBE articles), all of that data is embedded in the application (the website) itself. That’s fine if all you want is to use it, but not if you want to re-use it. If instead there were a web service behind this, there could be multiple versions of this same basic capability, without having to re-engineer the basic data. I’ve ridden the hobby horse of data before applications before, and this is a basic tenet of Web 2.0 thinking. The most recent version of New Testament Names has some Google Earth data (which i used for this map in my SBL presentation) for just this reason, though (like BibleMap.org) it’s not complete.
  • I can easily guess why they chose the ISBE: it’s the most comprehensive Bible reference work in the public domain. But it’s not the most up-to-date (if it were, it probably wouldn’t be in the public domain!), and the depth of information sometimes goes well beyond what casual readers want. Which raises the fundamental question: what’s the right level of information for a reference like this? Most readers won’t care about proximity to modern archaeological sites, and would instead rather have basic information like best guesses as to how large a town was, prominent physical features, etc. Much of this information doesn’t exist in ISBE (or other resources, for that matter).
  • Once you start down the road of information integration (using hyperlinks or other mechanisms), you hate to stop. Wouldn’t it be great if the ISBE text itself was also hyperlinked with place names? The first part of the ISBE article on Nazareth reads

    “A town in Galilee, the home of Joseph. and the Virgin Mary, and for about 30 years the scene of the Saviour’s life (Matthew 2:23; Mark 1:9; Luke 2:39,51; 4:16, etc.). He was therefore called Jesus of Nazareth, although His birthplace was Bethlehem; …”

    Unsurprisingly, definitions for place names typically use other place names to put things in context. Without the hyperlinks here, the text becomes a bit of a dead-end.

  • Their display for John 1:28 shows a classic example of why simple string matching gets you most, but not quite all, of the way: Bethany isn’t the same as “Bethany beyond the Jordan”. Happily, there are few enough of these cases in the Bible texts that they can generally be fixed by hand: but having fixed them, that disambiguation becomes another critical piece of data that shouldn’t be stovepiped.
  • Viewing a little of the geographic context mostly leaves me wanting more. Back to my example of Nazareth: i’d like to see additional overlays of other towns (and of course, that’s specific to the context of a given passage) as well as other features like travel routes and named bodies of water, since showing that town alone doesn’t tell you much. There’s also the subtle issue of what’s the right zoom level: for Matt.4.13, you’d want the map to show both Nazareth and Capernaum, rather than being closely focused in on Nazareth alone.

It’s always easier to critique than to create, i know. My point is simply this: while these early integrations of open tools like Google Maps with Bible study applications are exciting, much more is still possible.

January 7th, 2007

A Framework for New Testament Knowledge

After my recent presentation on using Semantic Web technologies for capturing information about New Testament Names, i had the the opportunity to talk with Tim Bulkeley. My only previous interactions with Tim were through the blogosphere, so i was happy to make the connection in person. Tim mentioned his interest in creating a freely-available hypertext Bible dictionary, and wondered aloud about whether NTN might provide some initial help. After all, he pointed out, most of the entries in a typical Bible dictionary are things with names.

This made a light go on in my head. He’s right of course: the people, places, and other things designated by proper names are the most concretely referential things in the Bible. Named things are important for organizing the narrative: they give us a handle for the characters whose repeated appearances allow us to form a composite view from the individual passages that mention them. When extra-biblical sources are available to enrich our understanding of the background, the names are the links (e.g. the Herod in this passage is the same Herod described in Josephus). The very fact that they’re named tends to help them persist into later church tradition (whether historically based or not).

The light bulb for me came against the backdrop of my own dim sense of the value of NTN: what good are a bunch of OWL statements (even if you make them accessible in a browser like Longwell)? What i realized is that providing the skeleton for a dictionary (albeit a very non-traditional one) was an important use case i’d totally missed.

Suppose you were going to create a dictionary for the New Testament: where would you begin? You’ve got to decide what kinds of things it will cover: a basic background dictionary (Smith and Easton are older, now public domain examples) is quite different from a dictionary of theological terms. So let’s say for starters, you want to talk about people and places: since i’ve already got those in NTN, these form the index. You need to target an audience: my choice here would be the novice reader who’s just trying to understand the basic context, not the advanced academic. Let’s take Barnabas as an example entry: you’d want to say a little about his background, his relationships with other people (especially Paul and Mark), his activities (including his missionary travels). You’d back these comments up with Scripture references for the facts.

Well, many of these things are already in the structure of NTN, but with some important differences:

  • I haven’t included the scripture references. This isn’t too hard for a list of names, given a concordance (though there are some challenges with underspecified names like John that can refer to multiple people). That doesn’t capture all the pronominal references, which (for frequently mentioned people) can be substantial. And of course, no decent Bible dictionary includes all the references except for very sparsely mentioned individuals: otherwise they would overwhelm the other text in the entry.
  • Relationships to others are links without explanatory text (but this could be added)

Suppose you wanted to create your own dictionary, covering the same range of items but with different emphases: perhaps archaeological information about the places, or sociological analysis about individuals, or commentary by later Church Fathers on specific incidents. You’d still want to build on the same foundation of basic facts (it’s hard to start a discussion of Barnabas without some background), and then add your own facts and commentary. This has a natural expression in the Semantic Web framework:

  • You expand the topics of discussion by adding subclasses to the ontology: if the upper ontology is appropriately broad, this is just an extension (rather than starting over with a new ontology)
  • You add relationships with additional specificity or relevance to your emphasis (again, an extension, rather than starting over)
  • You simply omit from your presentation relationships that aren’t relevant: this is easily and mechanically done

This seems to open up a whole range of possibilities for building new resources.