[sword-devel] Bible Resource Identifiers

Sat Apr 3 10:51:34 MST 2010

Last weekend at BibleTech:2010 I also presented a standardized URI space for
addressing & accessing scripture.
Here's a draft with URI examples:
http://wiki.github.com/openscriptures/api/restful-uri-structure
Video of my talk: http://vimeo.com/10490211

Our idea is to implement this standard URI space on multiple API servers in
a scripture network; the result is that the same passage can be looked up on
the closest server and if its not available to be able to fallback to
another server; so the servers in the network would serve as mirrors for
some content. Other content would be restricted to certain servers; for
example, the NET Bible would reside on Bible.org's server; if a request was
made for the NET Bible on Crossway's server, it would redirect to the
Bible.org.

http://esv.example.com/passage/ESV:John.3.16
http://net.example.com/passage/NET:John.3.16
http://esv.example.com/passage/NET:John.3.16 ==>
http://net.example.com/passage/NET:John.3.16

With standardized URIs, not only can requests be redirected like this, but
scriptural passages on different servers can be unambiguously and precisely
linked together by these URIs; and API responses can aggregate content from
multiple locations. So lets say a request is made of the ESV and NET in
parallel:

http://esv.example.com/passage/ESV:John.3.16|NET

If the ESV server didn't have direct access to the NET, it can simply use
some kind of inclusion mechanism (e.g. XInclude) to notify the client that
it should load the NET content from another location; if it does have direct
access, it could pull in the sources from other servers and return the
aggregate response itself.

URI request & response examples:
http://github.com/openscriptures/api/tree/master/examples/

Obviously it would be very beneficial if both the internal SWORD frontend
URIs and the URIs used for Web APIs could be harmonized: URIs from inside
the SWORD frontend could then easily link out to URIs on the Web, and
visa-versa. Also, the Open Scriptures project aims to populate our
scriptural data models with various public domain texts as CrossWire has
done, and then to make the API and the populated data models available for
installation on any machine to serve as a local API server, e.g. when
offline; with shared standardized URIs, then the SWORD frontends could tie
in directly with the Open Scriptures API. Furthermore, if more and more
content providers make their content available via the Open Scriptures API
using standardized URIs, then SWORD frontends on user machines could
potentially have access to more restricted data because they could
communicate directly with the content owner with whom the user could have a
license key to gain access to their content. But everything hinges upon
having standard URIs.

So while the official SWORD URI standard is sword://module/key
The parallel URI space we are talking about could be be prefixed with the
“bible:” scheme, as Chris Little affirms. As such, the URIs in SWORD
frontends would technically be URNs which then get resolved to either the
internal SWORD engine, or externally to a URL on the Web:

URN bible:passage/NET:John.3.16  ==> URL
http://net.example.org/passage/NET:John.3.16

Thoughts?

Weston

Forwarded conversation
Subject: [sword-devel] Bible Resource Identifiers
------------------------

From: *Константин Маслюк* <kalemas at mail.ru>
Date: Fri, Apr 2, 2010 at 1:50 AM
To: SWORD Developers' Collaboration Forum <sword-devel at crosswire.org>

Hi all.

I've created http://www.crosswire.org/wiki/Frontends:URI_Standard for
discussing Bile uri's . If your frontend supports this , please
describe there , how.

Also it would be nice if SWORD take care of handling /  decode into
SWModule/SWKey.

Wish you the best.

_______________________________________________
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

----------
From: *David Haslam* <d.haslam at ukonline.co.uk>
Date: Fri, Apr 2, 2010 at 4:06 AM
To: sword-devel at crosswire.org

I have updated the wiki page a bit. Plus some useful wiki house-keeping.

I have also written to Brian to ask him to add the details for FireBible.

David
--
View this message in context:
http://n4.nabble.com/Bible-Resource-Identifiers-tp1748943p1749018.html
Sent from the SWORD Dev mailing list archive at Nabble.com.

----------
From: *Chris Little* <chrislit at crosswire.org>
Date: Fri, Apr 2, 2010 at 11:40 AM
To: SWORD Developers' Collaboration Forum <sword-devel at crosswire.org>

I think it important to point out that the official Sword URI standard, as
defined about 10 years ago and implemented to some extent in BibleCS at that
time, is basically:

sword://module/key

Adding an identical protocol handler for "bible:" is fine, and I'd even
encourage it, but "sword:" is the official and defined protocol.

--Chris

