The Sabbath

Two parts of the article stand out. First:

For three decades, Talmud students have been able to use a Nexis-like CD search engine, the Responsa Project, created by Bar Ilan University in Israel…. Bar Ilan officials acknowledged that the CD had one major disadvantage: it cannot be accessed on the Sabbath, when much learning takes place. It also costs $790.

Of course it makes sense that you wouldn’t be able to use a digital study tool on the Sabbath; it had just never occurred to me. The evangelical analog might be having to use a print Bible in church instead of a mobile or projected version.

The Living Index

The second highlight from the article is:

Rabbi Benjamin Blech, professor of Talmud at Yeshiva University, said the rabbis believed that study should not be made too easy. “We want people to struggle with the text because by figuring it out you will have a deeper comprehension,” he said. “They wanted a living index, not a printed index.”

Bible software, websites, and apps are all working to create a “living index” (or at least a “responsive index”) of the Bible that lets you find comprehensive answers to every question that pops into your head while studying the Bible. But will this work devalue the actual experts (pastors and Bible teachers) who currently serve as living indexes?

The book The Lean Startup provides a framework for answering this question. It quotes Farbood Nivi, founder of test-preparation website Grockit:

“Whether you’re studying for the SAT or you’re studying for algebra, you study in one of three ways. You spend some time with experts, you spend some time on your own, and you spend some time with your peers. Grockit offers these three same formats of studying. What we do is we apply technology and algorithms to optimize those three forms.”

Or, in evangelical terms:

Bible software has historically augmented “time on your own” by tying together study materials: connecting documents to each other.

Recently, Bible software has expanded into “time with your peers” by mixing in the social layer that is enveloping the wider world of technology—“away from a web that connects documents together to a web that connects people together,” as Paul Adams puts it in his book Grouped. Bible software has three options when embedding social technologies: (1) Inject technology into existing offline practices (e.g., automating the irritating or the expensive); (2) Copy technology from secular sources (e.g., foursquare-style checkins); or (3) Come up with something new. The most likely outcome will involve a combination of these options.

Eventually, Bible software will delve into “time with experts,” as well, whether those experts are your local pastor or nationally recognized figures. Biblical Training is pioneering this approach in the field of Bible studies and theology, while Stanford and MIT are leading the way in other fields.

Will Bible software someday become an “expert” itself, giving you custom answers to your questions and a personal study plan? It’s certainly possible. Khan Academy is already disrupting math education and assessment. Someone will undoubtedly explore whether a similar approach works for Bible studies.

Of course, the open question is just how much we want Bible software to function as a living index; the rabbis who preferred that students “struggle” with text have a point that learning and wisdom come with effort. In a future where Bible software can provide time for you to study on your own, with peers, and with experts, I guess we’ll find out just how “easy” we want Bible study to become.

In a dozen new phone applications, whether faith-based or faith-bashing, the prospective debater is given a primer on the basic rules of engagement — how to parry the circular argument, the false dichotomy, the ad hominem attack, the straw man — and then coached on all the likely flashpoints of contention….

Users can scroll from topic to topic to prepare themselves or, in the heat of a dispute, search for the point at hand — and the perfect retort.

I expect that, eventually, we’ll just let our phones argue the basic questions of existence among themselves, and then they’ll let us know what they’ve decided.

In Redmond, Wash., a start-up called 3D Outlook Corp. this month will begin using software from NASA to sell 3-D models of mountains and other terrain priced at under $100, says Tom Gaskins, the company’s chief executive officer. Mr. Gaskins says hikers, resorts and real-estate firms are likely customers for 3-D maps and models that show the topographic contours of ski slopes, golf courses and other landscapes.

So you could, in theory, take Google Earth satellite and elevation data, combine it with the Bible geocoding data, and produce a custom 3D physical model of the Holy Land with key places labeled—or you could focus on one area, like Jerusalem, and show how it changed over time.

Or you could take a 3D model of Herod’s Temple and turn it into a 3D “printout.”

Anything you can represent in three dimensions—for example, the Ark of the Covenant or an ancient synagogue—can become a 3D model. In the future, I imagine technically minded Bible students producing a 3D model of something in the Bible, backed by research, as a final project in a class.

