[osis-users] Standard format for osisWork identifiers

[Todd Tillinghast]

Weston,

The only aspect that is determined by the standard is the use of 
"Bible." at the first and that "." is the separator.

We could not agree on a standard hierarchy.  I have used the following:
Bible
language code (two or three letter)
Abbreviation for the copy right holder
Common name of the translation (CEV, GEN, NIV, etc..) OR the three 
letter language code again if a minority language
The year of the translation

Examples of what I do (not specified by standard).
Bible.en.Public.KJV (this is the troubling one because there is also 
Bible.en.ABS.KJV so fall back to Bible.en.ABS would happen before 
Bible.en.Public.KJV which would be more appropriate.)
Bible.en.Biblica.NIV.1984 or Bible.en.IBS.NIV.1984
Bible.en.ABS.CEV.1995

I do find that for cases other than public domain texts like the KJV 
that fall back to less specific names works.  (That is the point that we 
got hung up on and one for which no solution exists.)

Todd


Weston Ruter wrote:
> I had a conversation with Troy about osisWork identifiers like:
>
> Bible.LXX
> Bible.en.KJV
> Bible.en.NIV.1984
> Bible.en.ABS.CEV.1995
>
> I'm trying to nail down what the specific order that the segments 
> should appear in so that these identifiers can be constructed and 
> recognized programmatically based on the various information 
> available. The goal would be to be able to construct unique 
> unambiguous work identifiers.
>
> On Sun, Jun 20, 2010 at 11:10 PM, Troy A. Griffitts 
> <scribe at crosswire.org <mailto:scribe at crosswire.org>> wrote:
>
>
>     Oh, it's a long debate about what the meaning of each segment of
>     an osisWord id should be.  I think everyone agrees Bible.KJV and
>     likely Bible.en.KJV are valid, but then I can't remember.  I think
>     we punted and said the rest is publisher preference.  I have
>     always argued for a sane fallback, so a very specific osisRef
>     which requests an osisWork like Bible.en.KJV.CrossWire.2003 would
>     yield progressively less useful results as you fall back segment
>     by segment to a module available in the user's library.  That's my
>     reasoning for the syntax I used and prefer.  I'm not sure how
>     Patrick chose his example in the user guide.  Are there prose
>     detailing the meaning of each segment anywhere that you've seen? 
>     I can try to get clarity from the guys.
>
>
> This is very helpful. It makes sense to consider the segments to be 
> increasingly narrowing in scope; the question is whether or not the 
> publisher is at a higher scope than the work itself, i.e. if the 
> publisher acts as a namespace prefix for the work abbreviation or if 
> it serves as a supplemental disambiguator for what the work 
> abbreviation refers to.
>
> I have not run across any prose detailing the order and possible 
> values for the osisWork segments. The manual merely says:
>
>     The osisWork attribute of each work element provides a short name
>     used to refer that work and its declaration as a whole. As of
>     version 2.1, OSIS specifies the recommended format described below
>     for those short names.
>
>
> But I can't find where "below" refers to, and I'm not sure this is 
> referring to the prose that is needed to document what the osisWork 
> segments are.
>
> Getting clarity regarding this would be a huge help!
>
> The way I've written OsisWork in osis.py currently, I'm probably doing 
> it wrong: 
> http://github.com/openscriptures/api/blob/41ba6ad7b0d11346e9beff9e9cb7f623be00e8f1/osis.py#L166
>
> Anyone have any insights?
>
> -- 
> *Weston Ruter*
> Founder
> Open Scriptures
> http://openscriptures.org/
> ------------------------------------------------------------------------
>
> _______________________________________________
> osis-users mailing list
> osis-users at crosswire.org
> http://www.crosswire.org/mailman/listinfo/osis-users
>