Bibleref Revisited

[Weston Ruter]

This thread is introduced at http://groups.google.com/group/open-scriptures/browse_thread/thread/b0c262c3fc16cfdd

For some background, read Sean Boisen's work on Bibleref Markup: http://www.semanticbible.com/bibleref/bibleref-overview.html

Also listen to Stephen Smith's presentation at BibleTech and look at the accompanying slides (both should be posted shortly): http://bibletechconference.com/speakers.htm#StephenSmith-2009

We should discuss here why Bibleref hasn't taken off, and what we can do to improve it.

Stephen presented a few alternatives to Bibleref, and I think the one that holds the most promise is the URN (Uniform Resource Name) approach, that is, using hrefs with "bible:" as the protocol. However, since URNs are not yet implemented, I suggest using Purl.org as the resolver for these URNs until they are widely implemented. For example, I believe we could encode Bibleref URNs in Purl.org like this:

http://purl.org/OSIS/bible:ESV:Matt.5.6

This could then redirect to an OSIS resolver service that would present the user with a list of choices for where they could view the passage. Once they make a selection, their choice could be saved with a cookie so that future lookups would redirect immediately to the passage on their favorite Bible website. This would bring greater visibility to all Bible websites out there, both in terms of a user seeing what is out there and in terms of SEO. Developers who encode Bible references in this way would give users the ability to use which website they prefer when viewing Scripture.

What do you think?

[SeanB]

Interestingly, i sent Stephen Smith an email today with my thoughts
about why (as he correctly noted in his BibleTech talk) bibleref
markup hasn't really taken off.

There are several possible needs and user groups one might consider in
standardizing a scheme for annotating Scripture references. To me, the
most important one is the large body of bloggers, content publishers,
and web site developers who are publishing Bible references in their
web content, where a microformat approach (like bibleref) might enable
use to aggregate and learn from all that content. The critical issue
for this group is to make it dead simple.

About the same time as i was starting to promote bibleref, Logos came
out with their <a href="http://www.logos.com/reftagger">RefTagger</a>.
I concluded fairly quickly that, while there were some edge cases that
bibleref handled a little better, RefTagger provided a 90+% solution
with a very nice result and no on-going markup burden on content
creations: just put some javascript in your WordPress template etc.
and you're done.

I still believe in bibleref, more or less as initially proposed, as a
good compromise between lightweight demands on people and high
functional value in coverage of actual references. If you use bibleref
in your blogging (as i do), you get those benefits (and RefTagger will
recognize bibleref markup). But i think most users will prefer an
easier solution like RefTagger, and it's certainly seen much wider
adoption in the last year. I recognize that RefTagger doesn't meet the
needs of those who want to create links to other online Bible sites,
and it's not open source. I guess that's an opportunity for somebody
to create alternative tools. But i'm not sure how big an issue that is
for the average blogger who just wants to make it easy to identify
references on their site, and get a pop-up or hyperlink. The other
main thing that RefTagger lacks in my view is a way to generate static
markup: i hope Logos will add this capability in a future release.

So the biggest issue i see with your suggestion, and numerous other
similar ideas (including bibleref), is that it will likely prove very
hard to get widespread adoption. The burden goes on the content
providers, while the benefit only accrues to content consumers. So
there's a strong incentive for content publishers to make it as easy
on themselves as possible.

A different, and still unsolved, set of needs are the spidering,
aggregation and search of such markup: the jury's still out on that
one. <a href="http://www.openbible.info/blog/2008/03/yahoo-bibleref-
and-rdfa/">Stephen posed a good argument</a> a year ago as to why
moving toward RDFa might be the right solution: i don't know that i
have any more clarity now as to whether RDFa is picking up steam.

Sean

[Craig]

> For some background, read Sean Boisen's work on Bibleref Markup....
> Also listen to Stephen Smith's presentation at BibleTech...

