Last weekend at BibleTech:2010 I also presented a standardized URI space
for
addressing & accessing scripture. <br>Here's a draft with URI examples:
<a href="http://wiki.github.com/openscriptures/api/restful-uri-structure">http://wiki.github.com/openscriptures/api/restful-uri-structure</a><br>Video of my talk: <a href="http://vimeo.com/10490211">http://vimeo.com/10490211</a><br>
<br>
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.<br>
<br>
<a href="http://esv.example.com/passage/ESV:John.3.16">http://esv.example.com/passage/ESV:John.3.16</a><br>
<a href="http://net.example.com/passage/NET:John.3.16">http://net.example.com/passage/NET:John.3.16</a><br>
<a href="http://esv.example.com/passage/NET:John.3.16">http://esv.example.com/passage/NET:John.3.16</a> ==>
<a href="http://net.example.com/passage/NET:John.3.16">http://net.example.com/passage/NET:John.3.16</a><br>
<br>
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:<br>
<br>
<a href="http://esv.example.com/passage/ESV:John.3.16|NET">http://esv.example.com/passage/ESV:John.3.16|NET</a><br>
<br>
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.<br>
<br>
URI request & response examples: <a href="http://github.com/openscriptures/api/tree/master/examples/">http://github.com/openscriptures/api/tree/master/examples/</a><br>
<br>
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.<br>
<br>
So while the official SWORD URI standard is sword://module/key<br>
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:<br>
<br>
URN bible:passage/NET:John.3.16 ==> URL
<a href="http://net.example.org/passage/NET:John.3.16">http://net.example.org/passage/NET:John.3.16</a><br>
<br>
Thoughts?<br>
<br>
Weston<br><br><br><div class="gmail_quote"><span style="font-size: large; font-weight: bold;">Forwarded conversation</span><br>Subject: <b class="gmail_sendername">[sword-devel] Bible Resource Identifiers</b><br>------------------------<br>
<br><span class="undefined"><font color="#000000">From: <b class="undefined">Константин Маслюк</b> <span dir="ltr"><<a href="mailto:kalemas@mail.ru">kalemas@mail.ru</a>></span><br>Date: Fri, Apr 2, 2010 at 1:50 AM<br>
To: SWORD Developers' Collaboration Forum <<a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>><br></font><br></span><br>Hi all.<br>
<br>
I've created <a href="http://www.crosswire.org/wiki/Frontends:URI_Standard" target="_blank">http://www.crosswire.org/wiki/Frontends:URI_Standard</a> for<br>
discussing Bile uri's . If your frontend supports this , please<br>
describe there , how.<br>
<br>
Also it would be nice if SWORD take care of handling / decode into<br>
SWModule/SWKey.<br>
<br>
Wish you the best.<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
<br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">David Haslam</b> <span dir="ltr"><<a href="mailto:d.haslam@ukonline.co.uk">d.haslam@ukonline.co.uk</a>></span><br>Date: Fri, Apr 2, 2010 at 4:06 AM<br>
To: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br></font><br></span><br><br>
I have updated the wiki page a bit. Plus some useful wiki house-keeping.<br>
<br>
I have also written to Brian to ask him to add the details for FireBible.<br>
<br>
David<br>
<font color="#888888">--<br>
View this message in context: <a href="http://n4.nabble.com/Bible-Resource-Identifiers-tp1748943p1749018.html" target="_blank">http://n4.nabble.com/Bible-Resource-Identifiers-tp1748943p1749018.html</a><br>
Sent from the SWORD Dev mailing list archive at Nabble.com.<br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Chris Little</b> <span dir="ltr"><<a href="mailto:chrislit@crosswire.org">chrislit@crosswire.org</a>></span><br>
Date: Fri, Apr 2, 2010 at 11:40 AM<br>To: SWORD Developers' Collaboration Forum <<a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>><br></font><br></span><br>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:<br>
<br>
sword://module/key<br>
<br>
Adding an identical protocol handler for "bible:" is fine, and I'd even encourage it, but "sword:" is the official and defined protocol.<br><font color="#888888">
<br>
--Chris</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Karl Kleinpaste</b> <span dir="ltr"><<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>></span><br>
Date: Fri, Apr 2, 2010 at 12:03 PM<br>To: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br></font><br></span><br>That's all that Xiphos generates internally, and most of the examples I<br>
discussed with him in #sword the other day, which have now gone into the<br>
wiki page, used sword://.<br>
<br>
But Xiphos recognizes both, and installs handlers for both.<br>
<div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">David Haslam</b> <span dir="ltr"><<a href="mailto:d.haslam@ukonline.co.uk">d.haslam@ukonline.co.uk</a>></span><br>
Date: Fri, Apr 2, 2010 at 11:35 PM<br>To: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br></font><br></span><br><br>
FireBible recognizes both "sword:" and "bible:" as identifiers.<br>
<br>
David<br>
<font color="#888888">--<br>
View this message in context: <a href="http://n4.nabble.com/Bible-Resource-Identifiers-tp1748943p1749916.html" target="_blank">http://n4.nabble.com/Bible-Resource-Identifiers-tp1748943p1749916.html</a><br>
</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">DM Smith</b> <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>></span><br>
Date: Sat, Apr 3, 2010 at 7:43 AM<br>To: SWORD Developers' Collaboration Forum <<a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>><br>Cc: David Haslam <<a href="mailto:d.haslam@ukonline.co.uk">d.haslam@ukonline.co.uk</a>><br>
</font><br></span><br>
FireBible, since it is based on JSword, probably also recognizes some others based upon type, e.g. dict: as in dict://word.<br>
<br>
These are not standard, but are based upon a need to allow for general purpose lookup based upon type. This is what bible: is.<br>
<br>
We've discussed the need for type based lookups but I don't recall coming to a conclusion.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I think the semantic should be look for a preferred match, if any, and use the "best" match otherwise.<br>
<br>
In Him,<br><font color="#888888">
DM</font><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">DM Smith</b> <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>></span><br>
Date: Sat, Apr 3, 2010 at 7:58 AM<br>To: SWORD Developers' Collaboration Forum <<a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>><br>Cc: David Haslam <<a href="mailto:d.haslam@ukonline.co.uk">d.haslam@ukonline.co.uk</a>><br>
</font><br></span><br><div><div></div></div><br>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Jaak Ristioja</b> <span dir="ltr"><<a href="mailto:Ristioja@gmail.com">Ristioja@gmail.com</a>></span><br>
Date: Sat, Apr 3, 2010 at 9:55 AM<br>To: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br></font><br></span><br>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi<br>
<br>
When deciding whether to concentrate on the sword: URI or the bible: URI, one should take<br>
into consideration, that there is also other Bible software. Hence specifying a bible: URI<br>
should be an effort separate of the Sword Project. In the latter case we should also<br>
involve other interested parties in the discussion - both projects using Sword and those<br>
that don't.<br>
<br>
Another thing to consider (especially for the bible: URI format) is that it should stay<br>
very stable over time and be general (but not bloated) enough so that extensions to the<br>
format will not break backward-compatibility as long as required before the return of our<br>
Lord.<br>
<br>
Best regards!<br>
Jaak Ristioja<br>
<br>
PS: I strongly suggest you to pursue more important matters this time of the year!<br>
Especially this week! And especially these days of this week!<br>
PPS: Don't use "//": <a href="http://www.google.ee/search?q=berners+double-slash" target="_blank">http://www.google.ee/search?q=berners+double-slash</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.14 (GNU/Linux)<br>
<br>
iQgcBAEBAgAGBQJLt3L0AAoJEFqwhAoGc/hvnlQ//1XUjn7nnu/6jRrLp2Lvze7v<br>
m8M8GaGcLIP9rxuP3FzfOfLxWAY7rpzxEG+uXsmuUwGbkej7Zs7NrDppIQ5Dn85q<br>
qmIj85d42hrmuZEiZpGMwjMTS2uhA+iiRD/tD6+yv3A5VQEDU73uFjC799xAuZ7a<br>
/CGc1IXEeu3LTubkZEvk8rfW/EoukVboQ07zip4Ulliskwq4Dg/I1/qqzgmSxLhh<br>
R5bCDe71iAa08nJTPg1rVbRie7pUfZoXeN8LagN46L1bsnTwEGRHKbkvZfue0WGw<br>
236UMK0+w94HCQ6Xvqvht7HNjWs60fOV/0yc20m5UmTvvCzjIKBfueduse8FUBTa<br>
eN56Pg9w+D+lgA6WpkibMVB1cM1x8KRZ+bCM5Paf7rNnRZD6fxm0KZ+fpOmxynsg<br>
d/FwlMLzwNCFdSExXLH0L+/HPL3f3nSNGZWaSzqjtN6bCyXlhkSKxm/UHo98e2ZL<br>
FIbBlg4DzainZeUcEVvnzVhrIiIU5uLhp/qMywjpi8vHMDgbswXC3ftN1+MGR4yr<br>
opKnXIfhIkAL302h+9acETdp11A5E7/5trL62E+t/M/XR6iWGTZlSE0lmcrcJNed<br>
1vLXBPftKJSzXOxxsFOoSUfcO+YAksMdjWIXL7yFvbWqqv7iM5n+OL2r1hRLs6ZR<br>
Q7rpHgd22hGSeTTLFHlf/W/EoF3UQA7n7PbaJ4MOLxRqSBUQ8OvtfqwDce+z+FGx<br>
wkRECIG66WplwwJHBvfIdT44FOqGChnHiHgRLavudEtv8CSFYsvMPQ8V9QGZb1Ad<br>
fb2pFJexK1YYIyr8+9nux5Vjy0BB0KzkE8Yn+qx5dMGLSykMgHrBv2I1WD4CIMkL<br>
JjDNgWxOJqXvgAcWVJj04/dkktFhefjFonbGQfpUdUTWS+aZGDLsleRGsoPCI8pa<br>
p6b5FLU+iFJ+vhDwYp0s0UEkDiX8iSFXu/U9FPwes0Sjcj5AOZyVEw9+X2Tlvb/r<br>
Fg6jdw9j7RsH/G1OtfOVSyxkEYvxgHTVrHjfYlfmS/aF4SYS9srmbGmKHBUyDZiK<br>
0eMf+V4pZT4BatrubX2RTGG8AqoKl70AzwAJX+CSYLPh1fKlhkZbhZNOi8c5oogl<br>
SCh90HoRI1dlR85rWEfutPZ1b8hfOE+pSODP4tLvBCgxcTytQECxNpDO04p+VhFA<br>
ergnWXnqVeWhv9GHwVpCdJiSHKzYt5gX09d482de4UNDAm1pibeP/TTBt2vn9tU0<br>
m8dG35IYNEp5vPQH34mVdI2dhBxT4/XyhX7FGAHS91MX4tZHUSODwqlrEIBV4Jeb<br>
aStFVjf5lRqXqGc/BZQt8iE6X4tCSJsQWQDPco1TWxvlxcUig341M7lhIX8s1yff<br>
EUZODuNCdeW9CmPrkp0XbQzK8pou7mNbq9EjBcpDjO7ItH+Ip47SNdZUJbpTtUbi<br>
SLlwiNXhNp40Hj8lQAxitS271dZ6Q0HLwVuqgvv7gZkqIKQhh7Ya2myBlvrnTB6g<br>
ONbcsZ8S8JSDP3/qFLn57TQfVD1Ww8Yg9KHRQTrFrHDrNbVhNqNAG0sBUxFcLXmg<br>
PVJDjbEk4wzxSrsDYTNPusQRYUV09Tb+8AbqCcLkxM539/WrJuOh8gc3Forbxelk<br>
dIr4D+zW0zRpc7QfRAgabt2NJ62JLoWFB6htirtPz/RZsRh+uLRRx7B14fl+KFSS<br>
oR4dG8qqi2xtU3EKkubgnVgP4JQJB98VFsIFMeUqeNubC7CzanD8wy7h5rY63CrW<br>
YCL00ZXcFc0fGpOehWvPA/rpjbsbySatSHa0Eo5Xy09cx3aaA/ZbP6+3T78ffu/X<br>
uUJPTwsN6+HSsOKoe2OJ52tcPPxXb3kaxjshBw4H92qsPMu4hdZNDpo4Gn0ljSSU<br>
2zvF6XhAFloL0b7BbFMoE5WbSsWbYwd0fJNNcXdrgd/LXNtIm7ffwViqyKP6sDzE<br>
DrgIzEEOcFNiDDrhcA7WhxpERBwWr9DA9rDG2i78ykcsz0gAfh8t+b0JrZgkc+bc<br>
QuiAgmjI56r3VnssbDouV79fv74NCrxIJKqZ9F2GF83wwNgdU3vH4ZeOIC6jvuU1<br>
Jylp0X/NpbcU4Nn36cTGBfCUYsjL34dzVQF7c0KrNXUzfMowCSoH7YE1fU9gyi1q<br>
UHgoqTutn2pxL2eyXrjcQMHZrGYMFvbEA58KidIl4dkRQCjGKXC4XGZ26Js8XuE5<br>
14cVrMZydZiXKpnnRazyPQC9NtJukrfcYQ1CrfpLAFHl6o72yy8Fblw5xSf1nl6V<br>
qFOZoyCxzifrxtGDqPj626RHRpYhL+Jp5dZOyURiy4EmEgVsQcN4hm1F15eA1MV2<br>
TG3w714tm5+v8zcpl9QJtfQ9pv+oj3OGVL5c/xO3xcD32wo0wKMJfrOhFYwUkvnu<br>
hc27Dki/zFWIGaPOq8uBj/TqjBqc8N1jCDaO7Y0TCLqYGcfdU7Ge8yQ6Kk0hMATn<br>
/mPlYgRt/TnrRPlNSfRVKiWvhePC4+fw7kgqe3GWCl1ZSN581PRGprjR6AgT09Xz<br>
ti8OdWIMBFX7AAIPvS7gi64Xu+M9YBZfozIN0il+Dcsg2CP/ByA1y7RGDRDQcRl9<br>
EwLlVNkv63V7tzMTlMP5bHvlFDjZ2Zg20pmYuv+cGeEF6GKceTQcwFS4Ll9yr2Nc<br>
TOvouCT1kwgial/lIfQ+ZFssYxOWHSUQWh4tL3JmC7meDH5AdRcKLZA1X5ODuat0<br>
Oy1Szs3uCzJAx/KUG6rF<br>
=GBze<br>
-----END PGP SIGNATURE-----<br>
<div><div></div></div><br></div><br>