Comments

Hi Russ,

You are correct that ESM provides alternative ways of developing the bibliographic entry. I'm sure there are many folks who still sort their census bibliographic entries by household, too. (Since developing those materials, I've learned how to access the bibliography entries in FTM-Mac.)

I use a State-County lead. The following bibliographic citation template corresponds to the reference note template I posted above.
[STATE]. [COUNTY]. [YEAR] U.S. Census, population schedule. Digital image(s)< [WEBSITE OWNER].> [ITAL:][WEBSITE][:ITAL]. [URL] : [ACCESS DATE].*
*This assumes "access date" is a vendor's data type (like RootsMagic). If it's not, then you need a different element and the value will then often be user defined such as "2001-present."

BTW, we have census screen shots on the wiki about one of the FTM-Mac census source types, "Software Citations." http://bettergedcom.wikispaces.com/Software+Citations


Russ wrote, "the way that FTM2012 has Templates, set up, based on EE!, the template provides Source Fields and Citation fields."
You are referring to the forms/templates that are, in FTM, based on underlying citation templates. Although it may be a nit, FTM-M has elements/fields at the "source" and then additional fields, "citation detail" and "citation text," etc. that become available when you "cite" a source/"add new source citation." All the elements and fields are "citation elements," though, and they are compiled in different ways to form reference notes and bibliographic citations.

FTM has a feature that allows users who aren't happy with the default programmed citation result for the reference note to just add or delete information separate from the forms or citation templates. See the tab, "Reference Note" on the "Edit Source Citation" window. You can type/edit to your hearts content in this "Reference Note" window it includes buttons for formatting (italics and underlining). Such changes do not update or revise the information entered in the forms/templates.

Russ wrote, "In what you posted, you have included the Source and the Citation."
If you look, I believe you'll see that, using your terms, FTM-M reference notes include "the Source and the Citation," too.
http://bettergedcom.wikispaces.com/Software+Citations
In my reference note citation template, the element "[CD]" is comparable to FTM-M's field/element "Citation Details"=GEDCOM's PAGE I could have added another field, "[CM]" which would have been comparable to FTMs field/element, "Citation Text." (If you noticed, RootsMagic has converted its GEDCOM PAGE field to "Research Notes" in RootsMagic v5.)

As an aside, the citation template in the earlier posting came from TMG. It doesn't come preloaded with EE templates--I "define" my master source, including that I define how my programmed citations are to be developed (so I'm "defining" which elements will appear in my form/template).
See also, "Programmed Citations, a general overview."
http://bettergedcom.wikispaces.com/message/view/A+Data+Model+for+Sources+and+Citations/48011898