>
> We should discuss here why Bibleref hasn't taken off, and what we can do to
> improve it.

This is a fine topic for discussion, but is unnecessary in the context
of Stephen's presentation. Stephen is talking about a format for the
exchange of annotations between programs (whether they be Web-based
like Bible Gateway or running directly on the client machine like
Logos). It doesn't address how the program itself stores or uses Bible
reference links, nor does it need to in order to be useful. It only
addresses how those programs should talk to each other.

If a Web-based program is somehow able to use one of these links
directly (that is, if the unmodified link as transmitted by our
program (PocketBible), Logos, or any other program happens to be
directly clickable to see the referenced BIble verse) that's great.
But it's not necessary. In fact, I would think that even that Web-
based Bible program would want to munge the link so that it resolves
to the verse within the BIble program instead of going to whatever
universally recognized target (such as purl.org as you describe) the
unmodified link would go to.

So for example, in our PocketBible program we use <a href="bible:Mat
5:6">linked text</a> to link to Bible passages within user
annotations. But when we export to Stephen's format we'd be happy to
change those to <a href="http://purl.org/OSIS/bible:ESV:Mat.5.6"> or
any other format the group agrees to. Similarly, when importing
annotations the user has created somewhere else, we'll convert the
standard links, regardless of their format, to the format we use
internally.

While solving whatever issues might remain in the BibleRef standard is
a great idea, spending any time doing this for the purpose of moving
Stephen's work along is unnecessary. Personally, I'm in favor of a
very simple format like <a href="bible:ESV:Matt.5.6">. Any application
that needs the link to point to a particular resource can very, very
easily do that as the annotation is imported.

Craig

[ed_dodds]

FWIW: The whole area of semantic web, taxonomy, ontology, vocabulary,
etc. is the subject of the upcoming 2009 Ontology Summit http://is.gd/nXo8
This summit initiative is co-organized by NIST, Ontolog, NCOR, NCBO,
OASIS, OMG, ISO TC 184/SC4, STI International, DERI & OAGi One of the
things I've noticed is that various communities of practice often fail
to query others about solutions they've attempted before launching out
on their own. re-reinventing of the wheel and other re-redundancies,
etc.

Just a thought.

Ed

[Dave Dunkin]

I think the discussion of Bibleref is necessary in the context of a
universal Bible annotation format because it is one of the more
promising options proposed by Stephen.

The problem I have with a bible URI is the fact that most common tools
do not support it. I think it's important that an annotated feed be
useful to common tools, such as a web browser or feed reader, without
needing transformation. That is, I want to be able to take a feed of
my notes from my online Bible, stick it in a sidebar on my blog using
whatever tools are already built into my blog software and have the
links point to something valid so they will be useful for readers of
my blog.

A PURL/OSIS URL seems like an interesting compromise but has the
disadvantage of not allowing vendor-specific links. For example, it
would be preferable for Logos that a feed of sermons from
sermons.logos.com have links to bible.logos.com. If a standard
specifies that links point somewhere else that may direct users to a
competitor, it is less likely that Logos would want to implement that
standard.

Bibleref seems like a good fit here because references can be marked
unambiguously and are machine readable, yet links can still point to
wherever the vendor or content provider wishes. I could put a sidebar
on my blog that consumes a feed of notes from the Bible website I use
and the Bibleref links would point back to that Bible website. A
mobile software package could consume that same feed and process the
Bibleref links so that they open within the mobile software. Notes
from the mobile software could be posted back to the website and the
Bibleref links would be translated from whatever the mobile software
uses to what the website uses. That's a win for everyone; the user
gets good integration between tools and the software vendors get links
back to themselves from other consumers of the feeds.

Dave

[Craig]

