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: *Константин Маслюк* <kale...@mail.ru> Date: Fri, Apr 2, 2010 at 1:50 AM To: SWORD Developers' Collaboration Forum <sword-devel@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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page ---------- From: *David Haslam* <d.has...@ukonline.co.uk> Date: Fri, Apr 2, 2010 at 4:06 AM To: sword-devel@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* <chris...@crosswire.org> Date: Fri, Apr 2, 2010 at 11:40 AM To: SWORD Developers' Collaboration Forum <sword-devel@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* <k...@kleinpaste.org> Date: Fri, Apr 2, 2010 at 12:03 PM To: sword-devel@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.has...@ukonline.co.uk> Date: Fri, Apr 2, 2010 at 11:35 PM To: sword-devel@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* <dmsm...@crosswire.org> Date: Sat, Apr 3, 2010 at 7:43 AM To: SWORD Developers' Collaboration Forum <sword-devel@crosswire.org> Cc: David Haslam <d.has...@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* <dmsm...@crosswire.org> Date: Sat, Apr 3, 2010 at 7:58 AM To: SWORD Developers' Collaboration Forum <sword-devel@crosswire.org> Cc: David Haslam <d.has...@ukonline.co.uk> ---------- From: *Jaak Ristioja* <risti...@gmail.com> Date: Sat, Apr 3, 2010 at 9:55 AM To: sword-devel@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-----
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
