Comments

OK let me add my thoughts as the person who did a lot of the boiler plate for the "User Requirements". Normal practice is indeed for a Requirements Catalogue to be split between "user" and "system" requirements. However, it simply didn't work. Let me quote from the Req Cat page http://bettergedcom.wikispaces.com/Better+GEDCOM+Requirements+Catalog thus:
Quote starts:
"A division between functional and non-functional requirements is traditional in Requirements Catalogues. Functional requirements say what the new system should do (e.g. "Pay staff according to the 1929 Conciliation Staff Agreement") - non-functional requirements say how the system should do it (e.g. "Pay 10,000 staff overnight each Tuesday", or "Run on Windows 2000 Server OS"). As a result, the "techno-speak" requirements are part of the non-functional requirements.

"Given that the BetterGEDCOM file format does not do anything itself, it is debatable how relevant the division is, so, after trying to keep to it, I am putting them all together."
Quote ends.

For the avoidance of doubt, "functional and non-functional requirements" are equivalent to user and system requirements.

Let me put it another way - there are NO end-user (note, end-user) requirements in BetterGEDCOM because the end-user does NOT use BG (or GEDCOM). No, you _don't_. You do / will / would use an application program that uses the GEDCOM or BG format. Of course, you the end-user DO have a series of very justified user requirements for the transfer of your data but the BG project CANNOT satisfy those requirements. Only your application provider can satisfy those requirements and they might attempt to do so using GEDCOM or BG or GenBridge or AncestorSync or an API to newFamilySearch or.... BG would simply enable one of those _technical_ solutions just as GEDCOM enabled one years ago.

So trying to concoct end-user requirements on BG is a waste of time and just leads to frustration from both the end-users and the IT guys. The IT guys need the end-users to describe the type of data that is to be transferred or stored. The end-users needs the IT guys to concoct words and concepts that are at least part way IT literate.

PS - Russ - re storage. I'm an end-user and I have a user requirement to store my data in a standard file format. Hence my insistence on storage being in BG's goals. You may not wish to use that facility. Fine. I do. And yes, I do understand that as soon as anything is taken out of the app it's frozen.

Adrian,

As I have said, I was responding to Andy's comment about User Requirements.

My concern about storage is the ability to be able to do something with that "stored" file in the future. To me, in the list of tasks for BetterGEDCOM that "feature" would be low on the priority list.

If 'storage' is archiving of a file, what would be different. I have archived GEDCOM files on my PC. I can open them IF my Genealogy Management application will 'read' that version of a GEDCOM file. Today, it won't open a GEDCOM version 5.3, (as I recall), but it won't even open an earlier version of its own file.

My question about storage is a resource issue for this project.

Thank you,

Russ

Hi Russ,

Lemme tinker.

I've said there are other benefits to standardization. Separate from file sharing, there are important benefits in terms of innovation, trust and interoperability issues reaching to a cross discipline level.

There are also common concepts-like terminology/communication and efficiency.

You asked why a vendor would favor standardization. Well, innovation, trust and interoperability are pretty important to vendors, too. I'd add that having an organization that engages the broader group of international stakeholders and also supports/promotes the standards developed is also not a small benefit.

I know that is not the picture of BetterGEDCOM as you see it. I won't disagree, but as a member of the committee working on the organization, I don't think it's theory, either.

You wrote, "... those alternatives are going to reduce the need for any standardization." Somewhat a separate topic, but I see file sharing without standardization as a very expensive, intensive effort. I tend to think standardization change the market dynamics of "file sharing" more than the other way around.

Back at you ... thanks for listening. --GJ

Hi Adrian,

"Let me put it another way - there are NO end-user (note, end-user) requirements in BetterGEDCOM because the end-user does NOT use BG (or GEDCOM). No, you _don't_. You do / will / would use an application program that uses the GEDCOM or BG format."

(a) Actually, I'd like to challenge that notion. The very first time I had a file sharing problem/conflict), I was told it had nothing to do with the vendor. I should open up the GEDCOM in my text editor and make the changes myself--even write a macro for it. Since then, I've seen post after post on user mailing list where folks are told to do just that to fix their "user" problem.

(b) There are users like you, Adrian, who are talented enough to do a little work "under the hood" in the software you use--so that you get a little more mileage from the program you use. And talented users like Tony and Louis, who will develop their own models because they want certain features.