----------
From: *Karl Kleinpaste* <karl at kleinpaste.org>
Date: Fri, Apr 2, 2010 at 12:03 PM
To: sword-devel at crosswire.org

That's all that Xiphos generates internally, and most of the examples I
discussed with him in #sword the other day, which have now gone into the
wiki page, used sword://.

But Xiphos recognizes both, and installs handlers for both.

----------
From: *David Haslam* <d.haslam at ukonline.co.uk>
Date: Fri, Apr 2, 2010 at 11:35 PM
To: sword-devel at crosswire.org

FireBible recognizes both "sword:" and "bible:" as identifiers.

David
--
View this message in context:
http://n4.nabble.com/Bible-Resource-Identifiers-tp1748943p1749916.html

----------
From: *DM Smith* <dmsmith at crosswire.org>
Date: Sat, Apr 3, 2010 at 7:43 AM
To: SWORD Developers' Collaboration Forum <sword-devel at crosswire.org>
Cc: David Haslam <d.haslam at ukonline.co.uk>

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

----------
From: *DM Smith* <dmsmith at crosswire.org>
Date: Sat, Apr 3, 2010 at 7:58 AM
To: SWORD Developers' Collaboration Forum <sword-devel at crosswire.org>
Cc: David Haslam <d.haslam at ukonline.co.uk>

----------
From: *Jaak Ristioja* <Ristioja at gmail.com>
Date: Sat, Apr 3, 2010 at 9:55 AM
To: sword-devel at crosswire.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

When deciding whether to concentrate on the sword: URI or the bible: URI,
one should take
into consideration, that there is also other Bible software. Hence
specifying a bible: URI
should be an effort separate of the Sword Project. In the latter case we
should also
involve other interested parties in the discussion - both projects using
Sword and those
that don't.

Another thing to consider (especially for the bible: URI format) is that it
should stay
very stable over time and be general (but not bloated) enough so that
extensions to the
format will not break backward-compatibility as long as required before the
return of our
Lord.

Best regards!
Jaak Ristioja

