[osis-users] osis.py

[Todd Tillinghast]

Weston,

We as an OSIS committee could never agree on a structure for OSISWork.

The key sticking point was always "fall back".  There is a desire to 
have the ability to fall back to a more generic Work if you don't 
actually have the exact on referenced.

So if Bible.en.ABS.CEV.1999.wide was specified and all someone has 
available to them is something else like Bible.en.ABS.CEV (though 
possession of Bible.en.ABS.CEV.2005) or they simply have Bible.en that 
matches then they can fall back as far as they need to.

The problem always was that there is Bible.en.ABS.KJV and 
Bible.en.PublicDomain.KJV is you have the second value be language and 
the third be the copyright holder and the fourth be the name of the 
translation.  The most natural fall back in the KJV case is another KJV 
edition rather than another translations from a given copyright holder.

In most cases the conflict is between a public domain text and a variant 
of that same named edition that is not in the public domain.

All fall back aside, my preference is
1) Bible. (and this value IS declared in the schema)
2) language code
3) copyright holding organization
4) Edition name (if there isn't a name use the language code again)
5) The year of the edition/copyright
6) Any extra identifiers

We have about 100 done in this form.

But this is my no means a part of the standard as we were unable to 
figure this one out.

Todd Tillinghast


Weston Ruter wrote:
> I'm working on a Python module for representing osisIDs (works, 
> passages, IDs, and refs). I think I've got the OsisWork class baked 
> pretty well (at least for reading/parsing), and I would appreciate 
> your thoughts: 
> http://github.com/openscriptures/api/blob/master/osis.py#L122
>
> It supports osisID works like those listed here (you can run these 
> tests via `python osis.py`): 
> http://github.com/openscriptures/api/blob/master/osis.py#L474
>
>     * Bible
>     * KJV
>     * Bible.en
>     * Bible.en.KJV
>     * Bible.en.KJV.1611
>     * Bible.en.ChurchOfEngland.KJV.1611
>     * KJV.1611.06.07
>     * KJV.1611.06.07.235930
>
> In the last two examples, the month and day are also provided (if they 
> aren't, then they default to 1); and in the very last example, the 
> time is also included (HHMMSS).
>
> An OsisWork then has the following members:
>
>     * segments (each of the period-delimited segments in the osisID)
>     * type (one of the strings enumerated in TYPES)
>     * publisher (a string, the first of two segment slugs listed in
>       the osisID)
>     * name (a string, the single slug listed or the second of two)
>     * pub_date (a datetime object; is “pub_date” the best name?)
>
> Are there other pieces of information that should be parsed out? What 
> about revision, version, or edition like:
>
>     * Bible.Example.2010.r231239921
>     * Bible.Example.2010.v2
>     * Bible.Example.2010.ed3
>
> Currently if anything is included which isn't recognized, then it will 
> raise an exception; instead it should probably glob the unrecognized 
> segments into a "etc" or "splat" list.
>
> Thoughts? I'd love to get this implementation fully built out to be a 
> reference implementation for ports into PHP, JavaScript, etc.
>
> Weston
>
>
> On Tue, May 4, 2010 at 12:52 AM, Weston Ruter <westonruter at gmail.com 
> <mailto:westonruter at gmail.com>> wrote:
>
>     Hello all,
>     Things have been a bit quiet on my end the past few weeks, so I
>     wanted to update you on where I am at and what I see as coming
>     next for the API development.
>
>     I've been working on a standalone Python module for representing
>     and working with OsisWork, OsisPassage, OsisID, and OsisRef
>     objects. Since OSIS identifiers form such an integral part of the
>     URI space for the RESTful API as it is currently designed, having
>     a solid OSIS library seemed like a good thing to work on. You can
>     see what I have so far here:
>     http://github.com/openscriptures/api/blob/master/osis.py (it's not
>     yet at an alpha state). Please let me know what you think and fork
>     the code to make corrections and improvements.
>
>     Once osis.py is baked, then the Django views can be written to
>     handle the various OSIS objects. I hope that the osis.py module
>     could also be ported over to JavaScript and PHP and other primary
>     languages to give us a familiar interface for working with OSIS
>     identifiers.
>
>     In other news, my wife and I are expecting the birth of our first
>     child, a son, in three weeks. I plan to keep involved here as much
>     as possible, but will probably be distracted (though hopefully not
>     as much as I have been these past few weeks).
>
>     Weston
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> osis-users mailing list
> osis-users at crosswire.org
> http://www.crosswire.org/mailman/listinfo/osis-users
>