Check we have a plan for all current PT project types

[mvahowe]

I discovered in a call with @jonathanrobie that PT has project types that are not represented in DBL. We need to ensure that SB can handle all those project types (or come up with a valid reason for not handling specific project types.) The fix may be as simple as adding to the existing flavorType enums, or may require new flavors.

[jonathanrobie]

Here are the project types in Paratext: [image: Screen Shot 2019-11-20 at 16.02.37.png]

…

On Wed, Nov 20, 2019 at 12:48 PM Mark Howe ***@***.***> wrote: I discovered in a call with @jonathanrobie <https://github.com/jonathanrobie> that PT has project types that are not represented in DBL. We need to ensure that SB can handle all those project types (or come up with a valid reason for not handling specific project types.) The fix may be as simple as adding to the existing flavorType enums, or may require new flavors. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#93?email_source=notifications&email_token=AANPTPOUNHR6TX2HRUD2JG3QUVZ5JA5CNFSM4JPXBJKKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H2ZUFNA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPTPIWJLC755MNTVO232DQUVZ5JANCNFSM4JPXBJKA> .

[FoolRunning]

@jonathanrobie, I do not see your screenshot.

[jonathanrobie]

Take two ...

[mvahowe]

I don't really see this going anywhere unless or until the PT team makes some concrete proposals for SB flavors to represent some of these project types. @jonathanrobie @FoolRunning Realistically, for how many of the above cases is this likely to happen in, say, the next 6 months? (We still haven't done this work for a basic text translation, see #52.)

[FoolRunning]

Standard Translation, Daughter Translation, and Auxiliary are all basically the same (a set of scripture books). The difference is how they relate to other projects. I think new flavorTypes would be fine for those if we want them as SBs.

Back Translation and Transliteration (Manual) are basically the same as a normal translation, but include a status on whether the base translation was changed since the BT/transliteration was accepted. I'm not sure we want/need that status information in SB, but either way they could probably also just be flavorTypes.

Transliteration (using Encoding Converter) is basically a normal project that gets it's data automatically through a conversion from another project. Assuming we want this in SB, I think it could also be a flavorType.

Study Bible and Study Bible Additions are normal translations containing additional study-Bible content (e.g. sidebars, longer introductions, etc.). The difference between them is that Study Bible Additions uses standoff markup for the added content where Study Bible has it directly included in the USFM text. We have basically deprecated Study Bible projects in favor of the Additions, so I don't think there's any reason to support the deprecated version in SB. Because of it's standoff markup, this might need to be a new type of SB.

Consultant Notes are basically a set of project notes designed to be shared between projects. I don't think we've even talked about what to do with project notes so I'm not sure we want this included in a SB. I think since this is more akin to standoff markup it might need to be a new type of SB.

[rdb]

As I understand it, some of these project types actually share the same Registry metadata object as the main project they are related to. Which ones does this apply to?

If we want to define these as separate project types in SB, we should consider how this affects the metadata flow from the Registry, if these project types continue to share the same Registry project.

[FoolRunning]

As I understand it, some of these project types actually share the same Registry metadata object as the main project they are related to. Which ones does this apply to?

They share licenses, but they don't share much metadata. The only metadata sharing I can think of is that derived translations (everything but Standard and Consultant Notes) must use the same versification as it's base project.

[mvahowe]

@FoolRunning The list above is really helpful. The things you describe as "stand off" sound a lot like what I imagined putting in the parascriptural flavorType. eg stand-off study Bible content isn't Scripture, but tracks with Scripture. Could you give us an example of a file with stand-off content?

[FoolRunning]

Here is an Additions file: StudyBibleAdditions_xml.txt (16MB)
If we include this in SB, I'm not sure we want to use the same file format. It includes a lot of context information so it can re-hook up if the base text changes. Something simpler might be better for SB.

[mvahowe]

Thanks. At a quick glance that looks like a great candidate for a parascriptural flavorType. (Some of it would obviously need some burritoification, eg I don't think we'd want to refer to books by their number.)

[rdb]

They share licenses, but they don't share much metadata. The only metadata sharing I can think of is that derived translations (everything but Standard and Consultant Notes) must use the same versification as it's base project.

@FoolRunning I think what I'm asking is which project types currently are allowed/required to be registered independently on the PT Registry.

[FoolRunning]

@rdb, Ah. Standard, Daughter, Study Bible and Study Bible Additions are required to have their own registrations.

Back Translation, Transliteration (Manual), and Transliteration (using Encoding Converter) can optionally have them.

[ericpyle]

@FoolRunning DBL also currently supports GlobalAnthropologyNotes which is partially modeled after GlobalConsultantNotes project types.

Standard Translation, Daughter Translation, and Auxiliary are all basically the same (a set of scripture books). The difference is how they relate to other projects. I think new flavorTypes would be fine for those if we want them as SBs.

Back Translation and Transliteration (Manual) are basically the same as a normal translation, but include a status on whether the base translation was changed since the BT/transliteration was accepted. I'm not sure we want/need that status information in SB, but either way they could probably also just be flavorTypes.

Transliteration (using Encoding Converter) is basically a normal project that gets it's data automatically through a conversion from another project. Assuming we want this in SB, I think it could also be a flavorType.

Study Bible and Study Bible Additions are normal translations containing additional study-Bible content (e.g. sidebars, longer introductions, etc.). The difference between them is that Study Bible Additions uses standoff markup for the added content where Study Bible has it directly included in the USFM text. We have basically deprecated Study Bible projects in favor of the Additions, so I don't think there's any reason to support the deprecated version in SB. Because of it's standoff markup, this might need to be a new type of SB.

Consultant Notes are basically a set of project notes designed to be shared between projects. I don't think we've even talked about what to do with project notes so I'm not sure we want this included in a SB. I think since this is more akin to standoff markup it might need to be a new type of SB.

[jag3773]

Related to #145

[jonathanrobie]

Here are the definitions of project types in Paratext Help.