PS: I strongly suggest you to pursue more important matters this time of the
year!
Especially this week! And especially these days of this week!
PPS: Don't use "//": http://www.google.ee/search?q=berners+double-slash
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQgcBAEBAgAGBQJLt3L0AAoJEFqwhAoGc/hvnlQ//1XUjn7nnu/6jRrLp2Lvze7v
m8M8GaGcLIP9rxuP3FzfOfLxWAY7rpzxEG+uXsmuUwGbkej7Zs7NrDppIQ5Dn85q
qmIj85d42hrmuZEiZpGMwjMTS2uhA+iiRD/tD6+yv3A5VQEDU73uFjC799xAuZ7a
/CGc1IXEeu3LTubkZEvk8rfW/EoukVboQ07zip4Ulliskwq4Dg/I1/qqzgmSxLhh
R5bCDe71iAa08nJTPg1rVbRie7pUfZoXeN8LagN46L1bsnTwEGRHKbkvZfue0WGw
236UMK0+w94HCQ6Xvqvht7HNjWs60fOV/0yc20m5UmTvvCzjIKBfueduse8FUBTa
eN56Pg9w+D+lgA6WpkibMVB1cM1x8KRZ+bCM5Paf7rNnRZD6fxm0KZ+fpOmxynsg
d/FwlMLzwNCFdSExXLH0L+/HPL3f3nSNGZWaSzqjtN6bCyXlhkSKxm/UHo98e2ZL
FIbBlg4DzainZeUcEVvnzVhrIiIU5uLhp/qMywjpi8vHMDgbswXC3ftN1+MGR4yr
opKnXIfhIkAL302h+9acETdp11A5E7/5trL62E+t/M/XR6iWGTZlSE0lmcrcJNed
1vLXBPftKJSzXOxxsFOoSUfcO+YAksMdjWIXL7yFvbWqqv7iM5n+OL2r1hRLs6ZR
Q7rpHgd22hGSeTTLFHlf/W/EoF3UQA7n7PbaJ4MOLxRqSBUQ8OvtfqwDce+z+FGx
wkRECIG66WplwwJHBvfIdT44FOqGChnHiHgRLavudEtv8CSFYsvMPQ8V9QGZb1Ad
fb2pFJexK1YYIyr8+9nux5Vjy0BB0KzkE8Yn+qx5dMGLSykMgHrBv2I1WD4CIMkL
JjDNgWxOJqXvgAcWVJj04/dkktFhefjFonbGQfpUdUTWS+aZGDLsleRGsoPCI8pa
p6b5FLU+iFJ+vhDwYp0s0UEkDiX8iSFXu/U9FPwes0Sjcj5AOZyVEw9+X2Tlvb/r
Fg6jdw9j7RsH/G1OtfOVSyxkEYvxgHTVrHjfYlfmS/aF4SYS9srmbGmKHBUyDZiK
0eMf+V4pZT4BatrubX2RTGG8AqoKl70AzwAJX+CSYLPh1fKlhkZbhZNOi8c5oogl
SCh90HoRI1dlR85rWEfutPZ1b8hfOE+pSODP4tLvBCgxcTytQECxNpDO04p+VhFA
ergnWXnqVeWhv9GHwVpCdJiSHKzYt5gX09d482de4UNDAm1pibeP/TTBt2vn9tU0
m8dG35IYNEp5vPQH34mVdI2dhBxT4/XyhX7FGAHS91MX4tZHUSODwqlrEIBV4Jeb
aStFVjf5lRqXqGc/BZQt8iE6X4tCSJsQWQDPco1TWxvlxcUig341M7lhIX8s1yff
EUZODuNCdeW9CmPrkp0XbQzK8pou7mNbq9EjBcpDjO7ItH+Ip47SNdZUJbpTtUbi
SLlwiNXhNp40Hj8lQAxitS271dZ6Q0HLwVuqgvv7gZkqIKQhh7Ya2myBlvrnTB6g
ONbcsZ8S8JSDP3/qFLn57TQfVD1Ww8Yg9KHRQTrFrHDrNbVhNqNAG0sBUxFcLXmg
PVJDjbEk4wzxSrsDYTNPusQRYUV09Tb+8AbqCcLkxM539/WrJuOh8gc3Forbxelk
dIr4D+zW0zRpc7QfRAgabt2NJ62JLoWFB6htirtPz/RZsRh+uLRRx7B14fl+KFSS
oR4dG8qqi2xtU3EKkubgnVgP4JQJB98VFsIFMeUqeNubC7CzanD8wy7h5rY63CrW
YCL00ZXcFc0fGpOehWvPA/rpjbsbySatSHa0Eo5Xy09cx3aaA/ZbP6+3T78ffu/X
uUJPTwsN6+HSsOKoe2OJ52tcPPxXb3kaxjshBw4H92qsPMu4hdZNDpo4Gn0ljSSU
2zvF6XhAFloL0b7BbFMoE5WbSsWbYwd0fJNNcXdrgd/LXNtIm7ffwViqyKP6sDzE
DrgIzEEOcFNiDDrhcA7WhxpERBwWr9DA9rDG2i78ykcsz0gAfh8t+b0JrZgkc+bc
QuiAgmjI56r3VnssbDouV79fv74NCrxIJKqZ9F2GF83wwNgdU3vH4ZeOIC6jvuU1
Jylp0X/NpbcU4Nn36cTGBfCUYsjL34dzVQF7c0KrNXUzfMowCSoH7YE1fU9gyi1q
UHgoqTutn2pxL2eyXrjcQMHZrGYMFvbEA58KidIl4dkRQCjGKXC4XGZ26Js8XuE5
14cVrMZydZiXKpnnRazyPQC9NtJukrfcYQ1CrfpLAFHl6o72yy8Fblw5xSf1nl6V
qFOZoyCxzifrxtGDqPj626RHRpYhL+Jp5dZOyURiy4EmEgVsQcN4hm1F15eA1MV2
TG3w714tm5+v8zcpl9QJtfQ9pv+oj3OGVL5c/xO3xcD32wo0wKMJfrOhFYwUkvnu
hc27Dki/zFWIGaPOq8uBj/TqjBqc8N1jCDaO7Y0TCLqYGcfdU7Ge8yQ6Kk0hMATn
/mPlYgRt/TnrRPlNSfRVKiWvhePC4+fw7kgqe3GWCl1ZSN581PRGprjR6AgT09Xz
ti8OdWIMBFX7AAIPvS7gi64Xu+M9YBZfozIN0il+Dcsg2CP/ByA1y7RGDRDQcRl9
EwLlVNkv63V7tzMTlMP5bHvlFDjZ2Zg20pmYuv+cGeEF6GKceTQcwFS4Ll9yr2Nc
TOvouCT1kwgial/lIfQ+ZFssYxOWHSUQWh4tL3JmC7meDH5AdRcKLZA1X5ODuat0
Oy1Szs3uCzJAx/KUG6rF
=GBze
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100403/f80ced8e/attachment.html>