(c) How about folks like Randy Seaver--he's determined to be able to sync his stuff. So much so that he'll figure out his own work arounds, even when that means foregoing many of the benefits developers intended he might enjoy.

(d) There is certainly a group of users who just don't know any better. During a talk about GEDCOM, folks were moaning and groaning when one user chimed in saying she never had any errors with GEDCOM. I got a private message, I think from Myrt, saying, "Oh, Dear ... she just hasn't LOOKED yet." So yes, you have the group that just doesn't know, or know yet.

(e) And then a final group. "Since it doesn't work anyway, why bother/who cares."

Adrian wrote, "Of course, you the end-user DO have a series of very justified user requirements for the transfer of your data but the BG project CANNOT satisfy those requirements. "

If that is the case, then what possible justification is there for all that work to be done.

I said that "the BG project CANNOT satisfy those [user requirements for the transfer of your data]"

Gene asked - not without reason - "If that is the case, then what possible justification is there for all that work to be done?"

Because BG aims to provide a thing that ENABLES software suppliers to fulfil your requirements in a sensible manner. You mention above "file sharing without standardization [is] a very expensive, intensive effort". Absolutely. The Genbridge effort required - theoretically - a custom interface for each pair of supported programs. E.g. 10 supported apps requires 10 x 9 = 90 interfaces to be coded in Genbridge. 10 supported apps using GEDCOM requires only 10 x 2 interfaces (one in, one out) = 20, each to be coded by the experts in the software, not someone who's trying their best but who isn't an expert in the relevant app. I'm not decrying what Genbridge attempted but it was an inefficient means of solving the problem.

I said "the end-user does NOT use BG" - Gene responded "Actually, I'd like to challenge that notion". OK - you must have been listening to the neurons in my brain just to the left of the typing part. Yes, there are people who read and even hack their GEDCOMs. Or work to the lowest common denominator. But we need to satisfy the 90% first. Taken to extremes, we cannot twist the BG product to satisfy the needs of a few geeks - we need to take our chances with whatever comes out to satisfy the needs of the many. (And I'm thinking Spock's final words in The Wrath of Khan - obviously getting too late over here). The ordinary user should not need to look inside a BG file. HOWEVER - thinking about it, the need to repair a BG file does sound like a legitimate end user requirement on the structure and format of the BG file - the only one I've yet seen.

Users have to sometimes get down to the level of looking at actual GEDCOM files because of all the bugs and mistakes in programs that claim to support GEDCOM.

How is this an argument that Better GEDCOM needs user requirements? Are we that positive that we are going to fail? Looking for some common sense here, folk.

Hi Adrian,

It seems to me that sources and citations needs a standard that would then support file transfer.

At least I think that is what Geir had in mind when his proposal was developed. --GJ

Tom said - "Users have to sometimes get down to the level of looking at actual GEDCOM files because of all the bugs and mistakes in programs ... Are we that positive that we are going to fail?"

I think it's 99% certain that there will be errors in the way applications support BG. That being so, it seems eminently sensible that the BG data within a BG file should be readable and editable by a reasonably confident end-user who's familiar with text editors etc. I think that's a reasonable requirement. It so happens that if you class requirements into "user" and "system" requirements, then you might well put editability into the "user requirements" pot. That happens to be the only way that I can think of that a normal end-user might interact directly with a BG file, so if I did split requirements into "user" and "system" requirements, then that'd be the only "user" requirement I can think of on BG. Since, in fact, my classes are not quite the same I can't lose any sleep over what it's called so long as (a) the requirement is accepted and (b) the general concept that users do not deal with BG file content directly, aside from this one exception, is appreciated.

Gene - "It seems to me that sources and citations needs a standard that would then support file transfer"

Quite agree. The data kept about sources and about "citations" would be part of the BG standard, supporting file transfer. Just the list of "what" is kept for a source etc of whatever type.

The way citations are presented on screen and for printing have several standards already - Chicago, ESM, etc, etc.

The way such citations can be codified and so used by a computer is also already in at least one standard, isn't it? By which I mean CSL as used by Zotero??? So would we want to duplicate that work in BG? I think not. What we would want to do is enable the transfer of CSL (or whatever it is) files as attachments to BG files, just like images are also transferred as attachments (and note neither BG nor GEDCOM define the format to encode an image)

