[sword-devel] Bible Resource Identifiers

Tue Apr 6 00:31:15 MST 2010

Thanks for the response, Karl. Responses appear inline below:

On Sat, Apr 3, 2010 at 5:34 PM, Karl Kleinpaste <karl at kleinpaste.org> wrote:

> As a deeply network-centric person, I am always uncomfortable with any
> specification that includes phrases such as "use the closest server,"
> because the concept of "close" is effectively moot, particularly in the
> face of VPNs.  I am near Pittsburgh, but also routinely VPN'd to/through
> a site in Germany -- define "close" for me in any meaningful sense.  Am
> I "close" to a reference site for the Bible named "Hoffnung feur alle"?
> Net.topologically speaking, yes, I am, but physical packet-hop-wise, no,
> I'm not...and just try convincing any network path optimizer of that
> fact, considering that the VPN keeps it from seeing the first dozen
> hops.  Better would be "use the fastest," because that at least can be
> objectively tested, but speed at that level is primarily a concern when
> there will be bulk data transfer.  I have a strong sense that these
> sorts of queries are intended to generate short responses.
>

Good point; yes, instead of “closest” a better term would be “fastest”. I
had in mind the concept of mirrored-server selection when downloading
something from Sourceforge, for example. The selection of an scripture API
server would be dependent on a few factors, including speed, authorization,
and the number of works that the server makes available.

At present, and as far as I'm aware, no Sword Project application has a
> facility to link directly outside the local machine.  That is, for those
> which grasp sword://, it is interpreted exclusively within the universe
> of texts locally installed, and (I could be wrong here, but...) none of
> the apps is prepared to make arbitrary network accesses on the basis of
> http://.  At the moment, Xiphos treats bible:// as equivalent to
> sword://; the code to do so is very old, and pre-dates my participation
> -- this would be easily correctable for another purpose, of course.
>

I didn't think any SWORD Project currently supported dynamically loading in
content from a web server, but I think it could be a compelling feature and
would potentially make a lot more content available to users.

I suppose what concerns me most about the offered mechanism is the
> numerous formats and their qualifiers and what appears to be the
> seriously complicated interpretations by which to return results based
> on them.  I haven't had the time to watch the video yet, but how much of
> this query syntax is already, say, coded and supportable?  (I am only
> dimly aware of Open Scriptures.)  I saw in the web page TODO that you
> don't yet have a formal grammar, and I have a sense, somewhat
> incomplete, that there is considerable ambiguity in such matters as ';'
> -vs- '|' especially when combined.  It almost seems silly to ask, but is
> there operator precedence?
>

Although a formal grammar hasn't been written and the URI structure is still
a working draft, each operator has been assigned an unambiguous meaning. So
there is a grammar, it's just not fully formalized into a parser.

A comma “,” separates passages within a work:
/passage/NIV:John.3.15-John.3.16,Matt.5.1

The semicolon “;” merely separates passages from different works:
/passage/NIV:John.1.3-John.3;KJV:Matt.1

A pipe “|” separates a list of passages on the left with a list of works on
the right; it's purpose is to indicate that the parallel passages from the
works listed on the right should be obtained for the passages on the left.
The following would return Psalm 3:1 in KJV along with its parallel passages
in the LXX and Tanakh (which happen to use the reference Psalm 3:1):
/passage/KJV:Psalm.3.2|LXX;MT

And finally, the forward slash “/” is similar to the pipe in that it relates
to corresponding passages, but instead of returning both passages in
parallel, it only returns the passage from the work listed after the slash.
This passages to be retrieved from a work using the reference system of
another (in the following example, the passage returned would be from Psalm
3:1 in the LXX):
/passage/KJV:Psalm.3.2/LXX

So the pipe and slash operators allow a passage to be queried using whatever
reference system the user is familiar with and it addresses the issue of
works using different reference systems. In the example provided by Brian
Fernandes (on Sat, Apr 3, 2010 at 8:42 PM):

Also, if a comma is used in the module part, it indicates an additional
> module for which you want the same content in a side-by-side view (locally
> implemented, not yet released).
> e.g. bible://acv,esv,kjv/gen.1
>