Imagine a 3D recreation of Nineveh in the time of Jonah. Or a complete reconstruction of a partially uncovered artifact uncovered on an archaeological dig. Or a way to recreate a variety of pottery vessels based on location and period (to help archaeology students familiarize themselves with identifying pottery from sherds—maybe you could “print” several vessels, then break them, mix up the remains, and have to identify the location and period of several sherds; it sounds like an interesting exam to me). Or a way for museums to share exact replicas of items in their collections with universities, so students can examine the items more closely than they can the originals. And if you break one? Just print another copy.

Obviously the possibilities extend beyond the realm of biblical studies, but affordable 3D printing opens a lot of intriguing doors. Hopefully it’ll get cheaper and more widespread soon.

About Microformats

Microformats are a way of marking up semantic data in HTML without inventing new elements or attributes. For example, here’s how you might mark up geographic coordinates:

<div class="geo">GEO: <span class="latitude">37.386013</span>, <span class="longitude">-122.082932</span></div>

In this way, computer programs can figure out without any ambiguity that the above sequence of numbers refers to latitude and longitude. Browsers, for example, might automatically link the coordinates to Google Maps or your mapping application of choice. Firefox 3 is evolving along these lines.

Bible Microformat

I’ve been thinking for a while about the best syntax to use for a Bible microformat. The problem I kept running into was in coming up with the One True Representation of a Bible verse (i.e., is it “John 3:16” or “Jn 3:16” or “John.3.16” or something else).

Sean neatly sidesteps the problem with a “good enough” solution. He proposes a format akin to the following:

<abbr class="bibleref" title="John 3:16">Jn 3:16</abbr>

The crucial aspect is that it doesn’t matter exactly how you specify the Bible verse—once you do the hard part of indicating that a string of text is a verse reference (the class="bibleref"), any decent reference parser should be able to figure out which verses you mean. It’s so simple it’s brilliant.

Now let’s push it a little further.

I suggest that the microformat should take advantage of the underused and, in this case, semantically more meaningful <cite> tag rather than the <abbr> tag. You are, after all, citing the Bible.

<cite class="bibleref">John 3:16</cite>

However, you also have to account for people who link the verse to their favorite online Bible. You could double-up the tags:

<a href="…"><cite class="bibleref">John 3:16</cite></a>

But it’s messier than need be. Since the practice of linking is widespread, why not overload the <a> tag with the appropriate class:

<a href="…" class="bibleref">John 3:16</a>

Both <cite> and <a> have a title attribute in which you can place a human- (and machine-) readable version of the verse if you choose. The title is optional as long as the verse reference is the only text inside the tag. Indeed, a title is required only if the element’s text is ambiguous (a verse without a chapter and book, for example, or completely unrelated text). (The practice of not recording duplicate information is the Don’t Repeat Yourself principle.) For example:

<p>God <a href="…" class="bibleref" title="John 3:16">loves</a> us.</p>

Corner Cases

So how would you specify a Bible translation if a specific translation were germane to the citation’s context? (In theory, when you don’t specify a translation, people consuming the microformat could choose to see the passage in the translation of their choice, similar to how some people prefer to look up an address in Google Maps, while others prefer Yahoo Maps.) I’m sympathetic to the OSIS practice of indicating the translation first, followed by the reference. For example:

<cite class="bibleref" title="ESV: John 3:16">Jn 3:16</cite>

This practice follows the logical progression of going from general to specific:

[Implied Language] → Translation → Book → Chapter → Verse

The title is also human-readable, though it departs from the standard practice of placing the translation identifier after the reference.

Sean mentions two other cases of note: verse ranges (e.g., “John 3:16-17”) and compound verses (e.g., “John 3:16, 18, 20”). Personally, I see no reason for a biblerefrange attribute as he suggests. A bible reference parser should be able to handle a continuous range as easily as a single verse.

But compound verses present a more complex problem. How do you mark them up? The above examples all stand on their own, which is one of the principles of microformats—you parse the element and get everything you need. But let’s say you have the text “John 3:16, 18.” Treating the range as a unit is easy:

<cite class="bibleref">John 3:16, 18</cite>

Any parser will handle that text; though it could be ambiguous (do you mean John 3:16 and John 18?), in practice it rarely is. But what if you mark them up separately?

<cite class="bibleref">John 3:16<cite>, <cite class="bibleref">18</cite>

