Thanks for the response, Karl. Responses appear inline below:<br><br><div class="gmail_quote">On Sat, Apr 3, 2010 at 5:34 PM, Karl Kleinpaste <span dir="ltr"><<a href="mailto:karl@kleinpaste.org" target="_blank">karl@kleinpaste.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As a deeply network-centric person, I am always uncomfortable with any<br>
specification that includes phrases such as "use the closest server,"<br>
because the concept of "close" is effectively moot, particularly in the<br>
face of VPNs. I am near Pittsburgh, but also routinely VPN'd to/through<br>
a site in Germany -- define "close" for me in any meaningful sense. Am<br>
I "close" to a reference site for the Bible named "Hoffnung feur alle"?<br>
Net.topologically speaking, yes, I am, but physical packet-hop-wise, no,<br>
I'm not...and just try convincing any network path optimizer of that<br>
fact, considering that the VPN keeps it from seeing the first dozen<br>
hops. Better would be "use the fastest," because that at least can be<br>
objectively tested, but speed at that level is primarily a concern when<br>
there will be bulk data transfer. I have a strong sense that these<br>
sorts of queries are intended to generate short responses.<br></blockquote><div><br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
At present, and as far as I'm aware, no Sword Project application has a<br>
facility to link directly outside the local machine. That is, for those<br>
which grasp sword://, it is interpreted exclusively within the universe<br>
of texts locally installed, and (I could be wrong here, but...) none of<br>
the apps is prepared to make arbitrary network accesses on the basis of<br>
http://. At the moment, Xiphos treats bible:// as equivalent to<br>
sword://; the code to do so is very old, and pre-dates my participation<br>
-- this would be easily correctable for another purpose, of course.<br></blockquote><div><br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I suppose what concerns me most about the offered mechanism is the<br>
numerous formats and their qualifiers and what appears to be the<br>
seriously complicated interpretations by which to return results based<br>
on them. I haven't had the time to watch the video yet, but how much of<br>
this query syntax is already, say, coded and supportable? (I am only<br>
dimly aware of Open Scriptures.) I saw in the web page TODO that you<br>
don't yet have a formal grammar, and I have a sense, somewhat<br>
incomplete, that there is considerable ambiguity in such matters as ';'<br>
-vs- '|' especially when combined. It almost seems silly to ask, but is<br>
there operator precedence?<br></blockquote><div><br>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.<br>
<br>A comma “,” separates passages within a work: <br>/passage/NIV:John.3.15-John.3.16,Matt.5.1<br><br>The semicolon “;” merely separates passages from different works: <br>/passage/NIV:John.1.3-John.3;KJV:Matt.1<br><br>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):<br>
/passage/KJV:Psalm.3.2|LXX;MT<br><br>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):<br>
/passage/KJV:Psalm.3.2/LXX <br></div><div> <br>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):<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
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).<br>
e.g. bible://acv,esv,kjv/gen.1<br></blockquote><br>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: <br>
bible://KJV:Gen.1|ACV;ESV<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Even while seeing some amount of value in most of the offered samples<br>
(though "token/23" seriously freaks me out), how much of this API can be<br>
expected to be put into day-to-day practical use, and within what sorts<br>
of user applications? I'm looking for practical use cases that would<br>
apply to our (that is, Xiphos') users particularly, just because that's<br>
where I live, to decide whether it makes sense to expend the effort to<br>
glue an API of this sort into it.<br></blockquote><div><br>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.<br>
<br>Thoughts?<br><br>Thanks!<br>Weston<br><br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Just ruminating...<br>
<font color="#888888"><br>
--karl<br>
</font><div><div></div><div><br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">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></div></div></blockquote><div><br><br><br><br><div class="gmail_quote">On Sat, Apr 3, 2010 at 8:42 PM, Brian
Fernandes <span dir="ltr"><<a href="mailto:infernalproteus@gmail.com">infernalproteus@gmail.com</a>></span>
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br>
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.<br>
<br>
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).<br>
e.g. bible://acv,esv,kjv/gen.1<div class="im"><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></div>
This sounds like a good idea.<br>
<br>
I will be putting these details on the wiki shortly.<br><font color="#888888">
<br>
Brian.</font><div><div class="h5"><br>
<br>
<br>
On 03/04/10 8:13 PM, DM Smith wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 04/03/2010 02:35 AM, David Haslam wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
FireBible recognizes both "sword:" and "bible:" as identifiers.<br>
<br>
David<br>
</blockquote>
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>
DM<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">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>
</blockquote>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">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>
</div></div></blockquote></div><br> </div></div><br>