I happen to be a census splitter (see "Citation Mechanics," http://bettergedcom.wikispaces.com/Citation+Mechanics).

Russ wrote, "The other thing, is that the End User will most likely NOT see the data elements as in fields."
Without regard to semantics, that may be the case with FTM, but it is not the case with RootsMagic and Legacy. See the "Software Citations" RootsMagic screen shots. The "citation templates/elements" are to the right of the "fields/forms/elements." As the user fills in the blanks, those "templates" are populated. If the user prefers some alternate presentation, they either massage the data entry or create a custom template. (Legacy offers the same feature; we just don't have screen shots posted because Legacy doesn't have a source type compatible to the example on "Software Citations.")

Lots of details here ... pardon the typos. -GJ

GeneJ,

Sorry I can't post images here, as I think FTM2012 and FTMM-1 or 2, which ever you have, are different in the Reference Note. I added the Town, after the State and County, and the Town was listed as part of the SOURCE piece of the Reference Note.

Russ

Hi Russ,

When I need to add an image, I create a wiki page, and then upload and add the image to that new page. I add text to explain the image.

Once the page has been saved, just add the link to the page in a discussion.

If you don't need to add any text, then you might be able to upload the image using the "pages and files" section of the wiki. Once it's uploaded, I think you can also add a link to the file in a discussion. (I haven't tried this.)

In the FTM-M screenshot, the template I used had a field "Township/Civil District" at the source level.

I only have FTM-M1, all $99 of it. Since I've only had it about a year, it will be a while before I can update. When the beta for FTM 2012 came out, I had about 48 hours with it until the expiry, but I did make a quick "forms" comparison to FTM-M templates I'd been testing. Any screen shots you can add would be much appreciated. --GJ

Hi Russ,

I have a copy of RootsMagic5, and you have FTM 2012.

If you want to, we could set up another wiki page to use as a summary, and work on a handful of select sources and citations. We could present the default fields and then work to reverse engineer the default citation templates.

I have Legacy 7.5 here, too. --GJ

GeneJ,

I have all three. Give me an (1) example of what you want and I'll post all three on the Blog.

I find the Blog much easier to use.

I was hoping that the Source / Template / Citation Element issue that I tried to raise would show some sign of hope that it was important, so I had not put anything up. I still think that understand the "fields" (probably a bad term) in the Template / thus the source, and the Citation, with an common understanding of which Template (EE!) is used, the stream of data in the BetterGEDCOM file could be formatted correctly (per the receiving application) to the end user.

Russ

Gene: "Why don't you just eliminate the concept of standardized elements all together. Just recognize the two levels and allow vendors and users to define their own requirements"

I think where you're using (non-existent??) software that allows definition and export of "output" citation templates (sorry - I know you don't consider them output but it's the best words I can use to distinguish them from lists that just define data) and you have umpteen source-types, then you could work it like that.

However, as soon as you either want to swap templates or import into a non-template using app, then you run into issues if you don't agree standardised elements - e.g. you have "author" covering the writer, translator, editor concepts and I have "creator" with a sub-type of "writer", "editor", "translator", etc. If I can't just use your attached template, I'm into hard work to decide where your stuff fits into my formats.

Hi Russ:

I'm listing below 4 different sources; each a unique source type and all reasonably common. We've already done work on these and have references from EE. We have digital images of all but the last entry. Ditto, for all but the last entry, the underlying images or sources are readily available.

If you are game, for each of the four, we could (a) take screen shots reporting all the entries in the various forms, (b) compare the "reference notes" each program generates for each of the entries. (If you decide we should, we can compare the short reference notes--Legacy and RootsMagic only--and the bibliographic entries from all three programs.)

The reverse engineering is a process of relating the variables (from the forms) to the reference notes (and, if we opt so, the short reference notes and bibliographies). --GJ


(1) 1880 U.S. Census
http://bettergedcom.wikispaces.com/Citation+Graphics#112%201880%20US%20Census
References: EE, 2007, p. 240 [QuickCheck, Online commercial site], 250 [QuickCheck, 1880-1930, NARA films], 279-282 [1880, 1890, 1900 and 1910-1930 U.S. census].
Cite this source for an event/fact about Asa Thomas' birth.

(2) 1850 U.S. Census database entry
http://bettergedcom.wikispaces.com/Citation+Graphics#105%20US%20Cen%20Database
References: EE, 2007, p. 254 [QuickCheck, database online], 275 [online databases], 277 [Ancestry census database].
Cite this source for an event/fact about where Asa Thomas' parents were born


(3) Vital Record/published New England Town Records
http://bettergedcom.wikispaces.com/Citation+Graphics#120%20VR%20Hardwick
Reference: EE 470
Cite this source as another alternate event/"fact" for Asa Thomas' birth

(4) Simple Journal entry, 1964 “Founders of the American Firestone Family” article by George Ely Russell. http://bettergedcom.wikispaces.com/The+George+Ely+Russell
Reference: EE, 779, “Journal Articles: Print Editions” (QuickCheck Model), and (b) 798, “Basic Format: Journal Articles.”
I'll add relevant images from this article (we will only need a few lines); we can then use this source for an event/fact that "Hans Nicholas Firestone, born 25 March 1712 at Berg."

HI Adrian,

(1) OooO ... as for "software that allows definition" ... you know I'm not using non-existant software. I've posted the screen shots and added a discussion about the process ... If I were a more experienced Legacy or RootsMagic user, I'd post the custom builds/citation templates in those programs, too.

(2) You wrote, "as soon as you either want to swap templates or import into a non-template using app, then you run into issues if you don't agree standardised elements"

I am out of ideas then, Adrian.

There are programs that are "non-template" based, but not all vendors are "non-template," either. Isn't this a given--not all vendors will enable all functionality.

Here in the states, the citation is a part of our Genealogical Proof Standard; it's even written into the APG Code of Ethics. On the wiki, back in March, we identified programmed citations and styles as a featured trend, growing in popularity. We have researched and reported about the problems, and we know that every day, millions of users around the world enter citations to enabled software using these programmed citations--and their documentation "breaks apart" or is mangled upon transfer. As much or more than any other user problem, this issue was an impetus behind BetterGEDCOM.

Geir has reviewed the problems and written a good plan based on an inclusive set of requirements. It's an 80-20 plan. Andy has even found a way to identify the most accessed Ancestry.com offerings. --GJ

Gene - re "you know I'm not using non-existent software." Absolutely. The bit I was suggesting might not exist is the ability to export the templates. (Not the data, the templates for the data.) And in my book, you sitting there getting bored copying and pasting (well I'd get bored) the templates doesn't count as exporting. Exporting is TMG or GenBox or whatever exporting the templates themselves in a file. Does that happen? If it does I'd like to understand what the exported templates look like and if there is any compatibility across programs.

"Isn't this a given--not all vendors will enable all functionality". Trouble is, there's exclusions and there's exclusions. I can quite happily cope with the idea that not every vendor supports personas, evidence and conclusion persons, etc. Because they are features that not all software would support. But as good as all software supports "citations", so to make accurate transmission of citation related data dependent on features that are only seen in those programs supporting templated citations, seems to be building in failure from the start. It'll either be - "BG claims to support accurate transmission of citations but it doesn't work in my software or his, or hers or... Must be BG is rubbish" - or it'll be "XYZ Software Co claims to support BG but it doesn't support the citation bit - XYZ are lying..." Better by far to have the templated citation support a separate option that can be clearly included in or out.

I understand citations are important - it's the templating of them that I suspect is of less interest across the globe than you might think. Maybe I'm wrong and I'm certainly not defending the lack of interest in templating.

Hi Adrian,

Technically I have two ways of exporting templates, but both would be misleading in terms of the requirements considered by Geir's solution.

Adrian wrote, "Better by far to have the templated citation support a separate option that can be clearly included in or out." Aren't we just describing an added requirement? Ala, how will needed information be stored in programs that do not support programmed citations? I believe Geir's proposal assumed only some programs would support programmed citations. (We have been quite keen to a solution that incudes metadata.)

"I understand citations are important - it's the templating of them that I suspect is of less interest across the globe than you might think. Maybe I'm wrong and I'm certainly not defending the lack of interest in templating."

There are citations, there are programmed citations, and soon we will have metadata ... and then separately there are forms.

We have recognized programmed citations as a trend, growing in popularity. From experience on the various user mailing lists, I know software supporting programmed citations is popular outside of the United States, I just don't know how many of each flavor are actually in use in the different countries. TMG sells a "UK" version.

There are other related trends considered in Geir's proposal--the need for an international solution and user "options"; support for Internet services, and users who want simplified approaches to citations. We want genealogical metadata, too.

I wrote earlier that, as much or more than anything, "mangled" citations gave rise to BetterGEDCOM--Geir's proposal considers a solution to these mangled citations and it recognizes other trends or standardization needs.

In current discussions, you, Tom, Louis, Tony and others are making important contributions to the thinking about an inclusive set of requirements. It may be time to being a thread directly attached to Geir's proposal page, in which we summarize the requirements, especially these additional requirements.

I'm already tinkering off wiki on some 80-20 stuff. --GJ

















*I've said before that a term other than "evidence" be used to describe what are the abstracts and extracts referred to in the other thread.

Gene - you ask "how will needed information be stored in programs that do not support programmed citations?"

I have tried to say many times that the information will need to be specified in some form - whether it's items defined in BG for all source types, items defined in BG for individual source types; items defined by vendors for individual source types; items defined by individuals for individual source types (just like custom events). In other words, we want to use the equivalent of programmed citations but ONLY to define the data content, not how it appears. That will then allow its storage. Once stored, it can be transmitted because it will have its defined label with it.

Hi Adrian,

TY and sorry, I didn't mean to "ask" ...but, as you commented, I had intended to suggest the requirement involved specifying how that information woud be stored.

GeneJ said:

"That the systems are not compatible is further evidenced by the different arrays of default templates in the different programs--one has 170, another has about 400 and a third, between 1000 and 1500. As well, that all of the programs enable customization in one way or the other."

Then why not define the to-be-the-standard set of Citation Templates for BetterGEDCOMs SourceCitations.com initiative? Those programs, and every other, will then have "THE" standard to use, and you can define in the standard whether customization is allowed, and if so, where and how.

I'm always in favor of doing the work first, and arguing what to do with it (whether to include it in BetterGEDCOM or not) after - because the process of doing the work reveals insights and problems that would never have been seen in the myriad of precursive arguments.

Louis

... I meant for the SourceTemplates.org initiative.

Hi Louis,

There have been several discussions about the SourceTemplates.org initiative, there are some postings to the wiki.

Geir's proposal was discussed with Dovy in a Developers Meeting before publishing same to the wiki. I think they are waiting for BetterGEDCOM to rally round. In the mean time, AncestorSync is readying their underlying release for RootsTech.

http://bettergedcom.wikispaces.com/DevelopersMeetingNotes+2011-11-28+%28Nov+28%29

http://bettergedcom.wikispaces.com/message/view/Sub-Project+SourceTemplates/43916580

Tom,

Very briefly,

(1) Your nos. 3 and 4 (see my earlier posting for the links) would only be developed for some source types in the various cultures. We've used some rough ratios, like 80-20; if that turns out to be 95-20, all the better. We must still make it possible for the balance of those source types to be exchanged.

(2) I can't speak to the specifics of your 3 & 4, but unless you intended the pair to be based on a single style or user preference, then the citation elements provided for a given source type will support more than one style/preference. Unless we are able to communicate which style/which preference, a receiving application will not know. For example, how is a receiving application to know if your census citation was written in Register style or Evidence Explained … or "Adrian's way," for that matter. And why would any developer (or user) want an application to be bogged down with an ever increasing set of style definitions--many of which might never be used?

I'd like to write more about metadata and flexibility, but I'm just beat. As you probably saw, the DTO group was hard at work today. --GJ

"then the citation elements provided for a given source type will support more than one style/preference"
Yes.

"Unless we are able to communicate which style/which preference, a receiving application will not know"
Yes

"For example, how is a receiving application to know if your census citation was written in Register style or Evidence Explained … or "Adrian's way," for that matter"
It can't.

"And why would any developer (or user) want an application to be bogged down with an ever increasing set of style definitions--many of which might never be used?"
They probably won't. That's why we need a citation style language to define output (to screen or report) templates for "citations" (i.e. bibliography, 1st & 2nd reference etc).

Now - we agree on the issues. We just seem to be proposing different solutions. Let me take an example of what a source record in BG _might_ look like:
Title="John Doe & Martha Roe, 23 May 1767; Register of Marriages for the Chapelry of Witton (Jan. 1754 - May 1770)"
Author="St. Helen's, Witton, Cheshire"
Published="digital image of original published in 'The Cheshire Collection, Church of England Parish Registers 1538-1910', FindMyPast"
SourceType="Parish Register UK"
ActualText="blah blah"
Repository="FindMyPast"
RepositoryCallRef="Original register ref: CRO P53/4/1"

The citation elements provided for this will support more than one style/preference. Certainly will - rather extraordinary if they didn't.

A receiving application will not know which style/preference to use. Very true. Now - why does it matter? First question - has it got the right data? Yes. That's on the BG file. Is that data unambiguous? I think so. Will the receiving application understand that if I print this out, I will ensure that Repository "FindMyPast" will be accompanied by its URL? No, it won't understand it. But it will know what the URL is because that's held against the Repository "FindMyPast" elsewhere in the BG file.

Does this mean that the recipient has to create yet another template themselves? No - that's why we need a citation style language to define output (to screen or report) templates for "citations". If I sent the marriage out, then in the perfect world, I would also send the output template or send a reference to a standard agreed templates for UK Parish Registers.

Then by putting the template and the data together, the recipient can recreate my citation. And if it looks different - well, it doesn't matter if US genealogists put the author's name after the title because it's unpublished, or put it before like I do. (I'm making up differences). Because the data is there in the BG file marked up and even though the citation is different, the DATA is correct because it's all marked up.

I can see no way in which this solution doesn't work. So far as I can see, the only difference is that you are insisting the templates have to be defined by BG as part of the BG language and be part of the BG data. There is no point to this - as the IT people have said time and time again, for anything more than trivia, it pays to separate the contents of the data from the presentation of the data. The templates and the BG data need to be defined in step, otherwise what is "author" in one will be "creator" in the other or some such issue. Therefore the same people on BG who understand citation styles ought to help to define the styles. But the citation style language is a different project and it would produce different files - which could be linked, like image files, or sent separately.

There is a further reason for separating output citation templates from BG. How many non-US applications support them? I bet very few. If you stick output citation templates into BG, then suddenly you demand all these applications do things they've never done before to gain BG compatibility.

They all support individuals, families, source, etc. They all support export / import via GEDCOM (else they wouldn't be looking at BG). Only a percentage will support output citation templates - putting output citation templates into BG will automatically mean the others fail to support BG right from the start. Doesn't seem a very good idea to me. (Remember, they're squealing about XML which is just a plumbing job compared to GEDCOM. Templates is a major piece of work and I bet half the globe really DOESN'T CARE).

Far better to have a separate initiative for these templates that can be picked up by those software suppliers that can deal with it and want to. Remember, BG ensures the correct data is present. The citation templates simply ensure that data is presented in the correct fashion.

@ Adrian,

"That's why we need a citation style language to define output (to screen or report) templates for "citations" (i.e. bibliography, 1st & 2nd reference etc)"

Except for your description of my work as "output," this is why Geir's document makes the recommendations it makes, and why I have commented that, until the solution exists, the only way to transfer your citations is to revert to the old way--just type them out.

As I've said otherwise, I never "get" to filling out forms unless I have a programmed citation template. Lacking the solution, there won't be a form for me to fill out. --GJ

"Far better to have a separate initiative for these templates that can be picked up by those software suppliers that can deal with it and want to"

Well, when that is all done, then I suppose BetterGEDCOM would have some possible basis for Tom's 3 & 4.

@ Adrian,

Why don't you just eliminate the concept of standardized elements all together. Just recognize the two levels* and allow vendors and users to define their own requirements. It will also support third party metadata, as others have done or do the work to make same available. --GJ

*I suggest calling them master source or source_record and "assertion level" or "source details"; I don't warm up to Tom's term "source reference" because that terminology is somewhat in conflict with established terms in metadata.

GeneJ,

Question:

But, if you had Standardized Elements, then the sending application and the receiving application would know what to do with that element.

I am really thinking about the Template issue.

If a template had a designation and could contain these elements, the receiving application would know that it is a template (some designation by BetterGEDCOM), then the application would know that the 3rd Standardized Data Element should be Italic, then the application would present the citation correctly.

Russ

Hi Russ,

Notice: Techies look away, Bear gonna employ user-speak.

There is a notion that templates are needed to convey formatting, but that is not the case in practice--templates often contain "bits" of contextual information.

For example, when I converted from Evidence to Evidence Explained styled templates, I wrote new 1880-1930 US census population schedule templates for my most common source type. It's form is somewhat as below (I'm a splitter; showing here a full reference note and changing elements and element names for the sake of simplicity):

[YEAR] U.S. Census, [COUNTY], [STATE], population schedule, [CIVIL DISTRICT]<, [PAGEREF1]>, enumeration district (ED) [ENUMERATION DISTRICT]<, [PAGEREF2]><, [HOUSEHOLD ID]>, [RECORD OF INTEREST] household< as of [DATE]>; digital image(s),< [WEBSITE OWNER],> [ITAL:][WEBSITE][:ITAL] ([URL] : accessed [ACCESS DATE])<, cites National Archives micropublication [REFERENCE]><; [M1]><; [CD]><. [M2]>.

You can see that I have "contextual" information written into the template; as far as data entry was concerned, I had a pretty efficient set up. I took the same approach with other census templates and after I had a couple thousand entries updated (sigh), I learned GEDCOM only transferred "elements." So, I rewrote all the templates and I'm still working to get those "couple thousand" corrected. Even today, though, many of my templates have contextual information in them.

GeneJ,

In what you posted, you have included the Source and the Citation.

Doesn't EE! give you TWO ways to ReCord a Census Record? Year and Year and State.

The other thing, is that the End User will most likely NOT see the data elements as in fields. Having said that, the way that FTM2012 has Templates, set up, based on EE!, the template provides Source Fields and Citation fields.

These are the Source Fields:

[YEAR] [STATE] [COUNTY] (IF Year State is selected) [WEBSITE OWNER] [WEBSITE] [YEAR] [URL]

{YEAR] is year the Census records were published.

The rest are in the Citation fields.

Russ

Hi Adrian,

" people think evidence can change"
:-( now I think I'm just getting my chain pulled.
http://bettergedcom.blogspot.com/2010/12/what-is-research-having-fun-with-body.html
See also Mills, _Evidence Explained_, 2007, 15.

I actually think user requirements are driving the discussions about sources and citations--it's just not an inclusive set of user requirements. Separately, though, "leave the _templates_ in your application"--hahaha. Those taking this position ought to just say what they mean--"We don't use 'em and have no intention of transferring your reference notes and bibliographies. If you want those to transfer, just type 'em out."

Err... really should have said, "unless you want your reference notes and bibliographic entries to look the way we think they should look, you'll have to just type 'em out if you want them to transfer."

"unless you want your reference notes and bibliographic entries to look the way we think they should look, you'll have to just type 'em out if you want them to transfer."

I don't believe OUTPUT templates belong in BG. By which I mean...

Templates in current apps serve TWO purposes - defining WHAT data is to be captured for that source type and how it is PRESENTED on screen or in a report.

What belongs in BG is the means of capturing what data belongs to each type of source record. That's about what data we hold so is firmly in BG's scope.

What is outside BG's scope, in my view, is the stuff about how that data is formatted when it's shown in a printout or on the screen. For instance, that the date is in format dd/mmm/yyyy or mmm/dd/yyyy or... Or that "New England ..." is in italics. Or that the bibliography entry for a census includes the XXX but not the ZZZ. All these are specified in what I call the output template. Why don't I want it in BG? Well, for a start what language are we going to use to specify these templates? Depend on it, 3 different current template using apps will have 3 different means of doing it. And if they can't agree on getting the data right, what chance do we have of getting them to agree that (say) TMG's or Zotero's output template definition language is the one to use? Or even agree that templates could be transferred? ("Our mechanisms are so superior that it is pointless to attempt to transfer them into others applications" sounds like one possible response.) That's why we separate data and presentation. One is bad enough, both together has about as much chance as getting Republicans and Democrats to agree on anything - said from the western side of the Pond.

What I have said is that if a language can be agreed for the output templates (or part agreed) then the templates could be transferred in the BG file package but not as part of the BG data. Think of images. We would be thought idiots of the first order if we attempted to define a means of encoding images. But difficulties exist in transferring images so we propose that a package (e.g. a zip file) be created containing not just the "real" BG data but also the attached images.

Similarly, I would propose that if software company X did export its templates, then the templates could be zipped up with the BG data in the zip file. BG the standard would known nothing of the templates could could easily transfer them in the zips just like images.

GeneJ,

I do NOT think the "leaving the templates to the application" is a smart think to do. However, I do think that as an End User, I want the Application to identify and to present to ME, the user, the output, as defined in Evidence Explained!. BUT, and I think this may be where applications fall down, is that the Data Elements, outlined in Evidence Explained! have been implemented correctly.

As the applications gives me the right fields to provide input to create the proper Template generated output, that application needs to hand off to BetterGEDCOM the Same data elements defined by that template. AND receive from BetterGEDCOM the proper data elements so that the application can do "its thing".

Template 46
Data Element 1
Data Element 2
Data Element 3
End Template 46

Russ

Hi Russ

Data Elements. "I think this may be where applications fall down, is that the Data Elements ...."

I knew you felt this say and I worked on that reasoning with Yates, FTM, RM and Legacy. I don't know if anyone on the planet who has worked harder to get those elements and values to line up.

It's the underlying language that differs between the programs. The elements and values are different, but all that is really based on the language. When combined the different languages and different elements/values don't produce the same result. (I know, sigh.)

We've done many tests; have published or circulated information about a couple. In a test about the simple journal entry (see, "The George Russell" for the 1964 article), I wrote three citations (reference notes and bibliography), and then tried to produce the same results in three programs--FTM-M, RootsMagic and Legacy. I produced a total of nine citations (three from each program)--six of the nine were different than my control.

The differences in results are random (by source type, though, of course). In one of the tests (above) a program dropped the author, article title and its location from the bibliography. In another test we've published, one program dropped the civil district from the reference note about a census. There are many more punctuation differences, which of course are even more tedious to observe.

So, assuming you can even identify corresponding pre-packaged templates, and even if there were identical elements (= in theory, set up a perfect element/value transfer), the results "break" when you move from Program A to Program B. (This gets back to that same user requirement I mentioned … it's about the reference note and the bibliography=it's about trust).

Okay, so what if they are different? Transferring from me to you might not be a problem (lots of folks would expect to review every entry sent to them by a third party … especially source hounds like you and me). BUT, synching/transferring from me to me just doesn't work, and, it's a silent failure (no warning). Since this is a numbers game (ala, I have 6000 master sources and bibliographic entries, and 40000 reference notes), fix-after-the is not a reasonable workaround, especially given that some programs have well in excess of 1000 different default source types.

So, it is common that results are not equal (from program to program) and even vary from Mills. To me this suggests there are frequent customizations to those default templates. Not all these programs use the same customization techniques. In the case of FTM-M, customizations can be entered free form (actually overwriting the programmed elements/programmed citation--my description).

The comments above pretty much assume all the elements and values in all the programs matched, and comparable templates exist in all the programs (none of which is true today). But we know the elements and values are different. And also …

The data type differences are material, and data types are integral to each language.

There is a significant structural/mechanical difference between FTM-M and the other two programs. RootsMagic and Legacy use a "source details" form/template at what I call the assertion level. Any number of distinct fields may appear in that "source details" form/template. FTM-M uses the more traditional GEDCOM fields at the assertion level. (In RootsMagic v5, I believe that what was GEDCOM "PAGE" is now "Research Notes.")

There are structural differences, too, between the content (elements/values) of RootsMagic and Legacy's "source details" form/template. (What one puts in the Master Source appears in the source details of the other program).

I guess I could go on and on, because I think there are far more issues to consider in an "element only" approach. If folks really believe the element only approach will do more than just "break" the existing program language, I hope they will conduct and share the research showing otherwise.

Sorry for all the typos in above. --GJ

GeneJ,

Your long note is a valid indictment of GEDCOM's inadequacies in not providing enough data elements. It is not an indictment of data elements.

The results of GEDCOM-only experiments simply prove those inadequacies and the inconsistencies of how program developers have interpreted GEDCOM.

Those results don't have anything to do with Better GEDCOM, other than to continue to support my requirement that Better GEDCOM must be a data format that includes the data models implied by the set of good genealogical programs.

Actually, Tom,

Oh, please explain how you could conclude the post of late yesterday had anything to do with GEDCOM only experiments? --GJ

I believe it is easy to understand. Every transfer, either to and from the same program, or between two programs, involves a GEDCOM export and import, whether that is visible to the user or not.

In your experiments you are doing two things -- first seeing if the user interface of a program allows you to enter a particular type of citation -- second seeing if you can do round trip or two way transfer of those citations.

Neither of those things has anything to do with Better GEDCOM other than being a warning that Better GEDCOM must ENABLE (note stress) intelligent application developers to be able to support two way transfers of citations created by any other program. The results of these experiments have nothing to do with the ultimate nature of sources and citations, and neither has any bearing on the issue of data level versus presentation level. For me it is just a long distraction that takes us away from the real issues, which are (repeating for the umpteenth time) doing "my tasks three and four," which is determining the source types BG should support, and the citation elements that are needed to support each one.

My DeadEnds model, expressed by the document I made available, handles all these data issues simply and completely -- the model is set up to handle any number of source types, any number of citation elements, that can be shaped to create any kind of citation you wish. That model is data only, as it assumes that application developers are sufficiently intelligent (as they have proved themselves to be in many instances) to be able to apply a template approach to get citations prepared into publishable form. There are no templates in the DeadEnds model, because the DeadEnds model separates data from presentation (though I believe a strong argument can be made that notes be allowed to have simple semantic markup for things such as headings, list elements, and emphasis, though none of these are presentation level).

Some seem to have taken the view that those of us who believe that templates should be application only, that Better GEDCOM should be data only, are villains who are set out to destroy Better GEDCOM because of some hidden agendas of our own. For me this demonstrates an abysmal lack of understanding.

Hi Tom,

I'm still reading your posting, but actually, I didn't have to make any GEDCOM transfer to accomplish my findings.

I either already know the "template" or have done what I consider the necessary work to reverse engineer a knowledge of the template.

Based on that work, I know that even if the receiving program was sent an ideal set of your "data" the result will not be the same as it had been in the sending program.

@Tom,

I realize your Dead Ends model meets all of your needs.

It may surprise you to realize that users of other developers programs are big fans of the support in those programs.

That the systems are not compatible is further evidenced by the different arrays of default templates in the different programs--one has 170, another has about 400 and a third, between 1000 and 1500. As well, that all of the programs enable customization in one way or the other.

Based on that work, I know that even if the receiving program was sent an ideal set of your "data" the result will not be the same as it had been in the sending program.

GeneJ,

Not sure what you mean here. Are you saying that if Better GEDCOM were released as a data only system, we would necessarily have the same problems we have now with GEDCOM? And since you said 'your "data"' are you suggesting that that would be my fault, or at least the fault of the people who believe that BG should just hold data level information?

Why do you believe that the results of the experiments have any predictive power with respect to Better GEDCOM? Don't you see those experiments as simply a demonstration that Better GEDCOM needs a more comprehensive data model for sources and citation elements. Can you provide any solid reasoning why performing "tasks 3 and 4" is not sufficient for creating a data model that will allow complex citations on one system to be passed through unchanged to any other system that supports Better GEDCOM?

Hi Adrian,

"_Unresolved_ conflicting evidence is incompatible with a conclusion."

That is exactly as I read it, and so long as folks believe "sources [and citations]" should be separated from conclusions, and that the Genealogical Proof Standard is FUD, I suppose folks like me will continue to quote Tom Jones ... and further that some will see it as "sheer effect."

http://bettergedcom.wikispaces.com/message/view/Sources+and+Citations/48324558

http://bettergedcom.wikispaces.com/message/view/Sources+and+Citations/48595258

Sorry Gene that doesn't make sense to me...

If you quote it - why?

And what has the GPS got to do with it? GPS provides a set of measures that imply a skeleton process, so far as I can see. A step in the GPS implies the resolution of conflicting evidence, so I'm missing the point of a quote that is a (presumably) misleading version of that step.

The "Report Writing" topic was an attempt to discuss how to mark up the data and so create the sort of rich reference notes that you produce from your current applications. That's about output and is independent of how the conclusions enter the database, whether through an informal process of reasoning or a formal set of reasoning cross-checked explicitly against the GPS.

Well,

Direct evidence that is uncontroverted doesn't require a proof, right.

I don't think the statement is misleading ... but then again I strive to practice my genealogy in the spirit of the GPS.

As for the "Report Writing" topic ... well, my reference notes are not about "output." I said it a dozen times.

I'm glad that some developers took to creating the powerful technology that supports programmed citations. If they hadn't, I'd be typing those formed reference notes right into my software for each and every assertion.

If that is the only way reference notes can be shared in BetterGEDCOM, I supposed a lot of us will be going back to the old way of doing things.

Gene
"Direct evidence that is uncontroverted doesn't require a proof, right?"
I think you're using "proof" in a different manner from me. If I have a birth record saying "Simeon Doe was born Manchester, Lancashire, 26 Jan 1801", that sounds like direct evidence to me. Yes, in the absence of any contradictory evidence, it doesn't require any further processing. But what we _do_ need somewhere attached to the assertion or whatever is the "proof of identity" - i.e. is it "my" Simeon Doe? (assuming I have one already) - e.g. something like "the Manchester parish records for 1700-1900 show only one Simeon Doe being born / baptised, only one being married (previously identified as 'mine') and only one being buried (previously identified as 'mine'). Ditto censuses. Therefore by lack of alternative we deem this to be mine." So - no, we don't need any further analysis of the evidence but we do need a proof, the proof of identity.

"I don't think the statement is misleading ... but then again I strive to practice my genealogy in the spirit of the GPS" Well, you'll need to excuse my dedication to terminology here from my mathematics and computing background. You already said you agreed with my interpretation that the word "unresolved" ought to be in there, so in practical terms of what we do, we're in agreement. I imagine that your dedication to GPS makes you interpret and adapt phrases and stick in - very correctly - the extra steps. On the other hand, my own backgrounds in maths, IT and the occasional times I tried to write down procedures make me absolutely concerned to remove all ambiguities. (That often seems a pious hope rather than an achievable objective). My objection to "Conflicting evidence is incompatible with a conclusion" is that a piece of evidence does NOT change during my research (unless I misread the writing). That's the literal truth of what evidence is - as Louis says, "just the facts", so it can't change and it'll always be conflicting so we can never come to a conclusion. Huh? Clearly both you and I deal with it, we do come to a conclusion and we don't lie awake at night concerned we've broken the GPS or whatever mental model I have of proof. Sticking the word "unresolved" in makes it work - "_Unresolved_ conflicting evidence is incompatible with a conclusion". The fact that none of the Google repeats of the phrase explain this leads me to worry that:
1. people think evidence can change or
2. people reinterpreted the phrase like you but haven't made it clear for the less adept what's really going on or
3. people really don't care about precise words - and besides, it's a good shock phrase and to with logic.

"my reference notes are not about "output." I said it a dozen times." OK - whatever word you want to describe them with, they exist in your data and we want to try and store them in BetterGEDCOM.

"If [typing those formed reference notes right into my software for each and every assertion] is the only way reference notes can be shared in BetterGEDCOM, I supposed a lot of us will be going back to the old way of doing things." Nooooo - this is why I'm so frustrated - we were trying to work out what data is needed to support "the powerful technology that supports programmed citations", in other words what _data_ does BG need to hold to support storing the data for those powerful reference notes? (Bear in mind that BG is about data - the majority of us would prefer to leave it to the templates in _your_ application to decide how that stored data is displayed in your reference note, whether printed or simply visible on screen.

Bear in mind I can't help you from experience because my software doesn't support complex reference notes and templates. I have got GENBOX (in read-only mode now) on my desktop PC but that is dead, deceased, an ex-PC.

Yes, Andy,

This certainly is an important part of 80-20. --GJ

Well- when those are finished, I've got the next 24. *grin*

btw- anyone know if FamilySearch has a list somewhere of their most searched databases?

If there is such a list, it might be interesting to compare the two.

"The next 24," .... OooO, I think Andy is on his way to a hit series.

LOL! You realize that Ancestry has 30,500+ databases- right?

That means I can produce 1,271 lists.
*evil grin*

;)