If I compose the URI: bible://KJV,LXX/Psalm.3.1 The result would not be a
parallel passage, but two completely different passages, since the native
reference systems don't completely align as noted above. But instead if I do
something like bible://KJV:Psalm.3.1|LXX then I know that I'm getting a
verse using the KJV system I know along with whatever the equivalent passage
is in the LXX. So the example above could be rewritten like this:
bible://KJV:Gen.1|ACV;ESV

Even while seeing some amount of value in most of the offered samples
> (though "token/23" seriously freaks me out), how much of this API can be
> expected to be put into day-to-day practical use, and within what sorts
> of user applications?  I'm looking for practical use cases that would
> apply to our (that is, Xiphos') users particularly, just because that's
> where I live, to decide whether it makes sense to expend the effort to
> glue an API of this sort into it.
>

The URI /work/ESV.2001/token/23 is one which references the 23rd token in
that work. These URIs would not be used by end-users but rather would be
used for Linked Data to connect the tokens in one work to the tokens in
another (e.g. for parallel passage lookups or retrieving a passage from a
work using the reference system of another: versification system
independence). The /passage/* queries, however, would be much more directly
useful; they're just extended osisIDs after all.

Thoughts?

Thanks!
Weston

>
> Just ruminating...
>
> --karl
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>

On Sat, Apr 3, 2010 at 8:42 PM, Brian Fernandes
<infernalproteus at gmail.com>wrote:

> FireBible started off with bible:// but later versions supported sword://
> too. Both are identical, but by default I generate bible:// URIs when you
> use the bible toolbar (so specifically when looking up a bible - for legacy
> purposes) and sword:// URIs in all other cases. However, if you replace
> bible with sword or vice-versa, everything still works.
>
> FireBible does in inherit all the JSword key parsing goodness, but I don't
> support any other *protocols* since each must be implemented in FireFox. So
> sword://greeekhebrew/0032 works, as does bible://acv/Lev.3-4,Gen.1.5-ff with
> the latter part being wholly parsed by JSword. The module reference ("acv")
> in this case can be omitted in which case the currently selected bible in
> the toolbar will be used, if none present than the "default" bible as
> specified in the preferences.
>
> Also, if a comma is used in the module part, it indicates an additional
> module for which you want the same content in a side-by-side view (locally
> implemented, not yet released).
> e.g. bible://acv,esv,kjv/gen.1
>
>
> >I'd suggest that in sword://module/key that module be allowed to be an
> abstract reference, such as >sword://Bible.en.KJV.*/key (type.lang.v11n.any)
> or as sword://Dict.strong.*/key.
> This sounds like a good idea.
>
> I will be putting these details on the wiki shortly.
>
> Brian.
>
>
>
> On 03/04/10 8:13 PM, DM Smith wrote:
>
>> On 04/03/2010 02:35 AM, David Haslam wrote:
>>
>>> FireBible recognizes both "sword:" and "bible:" as identifiers.
>>>
>>> David
>>>
>> FireBible, since it is based on JSword, probably also recognizes some
>> others based upon type, e.g. dict: as in dict://word.
>>
>> These are not standard, but are based upon a need to allow for general
>> purpose lookup based upon type. This is what bible: is.
>>
>> We've discussed the need for type based lookups but I don't recall coming
>> to a conclusion.
>>
>> There is also a need to be able to specify a particular versification for
>> bible:// where the user does not care about the particular bible that is
>> used.
>>
>> It might also be good to be able to specify a particular language or
>> perhaps any other attribute of a module specified in the conf. Kind of an
>> sql specifier.
>>
>> I'd suggest that in sword://module/key that module be allowed to be an
>> abstract reference, such as sword://Bible.en.KJV.*/key (type.lang.v11n.any)
>> or as sword://Dict.strong.*/key.
>>
>> I think the semantic should be look for a preferred match, if any, and use
>> the "best" match otherwise.
>>
>> In Him,
>>    DM
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100406/c2bc30d9/attachment-0001.html>