Pick an enum naming convention and stick with it

[rdb]

We seem to be inconsistent on this matter. Especially under the flavorDetails definitions, where enums are occasionally defined with upper-case, sometimes as English strings, and othertimes as camelCase. Also see #92. Should we adopt a consistent convention for this?

[mvahowe]

The future is camelCase!

[mvahowe]

I think the harder issue here is going to be working out how we ended up with the existing lists of enums (not the punctuation, the semantics). eg, for "audience", we have

basic, common, common-literary, literary, liturgical, children

I assume DBL inherited this from the PT Registry?

This looks like an attempt to produce a scale for what I would call "register", ie how long the words and sentences are, but it goes surreal at "liturgical". I don't know if we have projects that we could call "scripture" in our scheme that are liturgical - for me, liturgical implies not doing BCV. In any case, liturgy in the 21st Century is not always in literary language. It is possible in theory to have children's liturgy, and it's certainly possible to have more or less basic/common/literary content for children.

@jonathanrobie @klassenjm Who do you think we would need in the room to get the backstory for this and other choices of category in DBL (and, I suspect, PTReg) metadata?

[mvahowe]

As in other places, we have a choice between

• going with what we inherited, and trying to explain and justify it, and, eventually, extend it or

• going with something new, which means making a serious attempt to understand what needs determined the old, and also coming up with a watertight migration strategy between old and new enums.

[jag3773]

@mvahowe I'm in favor of option 2, going with something new. Since these enums will now be inherited by multiple third parties, I think it will be important to clearly explain what they mean. If we fudge then we'll have a continual problem.

Perhaps a few sliding scales could stand in the gap and provide more explicit information. e.g. for audience, it may be better to have something like:

• Target audience age range
• Target audience reading level (could be one of the standard measurements, or grade level, or 1-10 scale)
• Target audience education level
• Target audience background (e.g. cultural background which can affect vocabulary, use of metaphors, etc.)

Just some ideas that would provide specific information that combined could equal the previous "liturgical" or "children" and yet provide richer information too.

[klassenjm]

@mvahowe I would strongly recommend speaking with Kees de Blois for some background on this vocabulary. It likely comes from before the PT Registry - from TMS, and other databases or practice before that.

[rdb]

I assume DBL inherited this from the PT Registry?

PT Registry inherited this from GBC, and GBC inherited from DBL (although GBC may have introduced some fields from other sources, I wouldn't know because I wasn't involved in GBC early on).

I don't mind going with something new as long as we have a clear and implementable data migration strategy.

[klassenjm]

DBL inherited various things from earlier systems, like TMS - which is why I would recommend checking in with Kees, if he does not mind engaging here a bit.

Jeff

On Mon., Jan. 13, 2020, 1:23 p.m. rdb, notifications@github.com wrote:

I assume DBL inherited this from the PT Registry?

PT Registry inherited this from GBC, and GBC inherited from DBL (although GBC may have introduced some fields from other sources, I wouldn't know because I wasn't involved in GBC early on).

I don't mind going with something new as long as we have a clear and implementable data migration strategy.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/104?email_source=notifications&email_token=ABBXGJ7NOSYFFBMI2EFHCW3Q5SWTHA5CNFSM4J5KNAD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIZYHFY#issuecomment-573801367, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBXGJ4RFYHRS6I2UOPEAHTQ5SWTHANCNFSM4J5KNADQ .

--

This email and any attachments are confidential and intended only for those to which it is addressed. If you have received this message in error please inform the sender and delete the email. The content of this message belongs to the sender and the views expressed do not necessarily reflect the views of United Bible Societies.

United Bible Societies Association, a company limited by guarantee. Registered in England and Wales No 2264875. Registered Charity No 800058 Registered Office: Stonehill Green, Westlea, Swindon, Wiltshire, SN5 7PJ, England.

[mvahowe]

Thanks @rdb, @klassenjm. I'll start a conversation about this somewhere but, before doing that, I'll try to collect the current enums so we know what we are discussing. (So a meta-enum.)

[mvahowe]

Here are the enum-like bits of the current DBL metadata schema.

dbl_enums.txt

[mvahowe]

@rdb Could you please take a look at the document above and tell us

• which of these fields have an equivalent in PTReg

• whether those fields that do use the same enum

• ideally, whether all the options are used in PTReg

[rdb]

@mvahowe From that document, the Registry has scopeEnum, numeralSystem, translationTypeEnum, translationLevelEnum exactly with the options shown there, and all enum values are used by at least one project, with the following exceptions:

• Our type_audience includes a "Literary - Liturgical" value, not present in your enum. It is in use.
• We don't appear to have a project in the DB that uses the "Hebrew" numeral value.

With regards to numerals, I would strongly prefer us to switch to the enumeration defined in the Unicode CLDR.

[mvahowe]

Some (maybe) low hanging fruit:

• canonTypes This is currently a comma-separated list, as a string. In JS it seems like a no-brainer to have an array that can contain between 1 and 3 of "(ot|ot+)", "nt", and "dc" in any order, ie ["ot", "dc", "nt"] # interconfessional Bible ["ot+", "nt"] # Catholic Bible (Hebrew and Greek OT books mixed)

• audioCompressionEnum DBL uses mp3 and, more recently, wav. It might be nice to include flac for people who don't like patents, so mp3 | wav | flac

• printOrientationEnum portrait | landscape

• printColorEnum Lower case, so cmyk | rgb

• printFontEnum Maybe camelCase, so bitmap | openType | trueType | type1 | other

• numeralSystemsEnum use BCP47 names: adlm ahom arab arabext armn armnlow bali beng bhks brah cakm cham cyrl deva ethi finance fullwide geor gong gonm grek greklow gujr guru hanidays hanidec hans hansfin hant hantfin hebr hmng hmnp java jpan jpanfin jpanyear kali khmr knda lana lanatham laoo latn lepc limb mathbold mathdbl mathmono mathsanb mathsans mlym modi mong mroo mtei mymr mymrshan mymrtlng native newa nkoo olck orya osma rohg roman romanlow saur shrd sind sinh sora sund takr talu taml tamldec telu thai tirh tibt traditio vaii wara wcho

[jag3773]

Notes from our meeting: use otdc; use audioFormat and drop flac; drop 'other' from fontEnum

[mvahowe]

New issue for audio-related enum issues at #144

[mvahowe]

New issue for translationType and audience at #145

I believe that all the enums are now either implemented or in another issue, so I'd like to close this issue.