In this case, the “18” doesn’t communicate enough information to the parser. The parser could maintain a state and know that the previous reference was to John 3:16, but state requirements increase the parser’s complexity, which in turn defeats the purpose of the microformat in the first place. In such cases, then, I would argue that a title attribute is necessary:

<cite class="bibleref">John 3:16<cite>, <cite class="bibleref" title="John 3:18">18</cite>

Putting It All Together

Here’s my Bible microformat proposal:

Citing a Bible Verse without Linking to It

<cite class="bibleref">[reference]</cite>

Citing a Bible Verse while Linking to It

<a class="bibleref">[reference]</a>

Citing a Bible Verse Indirectly (or When the Text Is Ambiguous) without Linking to It

<cite class="bibleref" title="[reference]">[any text]</cite>

Citing a Bible Verse Indirectly (or When the Link Text Is Ambiguous) while Linking to It

<a class="bibleref" title="[reference]">[any text]</a>

Verse Reference Format

The [reference] in the above examples refers to a machine-parsable and human-readable representation of a single verse, a range of verses, or a series of verses. You should use unambiguous abbreviations if you use abbreviations. See Appendix C in the OSIS spec (pdf) for a list of possible abbreviations.

When you’re in doubt about whether the reference text is parsable, use the title attribute to encode a fuller representation. In particular, when the reference doesn’t include all the text necessary to produce an unambiguous book/chapter/verse reference, place an unambiguous reference in title.

About the title Attribute

The title attribute, when present, takes precedence over the contents of the element (<cite> or <a>). When the title is not present, the contents of the element are assumed to be the verse reference. The title attribute contains an unambiguous machine-parsable representation of the verse reference.

The attribute can also contain an optional translation identifier at the beginning of the value, followed by a colon. Appendix D in the OSIS spec (pdf) has a list of translation identifiers. For example:

<cite title="ESV: John 3:16">…</cite>

To be comprehensive, you would ideally include a language identifier (e.g., “en:ESV: John 3:16”) before the translation identifier. I would argue that a language identifier is only necessary if you’re using a non-standard abbreviation.

However, you should only include a translation identifier if it is important that your readers see a particular translation or language. Otherwise, you should allow the parsing software to use your readers’ preferred translation and language.

Here is a Perl regex for allowed formats in the title. $1 is the optional language identifier. $2 is the optional translation identifier. $3 is the verse reference, which is deliberately wide-open to accommodate many different reference formats.

title="([\w\-]+:)?([\w\-]+:)?\s*([^"]+)"

Having been an English major, I keep trying to assign meaning to the line breaks—you pay close attention to line breaks when explicating poetry, and it’s hard to stop noticing them everywhere once you start noticing them in poetry. Live Ink has research to back up their reading claims; I’m not one to question their findings. So maybe I’m an anomaly, but studying the Bible in a similar format would distract me.

Speaking of things that distract me, a few years ago I came across an example (now lost on the hard drive of a deceased computer) of an interesting way of reading the Bible: one word at a time. The program cycles through the text of the Bible, showing you only one word on the screen—blink and you miss it. This Flash demo I just whipped up gives you the general idea:

You may need to read this post outside an RSS reader to see the demo. Not inclined? Here’s a screenshot. Picture the words rapidly scrolling upward:

Honestly, I can’t decide if it’s a good idea or a bad one. The hardest part for me is that it requires more sustained concentration than I usually devote to reading. It might be useful if someone could come up with an intuitive way to control the speed and allow time to blink. Like Live Ink, it may simply take some getting used to.

(The way the demo scrolls kind of reminds me of William Shatner’s line delivery in Star Trek—it pauses slightly on longer words, which was apparently the key to Shatner’s acting in the 1960s. Actually, the line breaks in the Live Ink screenshot above remind me of how he would read a box score, too. Maybe he was just ahead of his time.)

In the live application you can move around and highlight different photos taken from all sorts of angles. Check out the screencast if you’re hesitant about installing an ActiveX control on your computer.

I can see using this technology to reconstruct highly photographed places like Jerusalem in 3D. It’s not quite as good as building your own virtual-reality model of Jerusalem, but it’s a lot easier. Consider that flickr has about 9200 photos tagged “Jerusalem” under a Creative Commons license, and you can imagine the possibilities.

I look forward to being able to upload your own (or others’) photos and have the application create a space for you. Right now you can only use predefined photo collections.

Via Digital Media Minute.