Hello Nathan,On 11/8/06, lumin8 <[EMAIL PROTECTED]> wrote:
Bill,Yes exactly. Sounds like you are doing some great work with this.I'm trying to figure out how I can help - at the least I could packageit as a rails plugin or gem making it easy for any ruby on rails
developer to get started with it.I
Bill,
Yes exactly. Sounds like you are doing some great work with this.
I'm trying to figure out how I can help - at the least I could package
it as a rails plugin or gem making it easy for any ruby on rails
developer to get started with it.
Let me know if I can help with anything else.
-=natha
Thanks to everyone who has shared ideas on this thread.
Of course I do not want to reinvent the wheel. I am also very
interested in community development. Over the years, I have been
humbled by my own ability. Pie in the sky ideas never get realized in
the reality that I am only one developer.
Martin Gruner wrote:
>
> You've got a good point right there. This would actually be most preferrable.
> I don't know of a good solution for fast access in that case. You don't want
> to read the entire document into memory, and you don't want to parse it every
> time. Ideas?
Ah, I think I'm c
Nathan,
My 2 cents on the entire thread.
There are several fundamental parts of a database application:
1) Indexed lookup: Given a key, return some data. Nothing will beat
the simplicity of Sword's api.
2) Metadata and text search: Given a search criteria, find all data
that satisfies the qu
On Tue, November 7, 2006 5:49 pm, Troy A. Griffitts wrote:
> In regard to this thread. It all boils down to simply comparing
> comparable entities.
Well put! Thanks for the insight.
Peace,
Gabriel
--
G a b r i e l M B e d d i n g f i e l d
___
In regard to this thread. It all boils down to simply comparing
comparable entities.
Data storage:
A database stores and retrieves a chunk of generic data
The SWORD low level drivers store and retrieve chunks of generic data
You might argue that we need to add a new driver which can retrieve
Hi Gabriel.
>From what I've seen, a lot (maybe most) of the "serious" bible texts have
> structured their documents like you would a book, and then littered it
> with "milestones" to mark where chapters and verses begin. E.g.
>
>
>
> In the beginning, God created
> the heavens and the earth
Hi Troy,
> Martin, not to be rude, but have you actually personally used SWORD to
> display a tree structure?
Well we gladly use it in BibleTime to display Genbooks, as you know. =)
> Have you attempted to represent a tree
> structure in a RDBMS?
Yes. I learnt of it at work, where we use t
> You can split up any XML document at its nodes like , etc.
> into
> rows of a database that also holds the rendering context for each of these
> nodes, and also information about the tree structure of the xml document
> (parent-children etc.). How deep you want to split it beyond osisID
> depen
Hello,I see. You want the module information in a database because it's then trivial to program a web application using Ruby on Rails ActiveRecord object relational mapping support. RoR also supports other logic in controllers such as web services clients so it's entirely possible to write an app
Martin Gruner wrote:
> I find that a database would be a very
> fast and convenient way to represent the tree structure of an xml document.
> Better than Sword does at the moment.
Martin, not to be rude, but have you actually personally used SWORD to
display a tree structure? Have you attempte
Well, I thought about this, and since you ask..
> Case-in-point: book/chapter/verse. You can easily put a bible into any
> relational database and index it having a column for book, chapter, and
> verse. But what about paragraphs? Sentences?
You can split up any XML document at its nodes li
On Tue, November 7, 2006 9:34 am, lumin8 wrote:
>>
>> I'll leave the question alone as to the value of a relational database
>> for this data over using the SWORD API.
>
>
> Actually, I am interested in this question if you have time / desire to
> enlighten me. I think I can manage the chunk of c
I'll leave the question alone as to the value of a relational databasefor this data over using the SWORD API.
Actually, I am interested in this question if you have time / desire to enlighten me. I think I can manage the chunk of code you gave me (thanks), but I have never compiled a program in my
Em Mon, 06 Nov 2006 15:36:14 -0600, lumin8 escreveu:
> I am interested transferring a couple of the Sword bible and lexicon
> modules into a relational database (mysql most likely)
Actually SQL is not relational.
> for my own indexing purposes.
I guess PostgreSQL’s tsearch2 cou
On 11/6/06, Greg Hellings <[EMAIL PROTECTED]> wrote:
> On a branching note, thinking about quick & dirty hacks for this type
> of tool, what is the current state/lack of state for the Sword
> library's python binding? I thought I remembered hearing someone
> speaking about it in the past, but I do
On a branching note, thinking about quick & dirty hacks for this type
of tool, what is the current state/lack of state for the Sword
library's python binding? I thought I remembered hearing someone
speaking about it in the past, but I don't recall hearing much about
it. It would seem an ideal way
sorry, typo 'module' variable used below should be 'book', per the
name declared near the start.
Troy A. Griffitts wrote:
> I'll leave the question alone as to the value of a relational database
> for this data over using the SWORD API.
>
> You can do this a few ways depending on your famil
I'll leave the question alone as to the value of a relational database
for this data over using the SWORD API.
You can do this a few ways depending on your familiarity of tools.
If you can process raw text files, you can use of one the SWORD provided
export utilities to produce plain text data
I am interested transferring a couple of the Sword bible and lexiconmodules into a relational database (mysql most likely) for my ownindexing purposes.Is there already a tool available that can move the data over? If
not, what would be the best way of accomplishing this?Thanks so much,nathan
_
21 matches
Mail list logo
