Citation Elements and "A medium sized set of elements":
You wrote, "Yates ... 600"
He only worked with the QuickCheck models, and came up with about 550 elements. (That number from my Excel work with his data.) I found it too time consuming to work in the spreadsheet format. I propose it's easier to start with a reasonable "generalized" list (even have a list for that purpose), and work directly on Mills QuickCheck models. We could add to the list as necessary. The list in a "citation elements" wiki page if I can ever get that page to actually save.
You wrote, "EE is that it has not attempted to generalize the element types." Once you get beyond the QuickCheck models, there's a much bigger message there--regardless of the style you use, citations should be "crafted around ... three essentials: evaluation, identification, and description." [EE (2007), p 38]
You wrote, " very little (or none) of the classification info appear" -- could you clarify what you mean by that?
Zotero -- (I lost that page due to log out too, by the way.) There are more reasons to go in a Zotero like direction than not. Translations, the ability to easily change between different style guides, etc.
From both online and telphonic discussions, the folks at Zotero want styles that have been "generalized," to use your words. For each "citation element" not now part of Zotero's historical sources, they will want a justification. That's not difficult to do, if you have their list to begin with. Zotero has a new community outreach staff member. (For whom I have left a message.) Perhaps we can save this part of the discussion until I re-write the Zotero-like page and get it posted.
One thought was to have a requirement for BetterGEDCOM to have a "default" template based on GEDCOM's current Data Fields. (Not all currently do.)
That would at least provide an internal "map to" mechanism in each BetterGEDCOM compliant application.
Needs much work, but perhaps this is a start.
Trying to respond to your request for ideas.... I'm a bit uncertain exactly what we're talking about. I presume that the "larger export" refers to the new elements to construct citation / footnotes / bibliography / whatever - where by "new" I mean, things that aren't in GEDCOM. Is it that or not?
Then the applications in scope seem to be clear - they are GEDCOM "compatible" apps but not BG "compatible" apps.
So.... oh - I just lost it - how are these GEDCOM "compatible" apps going to be loading these new elements? On what sort of a file?
I think I must have misinterpreted somewhere...
You wrote, "how are these GEDCOM "compatible" apps going to be loading these new elements?"
#6 recognizes that some, but not all, Applications have source systems that are comparatively larger than GEDCOM's say 10 data fields.
When two of those larger systems try to talk today, GEDCOM is sort of like a bottle neck.
We can remove that bottleneck, but when we do, there will still be Applications that have source systems based on GEDCOM's 10 fields.
Enter the #6 magician!!
A system that has GEDCOM's say 10 fields today might have only those same fields in the post BetterGEDCOM world.
If all programs had a default template set built from GEDCOM's say 10 Citation Elements," then we have ONE highly structured component setin an otherwise very flexible environment.
The thought was, that single highly structured component might play a role in discovering details for a #6 requirement.
Are you suggesting that a system that
(a) has GEDCOM's 10 fields (let's presume it's 10 for argument's sake) today,
(b) hasn't been modified for BG (yet);
would be modified in some fashion? (Just trying to get my head round this!)
Now, I thought the purpose of the template was to form the bibliography, footnote, 2nd footnote etc. So I'm still a bit lost on how this template using the 10 items helps with the _transfer_.
Are we suggesting that the umpteen dozen items from the big list (150 or whatever...) could be mapped onto the 10 in some fashion (which is CONSISTENT across all apps because the BG standard defines the mapping) and thus the umpteen dozen do get into an old style program? Albeit concatenated / compressed etc
If that could be done, the template is probably not that important - IF one had confidence that all 10 were printed.
Am I getting close to your ideas?
You write, "the big list (150 or whatever...) ... CONSISTENT across all apps because the BG standard defines the mapping"
Short answer--yes. Assume Family Historian is the receiving program example. Right now, if a Roots Magic GEDCOM is imported to Family Historian, the RootsMagic data will come to you organized differently than if you were importing a GEDCOM from TMG. (And we could go on and on and on.)
Requirement #6 says that once we've figure out how those larger systems talk to each other, we have to then make that same information import to the GEDCOM 5.5 based system--that can only read 10 fields.
Longer answer--How do CUSTOM elements import to Family Historian?
You wrote, "the template is probably not that important"
1) If the BetterGEDCOM system is based on transferring some reference to a template. Family Historian, as above, doesn't have a way of exporting reference to a template--so how will a BetterGEDCOM based application understand what to do with those elements? Voila--enter that "default" template.
2) A little more complex. All Application producing Citations in the ordinary course of business use template assumptions for that purpose--although a UI might keep the template under the hood. If we only "concatenated / compressed," there is a good chance Family Historian's import will be consistently unintelligent in it's template. BUT .. there is probably a way to make that intelligent.
I think ... if we presume a GEDCOM "default" template as we develop the gazillions of BetterGEDCOM templates and elements, the concept of higher or critical source elements will emerge. (Maybe like GENTECH in the post 2010 world) If that is the case, then Family Historian user will not ONLY get all the BG elements, but that GEDCOM identified subset will produce an intelligent citation, albeit limited compared to BetterGEDCOM compliant Applications.