Hi Adrian,

BetterGEDCOM is about developing open standards, a project to support file transfer exists ... that project needs a standard for sources and citations.

I'm saying we need to get beyond the file transfer discussions and start developing the standard. I believe Geir's document approaches the issue this way.

P.S. I don't believe we should be standardizing "a" style, but do think we can develop a default style and we can perform the work to help standardize a comparable part of the Mills style.

I tried to avoid commenting here as I feared it would be fruitless. However, I'm afraid I couldn't hold back :-(

I think this schism is in danger of fatally dividing the group, and I don't know how to reconcile it. It has been discussed in multiple threads so far but apparently with no full understanding of each others thoughts and requirements.

I fully understand Adrian's post, which probably means we have a similar background, and I largely support it. I know, Gene, that you feel this is dismissing your many complex citations as "mere presentation" but that is far from the truth. Unfortunately, different "languages" and academic backgrounds are probably making this more of an issue than it really is.

An ideal design would be able to transport "the essence" of a set of citations from one person to another, and still leave the recipient with a choice of which citation style to view them in, and how date and numeric values would be presented to them. I would not take kindly to receiving a set of "hard coded" (i.e. immutable) citations whose style and cultural variations conflicted with my own. And I'm sure the reverse would be true.

Adrian is suggesting that BG should address how "the essence" of a citation is depicted - which is really the only way to achieve this ideal design. Whether we also work on an adjunct to the BG standard that defines how its meta-data turns into a real humanly-readable citation reference, or assume something like CSL will do it, is then a different issue that we can debate. I would personally prefer that we also define that mechanism, albeit in an abstract way, such that various physical implementations can plug into our standards rather than vice versa.

What Adrian suggests, and what I have suggested in earlier threads, would work well for 'simple citations'. Where it becomes a little muddy is for 'compound citations' where there may be multiple simple citations involved, with/without author annotation that identifies the context of how it supports/contradicts assertions and theories. The STEMMA format discusses this, and makes some progress, but it doesn't present a clear-cut answer either. :-(

I hope I'm not annoying anyone here. I would like us to understand each other without assuming anyone of us are being obtuse or naive.

Tony

Hi Tony,

While there will be other "stress tests," the focus of these discussion is mostly the me-to-me transfer (as opposed to me-to-you). It's not that we don't care about a me-to-you transfer, but the requirements are quite different.

Something akin to CSL, as Geir discusses, needs to be a part of the standards project.

I really don't think complexity has much to do with the issue--it's more about accurate representation following a me-to-me transfer. I don't care where you want your comma to go, I just don't want to redevelop my citations following a transfer.

Cool. --GJ

Hi Russ,

If you mean the following:
"We need a renewed focus on User Requirements and how the project is to be guided by to solutions by those.
See follow up item about User Requirements. (Louis will try to update XML vs GEDCOM in the Requirements Catalog as an example.)"

In this context "User Requirements' means the Requirements Catalog (http://bettergedcom.wikispaces.com/Better+GEDCOM+Requirements+Catalog)

I'm not certain, but I think you are meaning it (User Requirements) in a different context. If so, perhaps you could start an 'End Users Requirements' page for discussion.

Andy

Andy,

I think that what this group has been working on are SYSTEM requirements.

As for End User Requirements, we have had that documented from the beginning.

To quote one of DearMYRTLE's blog posts:

<italic>

End-user to end-user

Where Researcher A exports a GEDCOM file from his genealogy management program and then directly shares that file with Researcher B via flash drive, CD or some other means. Researcher B opens his genealogy management program and then imports the GEDCOM file. <italic>

The ability to Share our Genealogy Research between Genealogy Management programs, faithfully, meaning without loosing or changing of content.

As I read this wiki, these are System Requirements, meaning, how to accomplish the above, with some look into the future, or some concepts that the genealogical community is developing, or wasn't there with these genealogy management programs were developed (i.e., GPS).

Clearly, as demonstrated on the Blog, the biggest issue has been Source and Citations. Which has taken up a lot of Wiki space, as it should, with GeneJ leading that effort, from the input of what she has provided.

Again, I was reacting to the term "User Requirements". If you all need more End User Requirements, then you may be right about starting our own.

Looking forward to see what Louis makes available.

Thank you,

Russ

I believe the consensus is that Better GEDCOM is a formatting standard for storing and transferring genealogical data.

User requirements might be thought of in a few ways with respect to a formatting standard. The first would be users who have to understand the format to the level of being able to read and write files written in the standard. These users are developers. But the requirements of being able to read and write files is so basic that I don't think we've ever thought of them as requirements.

Another way of thinking of user requirements might be to think about the programs that might use Better GEDCOM as one of their import and export channels, and the requirements that importing and exporting GEDCOM data puts upon those programs. The users here are the developers of the programs and the requirements would have to do with them understanding the underlying model of Better GEDCOM and being able to fully store that data in whatever database technology they choose to use, and how they choose to display the data in their user interfaces.

But I think Russ's users are the users of genealogical programs. But those users' requirements are actually requirements on the programs themselves, not on the file formats or any other infrastructure used by the programs. I think it is a fair question to ask whether there are any true user requirements on Better GEDCOM at this level at all.

In the requirements for Better GEDCOM that I wrote over a year ago I said something like Better GEDCOM must be able to store and archive data that is a superset of all the data used by all genealogical programs. To me this one requirement is the enabler requirement for all the user requirements for all the genealogical programs.

My overall point here is that the concept of user requirements doesn't apply to Better GEDCOM except for saying that a genealogical program must be able to import and export data in that format.

Tom,

You said:

I believe the consensus is that Better GEDCOM is a formatting standard for storing and transferring genealogical data.

Yes, I know that is what is agreed to. However, it has always been my opinion, (and I know my opinion doesnt count) that "Storing" is not, nor should be part of this project. I was overruled, which is OK, but the storage is DIFFERENT then the END USER requirement of Transfer.

Yes, you end up with a BetterGEDCOM FILE. But that FILE is an archive at one specific point in time, when that FILE was created. 30 seconds later, that file is OLD, outdated because I updated my database.

You, the developers are creating System Requirements.

IF you were the User, then you need to have the Vendors who create the Genealogy Management system at the table.

You, again this is only an End User opinion, are creating System Requirements on how a Genealogy Management system would generate a BetterGEDCOM file, and to Read and Understand a BetterGEDCOM file, so that it can be shared between Applications (Genealogy Management programs).

I still don't understand the Storing aspect. To me, storing of the information would then have to be updated, based on the Genealogy Management program updates. I don't think you are doing that.

For the application, Tom, that YOU have created, then yes, you are storing that, but as a Genealogy Management application. Its the Genealogy Management application that Stores the data and will be updated in the future. The BetterGEDCOM FILE is a time sensitive archive. I have many, many GEDCOM files that I have saved.

You said:
"concept of user requirements doesn't apply to Better GEDCOM"

I agree totally with you on that. I was responding to the wording in Andy's message about needing User Requirements.

You are, again, developing System Requirements.

You may understand "Interface to Interface" requirements, which to me is System Requirements, where Interface to Interface is Genealogy Management application to Genealogy Management application. Or Family Tree Maker to Roots Magic. FTM and RootsMagic are Storing and updating the Data that is being transferred.

As an End User, I want what I send to GeneJ or to your product, to get there and understood then presented to the End User.

Russ

Perhaps bit of a chicken and egg here?

Effective file sharing is just one benefit of standardization.

User requirements should be the basis of standardization, otherwise you are debating projects about technology solutions that seek some justification.

Are there approaches to file sharing that don't involve standardization? Yes--call it GenBridge and AncestorSync.

GeneJ,

I don't know if you are commenting on my comments or not, but again, I was ONLY responding to Andy's saying that we needed User Requirements.

I have stated my User Requirements for the BetterGEDCOM project.

The Real User Requirements would NOT go to BetterGEDCOM, but to the Vendor who I purchased my Genealogy Management program from. Which I have. But further, to have them consider what the BetterGEDCOM project is trying to do. One being Standardization.

You are correct about sharing that don't involve standardization. I am afraid that those alternatives are going to reduce the need for any standardization.

Why would any Genealogy Management application agree to a standard, if these alternatives already do the file sharing. Just askin.

Russ