On Apr 2, 2:58 pm, Dave Dunkin <dave.dun...@gmail.com> wrote:
> I think the discussion of Bibleref is necessary in the context of a
> universal Bible annotation format because it is one of the more
> promising options proposed by Stephen.
>
> The problem I have with a bible URI is the fact that most common tools
> do not support it. I think it's important that an annotated feed be
> useful to common tools, such as a web browser or feed reader, without
> needing transformation. That is, I want to be able to take a feed of
> my notes from my online Bible, stick it in a sidebar on my blog using
> whatever tools are already built into my blog software and have the
> links point to something valid so they will be useful for readers of
> my blog.

Stephen's talk was about making annotations portable between various
applications (Web-based and otherwise).

While it would be interesting if a side-effect was that the sync feed
from a Web-based application would be directly readable and usable
(i.e. Bible links go somewhere) in a Web browser or browser-like
application, that's not a necessary feature. If it holds up the
discussion at all, it can and should be abandoned and that discussion
take place within a different context.

Consider, for example, moving notes (or highlights, bookmarks, etc.)
between Logos and BibleWorks. Neither of these applications reside on
the Web, and the stream of data moving between the two apps (however
that might happen) might never touch the Web. So what difference does
it make if the data (which the user will never see) has clickable
links in it?

If Bible Gateway or another online application wanted to have a
feature that allowed you to feed verses to a side-bar on your blog,
they might give you a number of link formats that would do different
things depending on how you wanted them to work. For example they
might embed the text of the Bible verse into the feed so that you
could pop it up with a little script or view it in a separate pane
somewhere. That link would look different than a link back to Bible
Gateway or a link to some application you have installed that
recognizes bible: links and shows you the verse. It would be much more
powerful to have a feature dedicated to this task than to settle for
taking whatever comes out of the synchronization function for display
on your blog.

Consider also that what would be part of a synchronization feed might
be only those items that have changed after a certain date/time, or
only items that are newer than a particular date/time. It would also
need to contain instructions for deleting items that have been deleted
on one side and need to be deleted on the other. The point is that the
purpose of this synchronization feed is not to update your side-bar,
but to synchronize your data between two applications. Those uses
(side-bar vs. sync) will be at odds with each other much of the time.

I don't object to the discussion of the relative strengths and
weaknesses of bibleRef and the possible use of Stephen's data transfer
functionality as a source for an RSS feed or blog side-bar. I am
concerned, however, about the co-opting of Stephen's useful idea
(portability of notes -- and by extension bookmarks and other user-
created, personalized data -- between Bible applications) and the
inevitable lengthy discussions that will arise on essentially off-
topic subjects that will derail the main purpose of this great idea.

I don't normally participate in these kinds of design-by-committee
discussions because they inevitably get bogged down by a desire for
everyone to have everything they ever wanted included in the
application and as a result nothing ever moves forward. Nobody wants
to tell anyone that they're off topic. I think feeding Bible notes to
your blog is an off-topic use of this proposed technology, and taking
time to resolve all the problems introduced by this unnecessary
requirement is just time wasted. I also think Bible Gateway should
implement this feature (that is, feeding your notes to your blog)
because it sounds like a cool idea. It is, however, unrelated to the
subject of Stephen's presentation.

Craig

[SeanB]

I agree in principle with Craig that portability of notes doesn't
<em>require</em> web-friendly annotation of Bible references. But if
portability does mean understanding and manipulating these references
(for example, to convert one book abbreviation scheme to another, or
selecting a different version because you don't have NIV on your
mobile phone), then the functionality required will overlap
substantially with what's needed for the web-situated applications as
well.So there's some possible synergy from thinking about both
together.

I have two procedural suggestions for going beyond Stephen's helpful
outline in his talk:
* identify the initial subset of functionality to cover. I'm assuming
that there may be a lot of different note features that software
applications provide, and a first approach might not support all of
them. So which ones?
* look at existing approaches as examples. There are lots of current
scenarios where one application imports bookmarks, contacts, etc. from
another one: there are doubtless some lessons to learn from how they
do it (and perhaps what they don't do)

Sean