Home > Goals > Requirements Catalog


Co-Moderators: gthorud and AdrianB38 Snapshots of the page

RULES

Discussions: All discussions about the content of this page shall appear on the discussion tab for this page. The SUBJECT of the topic shall contain only the ID of the requirement, "space dash space" and the subject of the requirement. There should be only one topic per requirement. Enter the Description and Why (see below) in the first posting in the topic.

New entries: All wiki users can add a new requirement. Please check if there is an existing entry for the same requirement, and if there is a similar one check the discussion of that requirement or contact the Proposer of the requirement to see if the existing one can be slightly modified to cover your requirement.If you are in doubt about which group the requirement should be placed, or if your requirement should be entered, contact the moderators, see the top of the page.

Entry Moderator: The person proposing a requirement is responsible for updating the catalog entry following discussion. Updates shall be "announced" in the discussion topic. See rules in the template below.

Requirements Catalog Index

Quick access index:
Administration Characteristics Confidence&Accuracy Conversion Data Date DNA Event Evidence Family Group International Multimedia Person PersonNames Place Ship Source Support Syntax Test Suite Text Handling Timeline


Background

Background to BetterGEDCOM

Background to these pages:
At the Developers' Meeting of 17 January 2011, it was resolved that BetterGEDCOM's existing list of Goals were not appropriate for Goals and the list should be re-structured to extract a simple Goal and reformat the rest as Requirements. This set of pages is being written to carry out that task.

Personal comment by the original author (Adrian Bruce) - the sections of this catalogue were previously used by me as a template for a full-scale IT project. Though trimmed from that, they may still be regarded as over-the-top for a Wiki-based project. Having previously got stuck on the argument whether we had goals or requirements, I would rather take too rigorous a path now. Inspiration comes from the Volere Requirements Specification Template in "Mastering the Requirements Process" by Robertson & Robertson. Note also that I use the term "project" for the BetterGEDCOM work, even though it (so far) satisfies no formal definition of what a project should be.

Goals of BetterGEDCOM

BetterGEDCOM will be a file format for the exchange and long-term storage of genealogical data.
It will be more comprehensive than existing formats and so become the format of choice.
(Note - first sentence is a minor rewording of Goal 1 agreed 3 Jan 2011. Second sentence justifies why BG and not an existing format.)

Clients, Customers, Stakeholders & Users

(This section is here simply to make you think)
  • Currently we have no identified Client paying for the project.
  • No-one will buy the BetterGEDCOM product itself, therefore we have no Customers in the proper sense.
  • Stakeholders potentially affected by BetterGEDCOM are developers of application software that reads or writes genealogical data.
  • Since data may be transferred from a BetterGEDCOM file into an application, and then to a genealogy service provider via an API in the application, providers of such networked genealogy services could be affected by the structures in BG, and could therefore seek to influence or control BetterGEDCOM.
  • Potential users of BetterGEDCOM include people or organisations currently holding files of genealogical data and people using application software that exchanges or stores genealogical data.
  • A very small number of people may manipulate data in a BetterGEDCOM directly - most users will not do so.

Requirements Constraints

(Not all of these may be relevant in practice)
  • The application software that will potentially read and write BetterGEDCOM data files is developed and maintained by many organisations, all of which are independent from the BetterGEDCOM project. Therefore the BetterGEDCOM project cannot directly control the match between BetterGEDCOM data files and the BetterGEDCOM standard.
  • An uncounted number of files of genealogical data exist in various forms of the GEDCOM file format. The design of BetterGEDCOM shouldminimise the effort required by application developers to write software to convert those files to BetterGEDCOM format.
  • Many of the existing files of genealogical data do not conform to any official version of the GEDCOM standard.
  • Many of those files have extended the GEDCOM standard with tags whose function is known only to the developers of the application software concerned.
  • Many of those files have extended the GEDCOM standard with events and attributes defined by the user of the application, and their meaning is known only to those users.
  • The GEDCOM Standard(s) are under the ownership and copyright of The Church of Jesus Christ of Latter-day Saints.

Naming Conventions & Definitions

See Glossary of Terms

Assumptions



Scope of BetterGEDCOM product

BetterGEDCOM will produce definitions of the file format in:
  • A report (definitely)
  • A data model (definitely)
  • A codified form applicable to the technology chosen for the file format - e.g. XML schema or DTD (possibly)

BetterGEDCOM should provide a test suite of data that will
  • allow software suppliers to assess compliance of their software
  • help them to diagnose issues
  • assist them to resolve issues.

BetterGEDCOM will not have responsibility for testing application software.

BetterGEDCOM will not have responsibility for defining how individual applications should translate genealogical data from their native formats to and from the BetterGEDCOM format, nor from application's own varieties of GEDCOM to and from the BetterGEDCOM format. (Experienced users may make suggestions, but the responsibility lies with the application's owners.)

Requirements Introduction

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.

The Requirements below use the following template.

Id:
Code to identify the requirement - in bold
Title:
A short description - max 10 words - in bold.
Description:
One or two sentences - use "must" if importance is mandatory; "should" if very desirable; "could" if desirable.
Importance:
One of three values: Mandatory; Very Desirable; Desirable. For the time being, this is the assessment of the proposer.
Why?:

Source:
If from another page or discussion, please note and link All previous discussions should go here, but the last/current discussion should be linked to in Discussion.
Way forward?:
Comments on possible ways forward
Dependencies:

Approval status:

Proposer:
The creation date for the requirement and wiki ID of the proposer. and optionally name.
Changes:
Date changed (month and day) eg. Feb 21 and user id, comma separated list. Append last change to end of the line, eg: 22 Feb gthorud, 23 Feb userxxx
Discussion:
Link to the current Discussion topic for this requirement. The subject of the topic should be the ID followed by the Title. See top of page.
Copy this Empty template to create a new requirement:

Id:

Title:

Description:

Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:



Again, acknowledgments are made to the Volere Requirements Shell template in "Mastering the Requirements Process" by Robertson & Robertson

Detailed Requirements


Research Administration


Id:
Admin01
Title:
Research Administration Information
Description:
BetterGEDCOM must allow recording of administrative information needed to organise and document the research work.
Importance:

Why?:
--- This is a place holder at the moment, details and detailed requirements to be added.
----- See the discussion of this requirement for summaries of the functionality in some genealogy programs.
Source:

Way forward?:
More detailed solution, see Admin02 onwards.
Dependencies:

Approval status:

Proposer:
7 March 2011 gthorud
Changes:

Discussion:
Discussion

Id:
Admin02 (was Task01)
Title:
Research Task
Description:
BetterGEDCOM shall be able to record and track a Task (search or other task) that needs to be done or has been done. Information recorded about the task itself could be a Title/Short description, a full description (formatable). Research tasks can be organized in simple lists or grouped into Objectives, see below.
Importance:
Very Desirable
Why?:
Supports faithful recording of research status and results, and reduces repetition of labors.
Source:
Gramps, GenTech model
Way forward?:

Dependencies:

Approval status:

Proposer:
BrianJD
Changes:

Discussion:
Discussion at Task01 - Research Task

Id:
Admin03
Title:
Task information
Description:
BetterGEDCOM shall be able to record information about a Task, for example used for Categorisation (keyword, category, type (research/correspondence/other)), Progress management (priority, staus, dates. comments about dates), Resource use (Expences, number of hours used)
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin04
Title:
Identification of persons, events, places that the task is about
Description:
BetterGEDCOM shall be able to link a task to records representing the person(s), event(s), place(s), source(s) etc. that the task is about, existing when the task is defined (started). A possibility is also to record links to persons, events etc. that are created as a result of the task.
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin05
Title:
What to search
Description:
BetterGEDCOM shall be able to record information about, or link to records representing, WHAT to search – e.g. a source. Possibly an URL pointing to the source.
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin06
Title:
Where to do the task
Description:
BetterGEDCOM shall be able to record information about, or link to records representing, WHERE to do the task – Location name (if not linked to), Repository, Place (eg. cemetery), Address
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin07
Title:
Task results
Description:
BetterGEDCOM shall be able to record information about, or link to records representing, the findings and results produced by the task (an overall description of the results, Excerpts, Multimedia, Citations, Filing Cabinet Reference)
Importance:

Why?:

Source:

Way forward?:
The information recorded for this requirement overlaps with the information in the Evidence and Conclusion model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin08
Title:
Objectives - for grouping of tasks
Description:
BetterGEDCOM should be able to group several tasks into Objectives (Target) , each Objective representing a question to be answered or a problem to be solved. An objective is usually defined before the tasks needed to achieve the objective. Objectives should have a description and will be the record pointing to users, events, places etc rather than each task. Some elements of the information recorded for tasks (see above) can be defined for the objective rather than each task,
Importance:

Why?:
Questions and problems are in most cases the reasons that one or more tasks are performed.
Source:

Way forward?:
An objective record may contain elements of the info mentioned in Admin03
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin09
Title:
Projects - for grouping of objectives
Description:
BetterGEDCOM could be able to group several objectives into projects. Projects could be split into sub-projects. Each (sub-)project should have a name, elements of task progress listed above, completion grade (%) and description.
Importance:

Why?:

Source:

Way forward?:
A project record may contain elements of the info mentioned in Admin03
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin10
Title:
Correspondence log
Description:
BetterGEDCOM could be able to record information about letters, emails, phone calls or other correspondence related to the research. Item in the log can have a type (call, email etc), direction (in/out), researcher, correspondent, subject, date, reference to filing system and details about the correspondence. Contact information (address, phone etc) could also be recorded..
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin11
Title:
Researchers
Description:
BetterGEDCOM could be able to record information about the researchers using the program or other cooperating/corresponding researchers. Researchers can have a name, languages, registration number (?), notes, media (photo) and contact info. A researcher can be linked to a person in the database. The Gentech model also links researchers to assertions, i.e. who made the assertion.
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Admin12
Title:
Support Privacy Settings
Description:
Genealogy programs must support the user by providing controls/options/settings/reports to assist the user in maintaining the privacy of the people in the database, particularly those living.
Importance:
Mandatory
Why?:
Users will need to differentiate between data that can be shared or not. Users may need to differentiate between different data that be shared with different groups of people. For example, only the data related to one branch of a family would be shared with the people in that branch.
Source:
NGS Standards For Sharing Information With Others
Way forward?:

Dependencies:
The following requirements may impact or be impacted by this requirement:
  • Conversion02 - Support for generating web pages
  • Data06 - Transfer between one user's programs and to other users/services
  • Data-Ind01 - Data about persons
  • Data-Ind02 - Biological relations independent of family
  • Data-Ind04 - Sex-change individuals
  • Data-Place06 - Location to include address
  • DNA01 - Results from DNA tests
  • Multimedia02 - Information about multimedia objects
  • Multimedia03 - References to Multimedia
  • TextHandling03 - Footnotes/endnotes in notes
This list may be incomplete as requirements evolve.
Approval status:

Proposer:
12 Jul 2011 Christine_E
Changes:

Discussion:
Discussion at Admin12 - Support Privacy Settings

Confidence and Accuracy

Id:
ConfAcc01 (Confidence and Accuracy) (was Data03)
Title
Support for approximately known values
Description:
BetterGEDCOM must allow the recording of approximately known values in all appropriate contexts.
Importance:
Mandatory
Why?:
GEDCOM already allows dates to be "about yyyy".
Note - this is not the same as assigning a probability to a value - e.g. "Probably 1812" is not the same as "About 1812", and this requirement is not intended to cover concepts like "Probably 1812".
Source:
Tom Wetmore's Goal and Requirements plus various discussion pages.
Way forward?:
See Data-Date01 for this requirement on dates.
See Data-Place01 for this requirement on locations.
Work on the data model needs to establish if there are any other values that either need or would benefit from, the ability to record approximation.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:

Note that in this Catalogue, we use the term "Characteristic" to refer to what have been referred to as properties, facts, attributes, characteristics or traits. See PFACT in Glossary. Again, my use of this term does not imply that it should be the term used in the Data Model.

Id:
ConfAcc02 (was Data04)
Title:
Levels of Confidence in Database Conclusions
Description:
BetterGEDCOM should allow the recording of recognized levels of confidence associated with database conclusions
Importance:
Very Desirable
Why?:
Supports faithful recording of research status and results. This uncertainty / level of confidence can apply to various sub-items, including, but not necessarily restricted to, dates ("Probably 1812"), places ("Likely London, England") and relationships ("Possible father is ...").
Source:
_Evidence Explained_, 2007, p. 19, "certainly," "probably," "possibly," "likely," and "apparently," "perhaps"
Way forward?:

Dependencies:

Approval status:

Proposer:
GeneJ
Changes:
2011 Feb 21 - created
2011 Mar 21 - add examples to "Why".
Discussion:
Discussion at Data04 - Levels of Confidence in Database Conclusions

Id:
ConfAcc03 (was Data05)
Title:
Universal Qualifier Symbol ("?")
Description:
BetterGEDCOM should incorporate methods allowing users to apply the universal qualifier "?" before dates (or parts of dates), locations, names, etc.
Importance:
Very Desirable
Why?:
Supports faithful recording of research status and results.
Source:
Hoff and Leclerc, _Genealogical Writing in the 21st Century_ (2006), p. 115, "Commonly used Symbols," for "?" as, "uncertain interpretation of original text."
Way forward?:

Dependencies:

Approval status:

Proposer:
GeneJ
Changes:
2011 Feb 21 - created
Discussion:
Data05 - Universal Qualifier Symbol ("?")

Id:
ConfAcc04
Title:
Document Rejected Conclusions
Description:
BetterGEDCOM could allow the recording of rejected conclusions.
Importance:
Desirable.
Why?:
If a conclusion is rejected, it can be useful to record the rejected conclusion.
  • This should help to stop the researcher revisiting their own mistakes in future, when they have forgotten previous research;
  • Negative evidence can be useful in itself (e.g. "Thomas' mother was not Mary, so must have been Margaret or Molly");
  • Erroneous conclusions listed on the Internet are the bane of many genealogists' lives. It may be useful to have a refutation to hand.
Source:
Extension of Data04 "Levels of Confidence in Database Conclusions"
Way forward?:

Dependencies:
Data04 "Levels of Confidence in Database Conclusions"
Approval status:

Proposer:
AdrianB38, 2011 Mar 21
Changes:

Discussion:

Conversion

Id:
Conversion01
Description:
The coverage of the types of genealogical data must allow faithful import of data from all current, common genealogical software with no material manual intervention, subject to the limits of the applications involved.
Importance:
Mandatory
Why?:
If users cannot move their data to BetterGEDCOM formats, they will not use BG
Source:

Way forward?:
The data model for BetterGEDCOM must be rich enough to allow software companies to write routines to copy data from their internal file formats and / or their versions of GEDCOM to the BG format.
Therefore, the BetterGEDCOM data model must include everything in the current GEDCOM data model - but not necessarily in the same format - e.g. in-line sources could be converted to source records.
Dependencies:
We are dependent on the software companies writing that conversion code.
Approval status:

Proposer:

Changes:

Discussion:


Conversion02 - removed by the submitter. See discussion at Conversion02 - Support for generating web pages

Data

Note - The prefix "Data" is used for generic requirements that do not appear to be obviously applicable to only one group.

Id:
Data01
Title
Compatibility with GEDCOM
Description:
The data model that underlies BetterGEDCOM must be a superset of the models used by existing major, genealogical applications to the fullest extent deemed possible during design
Importance:
Mandatory
Why?:
BG compatible software must be able to import data from existing applications and must be at least as good as existing applications in relation to its model.
Source:
Tom Wetmore's Goal and Requirements
Way forward?:
Produce a data model to do this.
Dependencies:

Approval status:

Proposer:

Changes:
2011 Nov 15; Adrian B; rename from "Backwards Compatability" to "Compatibility with GEDCOM" to avoid use of "Backwards" - I thought that was the correct direction but others don't, so I avoid the use of the term - and correct the spelling as well.
Discussion:


Id:
Data02
Title
Support for all conventional genealogical processes
Description:
The data model that underlies BetterGEDCOM must provide a set of data entities that will allow genealogical applications to support all conventional genealogical processes.
Importance:
Mandatory
Why?:
BG compatible software must be able to carry out normal processes
Source:
Tom Wetmore's Goal and Requirements
Way forward?:
Produce a data model to do this.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:

Data03, 04 and 05 has been moved to Confidence and Accuracy.

Id:
Data06 (was Usage01)
Title:
Transfer between one user's programs and to other users/services
Description:
BetterGEDCOM should support data that needs to be exchanged between 1) one user’s applications possibly from different vendors or 2) several user’s/service provider’s applications.
Importance:

Why?
The requirement in these cases may be different, but betterGEDCOM must support both. For example a program may support management/classification/grouping of collection of media, e.g. photos. The grouping may not be of interest to other users, but should be transferred when the user transfer media between her/his own programs. Another example genealogy project management information, eg. planed lookups in a source, that may not be of interest to other users – but should be possible to transfer to the user’s other programs. Thus, all info stored by a program is a candidate for exchange.
Management data intended to be transferred between one user’s applications are not likely to be transferred to network services, and are thus not restricted by specifications that can be transferred to such services.
Source:

Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:
gthorud
Changes:
22 Feb gthorud
Discussion:


Id:
Data07
Title:
Independent record collections
Description:
BetterGEDCOM shall be able to record eg. only records containing information about places, without any person records or other types of records.
Importance:

Why?:
Independent record collections allows exchange of collections of source meta info, source data, place info, media meta data, media, timelines etc. This could facilitate projects where user could collaborate to create such collections, without having to rely on network services or other parties to provide the necessary facilities.
Source:
(Originally proposed by Tom in some discussion I can’t find)
Way forward?:

Dependencies:

Approval status:

Proposer:
22 Feb gthorud
Changes:

Discussion:
Data07- Independent record collections
Data08 - unasigned, see the discussion at Data08 - Importing Data (Proposal)

Id:
Data09
Title:
Collections of source data
Description:
BetterGEDCOM could allow recording of data from sources as a collection of records where none or only some are linked to persons or other records in the BG-file. Examples are transcriptions of a complete source or a section in the source, e.g. births in a church book, images of same or an index to the source.
Importance:
To be determined
Why?:
Often such collections are published in databases on the internet, but there could be many reasons why that is not practical, e.g. there might not be a database suited for the type of data or there could be copyright issues. It should be possible to search for data in a collection. It could be possible to link records in a collection to persons etc., incl source meta data, in the BG-file. It would also allow the user to see which records in the collection that are not linked to a person, and thus also to see that a candidate record in a collection is already assigned - thus avoiding e.g. to assign the same birth record to two different persons.
Source:

Way forward?:
The solution must be general so that it can handle many types of sources. For structured data, some general data elements, that are common to many sources, could be defined - facilitating searches across collections - e.g.given names, surnames, date of birth, "place of residence", place of birth (or place of event). Data could also be non structured text or images. An alternative could be to encode such collections in terms of persons, places, and events, in separate sets of data (some current programs can convert tabular transcriptions into Gedcom format), or keep the data in table structures with user assigned column headers imported from e.g. spreadsheets, possibly in a two level structure - one for the record (event) and one for the persons. A solution could also be used to store individual source records downloaded from web-services (would require a standard download format) or simply records entered by the user. There are lots of alternatives.
Dependencies:
This is somewhat related to Data07
Approval status:

Proposer:
gthorud 9 May 2011 - as instructed by todays Developer meeting
Changes:

Discussion:
Discussion at Data09 - Collections of source data

Characteristic


Id:
Data-Char01 (Characteristic)
Title

Description:
BetterGEDCOM must support the recording of the characteristics of persons, families, groups, places, "ships" etc.
Importance:
Mandatory
Why?
Current GEDCOM allows the recording of attributes for individuals and families.
Source:
Various discussion pages.
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Data-Char02 (was Data09 for Characteristics)
Title
Record locations for characteristics
Description:
BetterGEDCOM must support the recording of location values applicable to all characteristics of persons, families, groups, places, "ships" etc. (unless specifically agreed otherwise).
Importance:
Mandatory
Why?
Current GEDCOM allows the recording of place for attributes. Note this does not imply that the recording of a location against any particular characteristic makes sense - e.g. recording of a location against someone's sex would seem pointless. On the other hand, recording of a location against someone's name might well be useful - if someone emigrated under an assumed name, it might be useful to record USA (e.g.) against their new name, and England against their old.
Source:
Various discussion pages.
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:
2011 Mar 03 - split off requirement that location goes down to address to make it more obvious - raise new Requirement Data-Place06 for it.
Discussion:


Id:
Data-Char03
Title
Multiple Events & Characteristics etc
Description:
BetterGEDCOM must allow multiple characteristics and events of the same type against each person, family, group, place, "ship" etc.. In particular, it must be possible to allow multiple birth and death dates against individuals.
Importance:
Mandatory
Why?
Most applications allow multiple characteristics, occupations for instance, against an individual. Some applications allow multiple birth and death dates against an individual. The normal meaning of this is that these are alternatives. It must be possible to convert such data to BetterGEDCOM format.
As GEDCOM v5.5 allows multiple events and multiple attributes, including multiple birth-dates, this requirement is also mandated by the need to allow GEDCOM compatible data to be represented in BetterGEDCOM form..
Source:
Various discussion pages.
Way forward?:
Identify any events and attributes in GEDCOM that are currently only allowed to have one occurrence and decide what to do about these - with the exception of SEX, a first glance at GEDCOM 5.5 suggests the single occurrence items for the Individual are internal to the GEDCOM structure, rather than relating to their family history and genealogy and thus it may be appropriate for them to remain as single occurrence items.
Depending on the conclusions above, create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:
2011 March 05 AdrianB38 - split off sex-change to Data-Ind04
2011 March 05 AdrianB38 - add clarification that this is also a compatibility requirement.
Discussion:


Id:
Data-Char04
Title
Date all Characteristics
Description:
BetterGEDCOM must allow the recording of dates against all characteristics of each person, family, group, place, "ship". In particular, it must be possible to allow dates against an individual's name characteristics.
Importance:
Mandatory
Why?
While GEDCOM currently allows multiple names against individuals, there is no ability to record a date against each name, implying that the names are used at the same time. This may or may not be true. Allowing dating of names allows more precise description of married names, for instances.
Source:
Various discussion pages.
Way forward?:
Create this in the Data Model.
Dependencies:
Data-Char03
Approval status:

Proposer:

Changes:
2011 March 05 AdrianB38 - add title
Discussion:


Date


Id:
Data-Date01 (was date part of Data03)
Title
Approximately known dates
Description:
BetterGEDCOM must allow the recording of approximately known dates. This requirement refers to approximation of single dates only. The date in question may be represented as a single month or a single year.
Importance:
Mandatory
Why?:
GEDCOM already allows dates to be "about yyyy".
Note - this is not the same as assigning a probability to a value - e.g. "Probably 1812" is not the same as "About 1812", and this requirement is not intended to cover concepts like "Probably 1812".
See also Data03
Source:
Tom Wetmore's Goal and Requirements plus various discussion pages. DeadEnds Date Formats Dicussion of dates in the DeadEnds data model.
Way forward?:
Note that, for the purposes of clarity, date periods are covered by requirement "Data-Date04 Date Periods" and date ranges are covered by requirement "Data-Date05 Date Ranges".
Include this in the Data Model.
The existing GEDCOM options to be covered by this requirement are logically equivalent to the following phrases:
ABOUT date
ESTIMATED date
CALCULATED date
See pp39 & 40 in in GEDCOM Standard 5.5 for the meanings. No other options or meanings have yet been identified.
Dependencies:

Approv. status:

Proposer:

Changes:
14 May 2011 - added rows to requirement table; added discussion and link (GeneJ)
15 May 2011 - explicitly exclude the GEDCOM usages of date period and date range from this. It is acknowledged that some interpretations of "approximate" could cover date ranges, so we make it clear what the interpretations are.
Discussion:
Discussion at Data-Date01 (was date part of Data03) / Approximately known dates

Id:
Data-Date02
Title
Calendars
Description:
A BetterGEDCOM file must define the calendar to be used for each date stored in the file. This definition should be accompanied by a definition of the ordering of the date items within the date (e.g. year/month/day or day/month/year or month/day/year or ...)
Importance:
Mandatory
Why?:
Dates may occur in source documents in all sorts of calendar representations. It is desirable that the codified representation of that should differ as little as possible from the written characters in the source, to reduce the scope for error in input or output. Therefore, BetterGEDCOM needs to accommodate Jewish, Muslim, Chinese, etc, calendars, Julian or Gregorian calendars by country (e.g. with France and England on Gregorian and Julian calendars respectively(?) the two countries did not use the same day/month for "today"); French Revolutionary calendars, etc. Sometimes a date is just a text string.
Source:
Dicussion of dates in the DeadEnds data model
Way forward?:
Create this in the Data Model.
To be decided: Whether Data Model includes a facility for defining a default calendar and date-item ordering, or whether every date must be marked up with these items. If the latter option is chosen, this relies on intelligent application design to reduce user workload.
Note also - there is an assumption here that dates will be stored in various calendars and not as (e.g.) number of days since an agreed event.
Dependencies:

Approval status:

Proposer:

Changes:
2011 Feb 22 15:22 CET - alter description to "must" to match "mandatory" importance.
2011 Feb 22 15:43 CET - add to "Way Forward" comments about possible default calendar and assumption that dates will be stored in calendar form
2011 Feb 22 21:05 CET - alter description to separate definition of calendar itself from the ordering of the date items as these are 2 concepts. Also attempt to clarify Way Forward re defaults.
Discussion:
Data-Date02 modified

Id:
Data-Date03
Title:
Date phrases
Description:
BetterGEDCOM must allow a "date" to be entered as a phrase where the values are not recognizable to a date parser, but which gives a human reader information about when an event occurred. It must allow such a phrase to have an optional date in parseable format that can be used to interpret the phrase.
Importance:
Mandatory
Why?:
1. GEDCOM Standard 5.5 includes these two as DATE_PHRASE and INT <DATE> (<DATE_PHRASE>)
2. A phrase may give time-relative information even if a date is not known or not known well - e.g. "at the Battle of Brunanburh" is more informative than "between 934 and 939"; or "on a Tuesday in the spring of 1873" can be interpreted as 1873 but the words are informative.
Source:
GEDCOM Standard 5.5 Dicussion of dates in the DeadEnds data model.
Way forward?:
Include this in the Data Model
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:

Discussion:
Data-Date03 Date Phrases

Id:
Data-Date04
Title
Date periods
Description:
BetterGEDCOM must allow the recording of periods of time, denoted by start and / or end dates. BetterGEDCOM must explicitly define whether or not the end or start date is included in the period of time.
Importance:
Mandatory
Why?:
GEDCOM already allows this. Failure to include will result in failure to convert the vast majority of GEDCOM based files.
Source:
GEDCOM Standard 5.5, page 41
Way forward?:
Include this in the data model.
GEDCOM options are logically equivalent to the following phrases:
FROM date
TO date
FROM date-1 TO date-2
where date, date-1 and date-2 are known, unqualified dates - i.e. "FROM ABOUT 1066" is not included as the ABOUT is not permitted in this requirement.
It is suggested that the end or start date are included in the period of time as this is normal usage in the English language - e.g. "The First World War lasted FROM 1914 TO 1918" - 1914 and 1918 are included in the War's period.
The start or end date may be expressed as a Date Phrase, e.g. "FROM The marriage of Fred and Gladys Pugh"
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:
2011 May 15 - include this as a separate requirement, to make it explicit what Data-Date01 is concerned about.
Discussion:
Data-Date04 - Date periods

Id:
Data-Date05
Title
Date ranges
Description:
BetterGEDCOM must allow the recording of ranges of time, denoted by start and / or end dates, within which an event takes place.That event may take place on a single day, or it may take place over a period of days.
BetterGEDCOM must explicitly define whether or not the end or start date is included in the range of time.
Importance:
Mandatory
Why?:
GEDCOM already allows this. Failure to include will result in failure to convert the vast majority of GEDCOM based files.
Source:
GEDCOM Standard 5.5, page 41
Way forward?:
Include this in the data model.
GEDCOM options are logically equivalent to the following phrases:
BEFORE date
AFTER date
BETWEEN date-1 AND date-2
where date, date-1 and date-2 are known, unqualified dates - i.e. "AFTER ABOUT 1066" is not included as the ABOUT is not permitted in this requirement.
It is suggested that the end or start date are included in the range of time as this is the clear implication of page 42 in GEDCOM Standard 5.5, which explicitly states that:
1852 is equivalent and interchangeable with BETWEEN 1 JANUARY 1852 AND 31 DECEMBER 1852
The start or end date may be expressed as a Date Phrase, e.g. "AFTER The Fall of the Roman Empire"
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:
2011 May 15 - include this as a separate requirement, to make it explicit what Data-Date01 is concerned about.
Discussion:
Data-Date05 - Date Ranges

Id:
Data-Date06
Title
Approximate Date periods and ranges
Description:
BetterGEDCOM could allow ranges and periods of time, to be denoted denoted by approximate start and / or end dates.
Importance:
Desirable
Why?:
Many events cannot be located precisely in time - even the start and end dates can be unclear. GEDCOM has no means of expressing this.
For instance, "The Dark Ages lasted FROM ABOUT 410 TO ABOUT 1066 in England" (no arguments about the truth of that please!)
Source:

Way forward?:
Include this in the data model.
Dependencies:
Data-Date01 Approximately known dates
Data-Date04 Date periods
Data-Date05 Date ranges
Approval status:

Proposer:
AdrianB38
Changes:
2011 May 15 - new requirement
Discussion:
Data-Date06 - Approximate Date periods and ranges


Event


Id:
Data-Event01 (was Data10)
Title:
Events with multiple people, with roles
Description:
BetterGEDCOM must support the recording of events that affect multiple people. In particular, it must be possible to record the role of each person in the event.
Importance:
Mandatory
Why?
Events do affect multiple people. Current GEDCOM has almost no ability to record multi-person events, excepting perhaps births and adoptions. However, the parents of a birth in GEDCOM are usually implied by the parents of the appropriate family, creating potential issues when that family is an adoptive one. It would be better to have a birth event involving three people (e.g. child and two biological parents typically), with this data separate from the family.
Source:
Various discussion pages. A typical item in many other post-GEDCOM 5.5 proposals.
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:
AdrianB38 - 2011 Apr 17 - Add link to new discussion to record things we're liable to forget.
Discussion
Discussion at Data-Event01 - Events with multiple people, with roles

Id:
Data-Event02 (was Data09)
Title:
Multiple places per event
Description:
BetterGEDCOM should support the recording of multiple places for a single event.
Importance:
Very desirable
Why?
Current GEDCOM allows the recording of one place for events. There are application extensions to record more than one - e.g. FamilyHistorian records two places for emigration - a "from" and a "to" place. Users may also define "Journey" events, where a "from" and a "to" location would seem natural.
Source:
Various discussion pages. Qualifying Locations for Events
Way forward?:
  • Analyse whether there is a need for more than two places per event - e.g. "from", "to", "via";
  • Analyse whether location-roles are mandatory, optional or forbidden. (Location-roles refers to the role that a location plays in an event. Examples of roles are "from" and "to". Locations without roles would be just listed, e.g. "The 1906 earthquake happened at X and Y")
  • If roles are needed - what are the roles?
  • Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:
AdrianB38 - 2011 Mar 22 - make explicit this is multiple places for one event
AdrianB38 - 2011 Mar 24 - Clarify options for roles or not in 2nd bullet of "Way Forward"; Remove "Way Forward" bullet "Should multiple place events be listed?" as this is ambiguous and covered by 2nd bullet
Discussion:
Discussion on Multiple Places per event

Id:
Data-Event03
Title:
Central registry of event types (and possibly other types)
Description:
BetterGEDCOM should create a central registry of event types that are not defined in the main standard. The registry shall be updated more frequently than the main standard. It could potentially contain types used in structures containing non-standard type and value pairs. A procedure (rules) must be defined for maintenance of the registry. The information registered for event types (and other types) must be specified (eg. type name, definition, roles, event value types).
Importance:

Why?:

Source:
Custom GEDCOM Tags
Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Data-Event04
Title:
Events over a time-period
Description:
BetterGEDCOM must define what an Event is and must allow an Event to take place over a time-period of more than one day.
Importance:
Mandatory
Why?:
Current GEDCOM allows an Event to last for more than 1 day. Hence there will be many GEDCOM files containing such Events.
Page 35 of the (draft) GEDCOM v5.5.1 standard says:
"As a general rule, events are things that happen on a specific date. Use the date form ‘BET date AND date’ to indicate that an event took place at some time between two dates. Resist the temptation to use a ‘FROM date TO date’ form in an event structure. If the subject of your recording occurred over a period of time, then it is probably not an event, but rather an attribute or fact."
This can give the impression that events are only things that happen on a specific date.However, even this wording specifically allows events occurring over a period of time.
For clarity, the BetterGEDCOM standard must make it clear that events can occur over a period of time.
Source:
See discussion Syntax09 Define Event vs. Attribute. This discussion was primarily about distinguishing the difference between Events and Attributes if necessary. In there were various postings about the definition of an Event and whether it could last over several days or not. Those discussions stand independent of the differences between events and attributes.
Way forward?:
Define the event entity thus in the Data Model. Note the proposed definition in Syntax09 Define Event vs. Attribute that an event is something leading to a change - this might be a useful definition.
Dependencies:
Data-Event01 "Events with multiple people, with roles" and Data-Event02 "Multiple places per event" will influence the way forward on this.
Approval status:

Proposer:
AdrianB38 2011 Mar 25
Changes:

Discussion:


Id:
Data-Event05
Title:
Event Classes
Description:
BetterGEDCOM should define Event Classes grouping similar events into one class describing common rules for how the data recorded about events should be handled by programs. One example is a "Marriage event class" (this name may be changed) that would contain events such as Marriage, Civil Marriage, Cohabitation start, Partnership and other events that describes a union between two persons - all these events should be treated by programs as they currently handle marriage, although with different terms.
Importance:

Why?:
The purpose is to allow new events to be defined in the standard, a registry (see Data-Event03) or by users that will be handled by applications according to rules defined by the class that the event belongs to. The rules may be simple, just saying that the events shall be handled in the same way, when a new type of event is defined to be in the same class as a well established event type. Classes will be used when the event requires a more specialised handling than can be handled by a sentence template, e.g. when marriage events are placed in special paragraphs in reports - or depending on how data about families will be recorded in BetterGEDCOM, the event could be the basis for establishment of a data structure in the program representing a family.
Source:
This has been discussed in Data-Fam02 and in ?? (earlier discussions?) "I Want My Genealogy Software And BetterGEDCOM To Do This" on Shortcomings of GEDCOM
Way forward?:
The possible types of classes should be identified and populated with an initial set of events. The initial reason to do this is to verify that there is a need for classes. Rules should be defined for each class.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Data-Event06
Title:
Events as separate records
Description:
BetterGEDCOM must allow other records to reference events. Thus events should be recorded as separate records.
Importance:

Why?:
There is a need for other records to reference an event, for example from structures recording administrative information. Also, since we will have multiple persons participating in an event, the event should not be stored in the record of just one of those persons.
Source:

Way forward?:

Dependencies:

Approval status:

Proposer:
17 March 2011 gthorud
Changes:

Discussion:


Id:
Data-Event07
Title:
Person names per event
Description:
BetterGEDCOM must allow the recording of the name used by (recorded for) a person playing a role in an event.
Importance:
High
Why
A person may have used different names during his/her life, or one name may be recorded with different spellings in documents. For example, in many countries, people used the name of the farm where they were living, as a surname, so they would change their name when they moved to a new farm. It is best to record that name in the context of an event so it can be presented in the right context, rather than having a simple list of names as in current Gedcom.
Source:

Way forward?:

Dependencies:
Data-Event01
Approval status:

Proposer:
8 June 2011 gthorud
Changes:

Discussion:


Again, acknowledgements are made to the Volere Requirements Shell template in "Mastering the Requirements Process" by Robertson & Robertson

Family


Id:
Data-Fam01 (was Data06)
Title
Families independent of biological relations
Description:
BetterGEDCOM must support the recording of genealogy / family history data about the family as a (possibly informal) social grouping, independent of any biological relationship or legal adoptions.
Importance:
Mandatory
Why?
Family units exist where there is no underlying biological relationship and no legal adoptions.
Biological relationships exist where there is no family in any meaningful sense.
Existing GEDCOM files may contain data (possibly user-defined tags) recorded about the social grouping of the family, which must be carried forward on conversion to BetterGEDCOM format.
Note this requirement does not say anything about how that data will be represented on the file, specifically it does not say anything about how evidence and conclusions are represented.
Source:
GEDCOM does this. Various discussion pages.
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:
Data-Fam01 Family as a Social Grouping

Id:
Data-Fam02
Title:
Cohabitants
Description:
BetterGEDCOM must support the recording of information about cohabitants, with or without, common children. Cohabitants should be treated in the same way as married couples, and there should be events for the establishment and dissolution of "cohabintants". Some couples may start out as cohabitants and then marry.
Importance:

Why?:
The percentage of couples that are cohabitants is increasing in the western world, in some countries it is as high as 25-30%. BetterGEDCOM should not discriminate people in such relations.
Source:

Way forward?:
Depends on how BG implements relations/families in general. It may be sufficient with event types similar to marriage and divorce.
Dependencies:

Approval status:

Proposer:
26 March 2011 gthorud
Changes:

Discussion:
Discussion at Data-Fam02 - Cohabitants

Group


Id:
Data-Group01 (was Data05)
Title:
Data about groups of persons (eg. organisations)
Description:
BetterGEDCOM must support the recording of historic data about groups of persons, such as organisations, companies, regiments.
Importance:
Mandatory
Why?:
Organisations, companies, regiments, etc, have a major impact on individuals, yet no mechanism currently exists in GEDCOM to record any of their details in a structured manner, nor to link organisation data to people.
Note this requirement does not say anything about how that data will be represented on the file, specifically it does not say anything about how evidence and conclusions are represented.
Source:
Shortcomings of GEDCOM
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Person (was Individual)


Id:
Data-Ind01 (was Data04)
Title:
Data about persons
Description:
BetterGEDCOM must support the recording of genealogy / family history data about persons.
Importance:
Mandatory
Why?:
Statement of the obvious. Note this requirement does not say anything about how that data will be represented on the file, specifically it does not say anything about how evidence and conclusions are represented.
Source:
GEDCOM does this.
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Data-Ind02 (was Data07)
Title:
Biological relations independent of family
Description:
BetterGEDCOM must support the recording of biological relationships independent of any family grouping. Biological relationships must include surrogacy, etc.
Importance:
Mandatory
Why?
Biological relationships can exist where there is no family in any meaningful sense.
Existing GEDCOM files create a family for biological relationships. This is not always appropriate.
Note this requirement does not say anything about how that data will be represented on the file, specifically it does not say anything about how evidence and conclusions are represented.
Source:
Various discussion pages.
Way forward?:
Create this in the Data Model.
Dependencies:

Approv. status:

Proposer:

Changes:

Discussion:
Data-Ind02 Biological rel'ns indep of family

Id:
Data-Ind03
Title:
Non-biological, non-family relationships
Description:
BetterGEDCOM must provide a means to document relationships between individuals that are not based on biology or family, e.g. "X is the friend of Y".
Importance:
Mandatory
Why?:
GEDCOM has the ASSO tag in the ASSOCIATION_STRUCTURE (see GEDCOM 5.5) that may be used to document such relationship as god-parent, friendship, etc.
Also the ALIA tag can be used to link individuals' records, when the individual are suspected to be the same person.
Source:
GEDCOM Standard version 5.5 ASSOCIATION_STRUCTURE and ALIA tag
Tom Wetmore 2011 Feb 27 Syntax09 Define Event vs. Attribute discussion
Way forward?:
Comments on possible ways forward
Dependencies:

Approval status:

Proposer:
AdrianB38 2011 Feb 27
Changes:

Discussion:
Discussion

Id:
Data-Ind04
Title
Sex-change individuals
Description:
BetterGEDCOM should support the recording of sex-changes for individuals.
Importance:
Very desirable
Why?
There are individuals who have gone through a sex-change. BetterGEDCOM should be able to describe their history accurately, as it does anyone else.
Source:
Various discussion pages.
Way forward?:
Need to agree on what values are required - is male / female enough? Is there a need to consider not just sex (the biological and physiological characteristics) but also gender (the social construct)?
Dependencies:

Approval status:

Proposer:
AdrianB38 2011 March 05
Changes:

Discussion:


Person Names


Id:
Data-PersonNames01
Title:
Sorting on multiple given names and surnames
Description:
BetterGEDCOM shall provide a way to identify parts of names (whole words or parts of words) that shall be used for sorting, identifying if the part should sort as a given name or surname. It shall allow several such surname parts and could allow several given name parts. A priority could be assigned the name parts sorting as surnames. All this information related to sorting is a suggestion to the recipient for how name parts should be sorted.
Importance:
Very desirable
Why?:
Many cultures operate with several surnames. It should be possible to sort on those names in indexes etc. The same applies to given names (forenames) because a person may be known by any one of those given names. Some words in a name (eg. prefixes) are not used for sorting, and often the beginning of a name is not used for sorting (d’ in d’Hondt) (Honda should sort before d'Hondt), or one “word” may sort as two names eg. both Berg and Olsen in Berg-Olsen. When there are several surnames, some countries consider the last surname to be most "significant" while others considers the first to be the most significant. Identification of these parts have no influence on how a name is printed in reports or charts. The need to sort on several given names could be discussed, also the priority of surnames.
Important: For example, a middle name could indicated to be sorted as a given name or surname, but that does not imply that it is classified as a given name or surname in other contexts, and this proposal does not imply anything about any need to classify name parts as middle name, patronymic etc (which there may perhaps not be a need for).
Source:
Page: http://bettergedcom.wikispaces.com/Person-Name+Elements Discussion: http://bettergedcom.wikispaces.com/message/view/Person-Name+Elements/30777083 External Gramps page: http://gramps-project.org/wiki/index.php?title=GEPS_021:_Additional_Name_Fields
Way forward?:
A program could offer separate fields for the entry of these parts or use special notation.
Dependencies:

Approval status:

Proposer:
gthorud 25 Feb
Changes:

Discussion:
Discussion at Data-PersonNames01 - Sorting on multiple given names and surnames

Place


Id:
Data-Place01 (was location part of Data03)
Title
Approximately known locations
Description:
BetterGEDCOM must allow the recording of approximately known locations.
Importance:
Mandatory
Why?:
GEDCOM already allows dates to be "about yyyy". Locations may also be equally inexact, e.g. "at sea between England and Australia".
Note - this is not the same as assigning a probability to a value - e.g. "Probably London" is not the same as "Near London" and this requirement is not intended to cover concepts like "Probably London".
See also Data03
Source:
Tom Wetmore's Goal and Requirements plus various discussion pages.
Way forward?:

Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:
2011 Mar 22 AdrianB38 - rename from "Approximate known approximate locations" to "Approximately known locations"
Discussion:


Id:
Data-Place02 (was Data08)
Title
Recording of structured data about locations
Description:
BetterGEDCOM should support the recording of structured, historic data about locations, for example multiple names, default prepositions for names, photos, maps, sources and links for access to geographic information services.
Importance:
Very desirable
Why?
Current GEDCOM does not even recognise "Place" as an entity - there is a rich amount of information about places over time, much of which will affect people.
Source:
"GEDCOM Won't Transfer This" on Shortcomings of GEDCOM
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposal:

Changes:

Discussion:


Id:
Data-Place03
Title:
A place can be member of several place hierarchies
Description:
BetterGEDCOM should support the recording of places of various types as members of several hierarchies of places (locations), possibly changing hierarchies over time, and possibly with surety assigned to the relation to a higher place – in a way where the path through the hierarchy to the top is unambigously identified for each place name.
Importance:
Very desirable
Why?
Gedcom supports hierarchies of names in events, but does not link these names and hierarchies unambiguously to place entities. This is not sufficient to describe the facts of history related to a place.
Source:
tracking land changes idea” discussion and the Location entity page
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Data-Place04
Title:
Merging and/or splitting of places/locations
Description:
BetterGEDCOM shall be able to record identifiers of the place(s) that was split and/or merged when a place (location/property/region) was created.
Importance:

Why?:
The origin of a place is an important information about a place, and may in many cases provide evidence about relations between persons.
Source:
http://bettergedcom.wikispaces.com/message/view/Location+entity/30888227
http://bettergedcom.wikispaces.com/message/view/Location+entity/30668879?o=40
Way forward?:
The info should preferably be recorder by an event referencing the involved placeS, also giving date and source but possibly no persons.
Dependencies:

Approval status:

Proposer:
22 Feb gthorud
Changes:

Discussion:


Id:
Data-Place05
Title:
Place identifiers
Description:
BetterGEDCOM shall be able to record identifiers, possibly multipart/hierarchical, for a place used for example in land records, map databases, property owner databases, statistics. The identifier type should accompany each identifier part, i.e. a sequence of type/value pairs.
Importance:

Why?:
The identifier can be used to locate and lookup in various paper sources and , and is also in itself a historic fact. An identifier is often unique where a name is not. Several identifiers may have been used over time.
Source:
http://bettergedcom.wikispaces.com/message/view/Location+entity/30668879?o=40
Way forward?:

Dependencies:

Approval status:

Proposer:
22 Feb gthorud
Changes:

Discussion:


Id:
Data-Place06
Title
Location to include address
Description:
The location in BetterGEDCOM should be able to specify an individual address.
Importance:
Very desirable
Why?
Current GEDCOM5.5 defines a PLACE as a "jurisdictional name to identify the place or location of an event". The address of an individual building is generally not regarded as being a PLACE under this definition. Since many events are known to occur at precise addresses, the address details are kept separately in the ADDRESS_STRUCTURE. This structure, however, repeats items like city, state, country.
To avoid duplication and the consequent danger of values not being correctly duplicated, the successor to PLACE should include the ability to specify an individual address.
Source:
Various discussion pages.
Way forward?:
  • Create this in the Data Model.
  • To be decided - whether a location's details in BetterGEDCOM should include Postal Code or Phone Number, which are also part of ADDRESS_STRUCTURE of GEDCOM 5.5, but appear to have dubious relevance to historical events or characteristics.
  • Note this does not mean that the ADDRESS_STRUCTURE of GEDCOM 5.5 has no future in BetterGEDCOM, since the address of a repository, for instance, does not need to have the same structure as a location for historic events or characteristics.
Dependencies:

Approval status:

Proposer
AdrianB38
Changes:

Discussion:
2011 Mar 03 - Created. Split off from Data-Char02 the requirement that location goes down to address to make it more obvious

"Ship"


Id:
Data-Ship01 (was Data11)
Title
Data about miscellaneous entities
Description:
BetterGEDCOM could support the recording of historic data about miscellaneous entities or artefacts such as ships, locomotive types, etc.
Importance:
Desirable
Why?:
Individuals, organisations, etc., are usually involved with many physical artefacts, yet no mechanism currently exists in GEDCOM to record any of the artefact's details in a structured manner, nor to link these things to people, etc.
Examples could include a summary of the history of a ship used for several cross-Atlantic journeys by different people. These details could be entered in one place, not against each person.
Note this requirement does not say anything about how that data will be represented on the file, specifically it does not say anything about how evidence and conclusions are represented.
Source:
Shortcomings of GEDCOM
Way forward?:
Create this in the Data Model.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:
Discussion of Data-Ship01 Data about miscellaneous entities

DNA


Id:
DNA01
Title:
Results from DNA tests
Description:
BetterGEDCOM should be able to record results of DNA tests.
Importance:

Why?:
Many genealogy programs allow recording of such data.
Source:

Way forward?:

Dependencies:

Approval status:

Proposer:
19 March 2011 GeneJ
Changes:

Discussion:
To do - add sources, repositories, etc.

Evidence


Id:
Evidence01
Title
Evidence & Conclusion Model
Description:
BetterGEDCOM could handle evidence and not just conclusions
Importance:
Desirable
Why?:
Current GEDCOM is structured so that data about an individual or family is always the "latest working hypothesis". It is therefore difficult to identify the actual evidence, particularly when the "latest working hypothesis" is a composite of various bits of evidence.
Also, in the event of discovery of an error, it can be difficult to (a) identify subsequent issues and (b) revert to an acceptable set of "working hypothesis". This is because adding new or revised conclusions to current GEDCOM is generally a destructive process resulting in the replacement or deleting of superseded conclusions.
To overcome this, it appears as a minimum to be necessary to record evidence and conclusions separately. This allows adding new or revised conclusions to be a non-destructive process.
See Evidence and Conclusion Process
Note this requirement is effectively the same as (possibly part) adopting the "Evidence and Conclusion Model", which is linked to, but not the same as, the "Evidence and Conclusion Process". See Glossary
Source:
"I Want My Genealogy Software And BetterGEDCOM To Do This" on Shortcomings of GEDCOM
Way forward?:
  • Establish a first cut at a comprehensive set of genealogical processes that cover both Research Administration and recording of both Evidence & Conclusions.
  • Define which parts of the processes are in the scope of Research Administration and which in that of Evidence & Conclusions
  • Consider how the model and processes support "roll-back" to an acceptable state after discovery of an error.
  • Consider feasibility and therefore the priorities of documenting (a) requirements and (b) the data model relating to Research Administration and Evidence & Conclusions and establish what is do-able in relation to timescales
Dependencies:

Approval status:

Proposer:

Changes:
2011 Feb 22 17:45 CET - attempt to clarify this is about the "Evidence and Conclusion Model", which is linked to, but not the same as, the "Evidence and Conclusion Process".
2011 April 11 17:00 CET - adjust "Way Forward" in light of discussions. Add distinction btw destructive process for adding new stuff in current GEDCOM, conclusion-only, and non-destructive process in Evidence & Conclusion
Discussion:
Evidence01 and Evidence 01 Please use the latter one. See also Defining E&C for BetterGEDCOM

Id:
Evidence02
Title:
Proof Argument and/or Process
Description:
BetterGEDCOM should support users need to record and share proof arguments supporting and/or supported by the evidence and conclusions therein recorded or shared.
Importance:
Very Desirable
Why?:
Supports faithful recording of research status and results.
Source:
http://www.bcgcertification.org/skillbuilders/skbld091.html
Way forward?:

Dependencies:

Approval status:

Proposer:
GeneJ
Changes:
2011 Feb 21 - created
2011 FEb 22 - Fixed URL for link to discussion (GJ)
2011 Feb 22 - Fixed keyboard witch's duplication in the description field above.
Discussion:
http://bettergedcom.wikispaces.com/message/view/Better+GEDCOM+Requirements+Catalog/34594682

International


Id:
International01
Title
Support for international character sets
Description:
BetterGEDCOM must be able to handle text expressed in most of the world's writing systems
Importance:
Mandatory
Why?:
Genealogy is not confined to countries with the American-English 26 letter alphabet
Source:

Way forward?:
Unicode UTF-8
Dependencies:

Approval status:
See International02
Proposer:

Changes:

Discussion:


Id:
International02
Title
Unicode
Description:
BetterGEDCOM must use Unicode and only Unicode to represent text
Importance:
Mandatory
Why?:
Unicode is the universally accepted solution for handling the multitude of modern, historical and ancient character sets used by all human cultures. UTF-8 is the most common byte encoding of Unicode and supported by all modern software development environments
Source:

Way forward?:
Unicode UTF-8
Dependencies:
International01
Approval status:
Developers Meeting 17 Jan 2011 approved "Use Unicode (only) for the consistent encoding, representation and handling of text expressed in most of the world's writing systems"
This is International01 plus International02 expressed in one sentence.
Developers Meeting 31 Jan 2011 approved "Unicode character set in UTF-8 encoding, and optionally support other encoding schemes of Unicode "
Proposer:

Changes:

Discussion:


Id:
International03
Title
Support for the requirements of many cultures, countries, time periods and belief systems
Description:
BetterGEDCOM must support recording of information about real life in an open-ended set of cultures, countries, time periods and belief systems. It must not be biased towards any one of these.
Importance:
Mandatory
Why?:
BG must support (directly or indirectly) different calendars, events from different religions and cultures, etc.
Source:
Discussion topic "Goal 5 (Internationalization)"
Way forward?:
The BetterGEDCOM project cannot possibly understand all possible calendars, religions, etc. Therefore while we may be able to directly support the best known of them, we will have to cater for the rest indirectly by allowing software companies or users to extend BG to cope with them.
Dependencies:
This depends on Syntax04 and Syntax05 re extensibility
Approval status:
The 31st Jan 2011 Developers Meeting passed this:
"Goal 5 BetterGEDCOM supports recording of information about real life in an open-ended set of cultures, countries, time periods and belief systems. It should not be biased towards any one of these."
Proposer:

Changes:

Discussion:


Multimedia


Id:
Multimedia01 (was Syntax02)
Title
Multimedia container
Description:
BetterGEDCOM must use a container specification to hold separate supporting files such as multimedia accompanying the genealogical data.With Multimedia we mean digital resources that may represent photos, scanned images, video, sound, documents, web pages, diagrams, maps, (database?) etc.
Importance:
Mandatory
Why?:
1. Embedded files within the genealogical data are generally viewed as a bad idea - they would have been rejected by GEDCOM in the next version after 5.5.
2. A weakness of current GEDCOM is that there is no standard method of transferring linked multimedia with the GEDCOM file, nor of maintaining the links to them after transfer.
Source:
Original Goal 2 bullet 3 Multimedia inclusion and referencing issues Importing Data
Way forward?:
Zip is probably in there somewhere
Dependencies:

Approval status:
Developers Meeting 17 Jan 2011 approved this
Proposal:

Changes:

Discussion:


Id:
Multimedia02
Title:
Information about multimedia objects
Description:
BetterGEDCOM must support the recording of information describing each multimedia object. Possible types of information include object encoding type (MIME?), origin/creator/author/publisher, (file) size, title, description, caption, creation time, identification of e.g. persons shown, type of “objects” shown in media (e.g. persons, landscapes, houses), copyright, informal/short identifier/name, setting (type of circumstances/event when created), user defined attributes and attribute types/flags, quality classification, creating program name&version, tags (incl. geo tags), research notes, duration – and more – or less.
Importance:
Mandatory
Why?:
This information is needed to select, organise and manipulate multimedia objects in genealogy programs and to provide information about the object when included in e.g. reports.
Source:
Multimedia inclusion and referencing issues
Way forward?:
The various types of information could be split into new requirements. The information should be held in an entity and top level record, possibly by supporting structures.
Dependencies:

Approval status:

Proposer:
March 4 2011 gthorud
Changes:

Discussion:


Id:
Multimedia03
Title:
References to Multimedia
Description:
BetterCEDCOM should allow information recorded about persons, families, groups, places, sources, events etc. to reference multimedia objects. The reference could contain information about the media's relevance in the referencing context. It would also be useful if classify the media in the referring context, eg. if the media is a preferred media or one or more classifications that could eg. be used to affect it's location in reports.
Importance:

Why?:
Information about the relevance in the referencing context could say for example "This is a photo of Peter together with his classmates in 1955". It could overrule similar information recorded about the photo for general use. The classification could allow some media to be printed above the text about a person and other media below, or in a scrapbook etc. but could also be used for other purposes - this is useful when transferred between one user's programs.
Source:
Multimedia inclusion and referencing issues
Way forward?:
The reference should most likely be to a multimedia entity/record containing information about the multimedia, see Multimedia02. It must be possible to reference multimedia in notes and excerpts.
Dependencies:

Approval status:

Proposer:
March 6 2011 gthorud.
Changes:

Discussion:


Id:
Multimedia04
Title:
Grouping of multimedia in a container
Description:
A container (see Multimedia01) shall be able to group the media in a tree structure possibly reflecting the directory structure on the exporting program's computer.
Importance:

Why?:
The structure is most likely useful to the receiver of the media.
Source:

Way forward?:

Dependencies:

Approval status:

Proposer:
6 March 2011 gthorud
Changes:

Discussion:


Source


Id:
Source01
Title:
Information, Source and Evidence Type
Description:
BetterGEDCOM should record separately whether a Source is, for a given event or characteristic:
  • Primary or Secondary Information (latter includes tertiary)
  • Original or derivative source (e.g. paper or copy/digital image; document or compiled summary; document or transcribed version)
  • Direct, indirect or negative evidence
Importance:
Very Desirable
Why?:
GEDCOM only has QUAY (quality) for this; QUAY is not a substitute for the specifics, as herein described.
Source:
Discussion page on Shortcomings of GEDCOM
Way forward?:
Include data items
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:
11 Mar 2011: Added Title (GJ)
Discussion:
Source01

Id:
Source02
Title
Certainty Assessment (QUAY)
Description:
BetterGEDCOM should record the qualitative degree of likelihood that a source is true for a given event or characteristic.
Importance:
Very Desirable
Why?:
GEDCOM has QUAY (quality) for this but the GEDCOM Standard is not clear what QUAY value should be assigned to a Primary source of Questionable accuracy
Source:
Discussion page on Shortcomings of GEDCOM
Way forward?:
Include data items
Dependencies:

Approval status:

Proposer:

Changes:
12 Mar 2011: Added Title (GJ)
Discussion:
Source 02-Certainty Assessment (QUAY)

Id:
Source03
Title
Sourcing of child / parent relationships
Description:
BetterGEDCOM must provide the ability to record the sources and citations to justify why a child is believed to be in a particular relationship with its (birth or whatever) parents
Importance:
Mandatory
Why?:
GEDCOM has no ability to do this. The current citations and sources are either for a family as a whole or for individual birth (or whatever) events that only mention the child.
Source:
GEDCOM Messes This Up on Shortcomings of GEDCOM
Way forward?:
Include data items
Note the way forward may vary depending on the solutions chosen for Data-Fam01 and Data-Ind02 "Biological relations independent of family"
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:

Discussion:


Id:
Source04
Title:
Length of citations
Description:
There must be no limit in BetterGEDCOM on the length of a citation, whether that citation applies to a source (often expressed as part of a bibliography entry) or an event, attribute, person, relationship, etc, etc (often expressed as a footnote or end-note).
Importance:
Mandatory
Why?:
The majority of citations will be short. However, some users may wish to record a Proof Argument inside the citation. Any limit on the length of such a citation would be arbitrary and could be exceeded, so should not be permitted. See also requirement Syntax10 "No restrictions on item length or value", which is a generalised version of this requirement.
Source:
See discussion of "The Missing Link - a new entity type or a new type of source?" and specifically the discussion of the options for citations in there.
Way forward?:
While many users would never wish to use lengthy citations, there seems no good reason to forbid their use.
Dependencies:

Approval status:

Proposer:
AdrianB38
Changes:
Created 2001 April 17 15:50 CET
Discussion:
Discussion

Id:
Source05
Title:
Citations in notes
Description:
BetterGEDCOM should allow citations to be entered anywhere in in the text of notes.
Importance:

Why?:
For the same reason as footnotes are used in many texts to cite sources.
Source:

Way forward?:
One way to do it is to have separate records for citations.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Support for the standard


Id:
Support01
Title:
Support for multiple birth, death characteristics
Description:
Programs claiming support for BetterGEDCOM must support multiple birth, death characteristics for a person. Support means that the program must be able display the facts related to several occurencies of the characteristic, and allow recording of several such by the user.
Importance:

Why?:
See Char03
Source:

Way forward?:
The same requirement should be considered for other basic characteristics.
Dependencies:

Approval status:

Proposer:
6 March 2011 gthorud
Changes:

Discussion:


Syntax


Id:
Syntax01
Title
Underlying syntax
Description:
BetterGEDCOM's underlying syntax must be an existing, non-proprietary syntax
Importance:
Mandatory
Why?:
We do not want to reinvent the wheel
Source:
Original Goal 2 bullet 1
Way forward?:
Options include XML, JSON, GEDCOM, Google Protocol Buffers or any combination thereof.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:

Syntax02 has been moved to Multimedia01

Id:
Syntax03
Title
Content scope
Description:
The BetterGEDCOM file format must define data relating to the study of genealogy / family history.
Importance:
Mandatory
Why?:
Raison d'etre of the format - statement of the obvious. The coverage of BetterGEDCOM must be wider than existing formats in order to provide a reason for its adoption.
Source:
Original Goal 3
Way forward?:
Define the data in a Data Model etc.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Syntax04
Title
Extensibility by software companies
Description:
The BetterGEDCOM file format must be capable of extension by software companies. Extensions must be kept permanently separate from any later definitions in BetterGEDCOM format.
Importance:
Mandatory
Why?:
1. GEDCOM can be extended so to remove the facility would be a step backwards.
2. Many GEDCOM files exist with extensions.
Source:
Original Goal 3
Way forward?:
Note that extensions in GEDCOM are identified by an underscore, which applies only to extensions. Any new GEDCOM tags will not have the underscore so will not be confused with extensions. An equivalent mechanism needs to be used for BetterGEDCOM.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Syntax05
Title
User Extensibility of events and characteristics
Description:
The list of events, properties, characteristics, etc, of individuals, etc, in the BetterGEDCOM file format must be capable of extension by users. Extensions must be kept permanently separate from any later definitions in BetterGEDCOM format.
Importance:
Mandatory
Why?:
1. GEDCOM can be extended so to remove the facility would be a step backwards.
2. Many GEDCOM files exist with user-defined events.
Source:
Original Goal 3
Way forward?:
Note that user defined events and attributes in GEDCOM are identified by an underscore, which applies only to them. Any new GEDCOM tags will not have the underscore so will not be confused with user defined events, etc. An equivalent mechanism needs to be used for BetterGEDCOM.
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
Syntax06
Title:
Define one way of doing a thing
Description:
BetterGEDCOM should define just one way of doing one thing.
Importance:
Very Desirable
Why?:
More than one way may cause ambiguity and extra programming for programmers
Source:
Original Goal 7
Way forward?:
It may be sensible to agree specific exclusions to this requirement, e.g. for in-line notes and separate note records, where the extra programming work is trivial and does not create ambiguity.
Dependencies:
Issue 1: It is not always possible to agree that two things are, in reality, the same thing. For instance, whether or not in-line notes and separate note-records are, in practical terms, the same thing, has been the topic of debate.
Issue 2: If two separate methods in GEDCOM type formats are merged into one, then it will not be possible to round-trip data from a GEDCOM type format to BG and back again coming up with the same data.
Approval status:

Proposer:

Changes:
2011 Feb 22 - Updated template format to add rows for title, proposer and discussion; added title, added link to discussion (also added discussion topic) (GJ)
Discussion:
Discussion at Syntax06 - Define one way of doing a thing
Former discussion at Single way (current goal 7) [Please do not add comments to the former discussion]

Id:
Syntax07
Title
URIs (URLs) for external information
Description:
BetterGEDCOM format files must be able to contain URI (URL) addresses for external information
Importance:
Mandatory
Why?:
It is necessary for users to record to sources, etc on the Internet. Part of that data will be the URL.
Source:
Tom Wetmore's Goal and Requirements
Way forward?:

Dependencies:

Approval status:

Proposal:

Changes:

Discussion:
Syntax07 URIs (URLs) for external information

Id:
Syntax08
Title
Feature inheritance from previous event etc. types
Description:
It should be possible for user-defined events, properties, characteristics, etc, of individuals, etc, to inherit features from previously defined events, properties, characteristics, etc.
Importance:
Very desirable
Why?:
Events, properties, characteristics, etc. known to the application software may have logic built into the application to recognise them and process the data from them in certain ways.
For instance, the "Marriage" event might be used by the application to propose a family to the user.
User-defined events, properties, characteristics, etc., will not normally be recognised by the application so cannot have logic built into the application to recognise them. However, if the user-defined event, property, characteristic, etc., could inherit features belonging to one known to the application, then it would inherit that built-in logic.
For instance, "Marriage - civil" might be a user-defined event that inherits details from "Marriage" and so would also be used by the application to propose a family to the user.
Source:
"I Want My Genealogy Software And BetterGEDCOM To Do This" on Shortcomings of GEDCOM
Way forward?:
If events etc are given a type and sub-type, then it would be possible for the user to create a user-defined subtype of an application defined type, and thus inherit the processing done for that type.
For instance, an event "Marriage - civil" might have a type of "Marriage" and a subtype of "civil", thus automatically doing all processing created for the event-type of "Marriage"
Dependencies:
Syntax05
We depend on the application developers to create any processing that recognises events.
Approval status:

Proposer:

Changes:

Discussion:


Id:
Syntax09
Title:
Define Event vs. Attribute
Description:
Assuming that the BetterGEDCOM project distinguishes events from properties / facts / attributes / characteristics, then BetterGEDCOM must define and publish a clear definition of the difference between the two concepts that does not rely on a list of each. In particular, the definition must be clear enough for competent software suppliers and users to understand whether a new item is an event or a property / fact / attribute / characteristic.
Importance:
Mandatory
Why?:
There is no clear definition in the GEDCOM 5.5 specification of the difference between the two, only a list of events and a list of attributes. This means that a software supplier or user does not always know whether to create an event or attribute. As a result, the same concept can appear as both, resulting in difficulty of exchange of information.
Source:
Discussion on Custom GEDCOM tags Discussion: Eliminate Facts Discussion: Events, Properties, Characteristics and Facts
Way forward?:
If and when it becomes necessary to distinguish the two concepts, then the Data Model should be updated to record the definition.
Dependencies:

Approval status:

Proposer:
AdrianB38 2011 Feb 25 22:35
Changes:

Discussion:
Syntax09 Define Event vs. Attribute

Id:
Syntax10
Title
No restrictions on item length or value
Description:
Data items should have no length restriction in BetterGEDCOM, except as deemed necessary during design.
Data items should have no restrictions on value in BetterGEDCOM, except as deemed necessary during design.
Importance:
Very Desirable
Why?:

Source:
Original Goal 2 bullet 5
Also Tom Wetmore's Goal and Requirements
Way forward?:
Compare TextHandling02 "No restrictions on line length", which refers to the overall length of a line.
Dependencies:

Approval status:
Subject of Survey Monkey - relevance? result?
Proposer:

Changes:

Discussion:


Id:
Syntax11
Title:
Unique Identifiers
Description:
BetterGEDCOM should assign unique identifiers (UIDs) to records, BG-files and "data sets". Data sets (the term could be changed) is a collection of data that may hold infomation about e.g. "The Olsen family", "Persons in parish X" or "Our genealogy project" that will be updated over time, and be exported in a BG file at (i)regular intervals. The data set will have a unique identifier, and so will each BGfile containing a snapshot of the data set.
Importance:

Why?:
The various purposes that UIDs could serve must be more pricisely defined. Also the procedures for their assignement and their use.
Source:
This has been discussed in Data08 and UUIDs - No thanks and Please lets use UUIDS ... and several other discussions (search for UUID).
Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Task01 has been moved to Admin02.

Test


Id:
TestSuite01
Title:
Suite of test data
Description:
BetterGEDCOM should provide a test suite of data that will
  • allow software suppliers to assess compliance of their software
  • help them to diagnose issues
  • assist them to resolve issues.
Importance:
Very Desirable
Why?:
If we can't do it, others will - and probably get it wrong. This will also meet developers halfway.
Source:
Original Goal 4 (I need to check up subsequent discussions on this)
Way forward?:

Dependencies:

Approval status:

Proposer:

Changes:

Discussion:
Test Data Format

Text Handling


Id:
TextHandling01
Title
Formatting mark-up for text
Description:
BetterGEDCOM should define a method of marking up text with formatting information. It should be available in all appropriate fields
Importance:
Very Desirable
Why?:
This is a consistent request - the ability to format notes with italics, bold, etc.
Source:
Original Goal 2 bullet 4
Way forward?:
Allowing selected HTML or HTML-style tags?
Dependencies:

Approval status:

Proposer:

Changes:

Discussion:


Id:
TextHandling02
Title:
No restriction on line length
Description:
Lines should have no length restriction in BetterGEDCOM, except as deemed necessary during design.
Importance:
Very Desirable
Why?:

Source:
Original Goal 2 bullet 5
Also Tom Wetmore's Goal and Requirements
Way forward?:
Compare Syntax10 (was TextHandling03) "No restrictions on item length", which refers to the length of an individual item.
Dependencies:

Approval status:
Subject of Survey Monkey - result?
Proposer:

Changes:

Discussion:


Id:
TextHandling03
Title:
Footnotes/endnotes in notes
Description:
BetterGEDCOM should allow references to footnotes or endnotes that contains just text (not a source citation).
Importance:
Very Desirable
Why?:
Such footnotes/endnotes could contain comments or other text that may not be considered important enough to be entered in the note itself. See also Citations in Notes - Source05.
Source:

Way forward?:
The text could surrounded by special codes in the note text, or be contained in a separate structure.
Dependencies:

Approval status:

Proposer:
17 April 2011 gthorud
Changes:

Discussion:


Id:
TextHandling04
Title:
Semantic Mark-up in Text
Description:
TextHandling01 describes 'presentational mark-up' in text. This item supplements that with 'semantic markup' in text. This allows references to other entities (e.g. Persons, Places, Events, etc) to be embedded in text. Reference should be made to STEMMA's research document on Structured Narrative which discusses the need for both types of mark-up, plus citation references, and general reference notes.
Importance:
Very Desirable
Why?:
Semantic mark-up provides machine-readable references that can be used for automatic linking, and generation of hyperlinks for the UI
Source:
Structured Narrative
Way forward?:
Need to widen the scope of "Notes" to include general narrative, and hence "Structured Narrative". This is a neglected area that STEMMA is pushing alone. It is essential for the representation of family history data as opposed to mere genealogical data
Dependencies:

Approval status:

Proposer:
23 May 2012 ACProctor
Changes:

Discussion:


Timelines


Id:
Timeline01
Title:
Timelines
Description:
This is just a placeholder so far.
Importance:

Why?:

Source:

Way forward?:

Dependencies:

Approval status:

Proposer:
20 March 2011 gthorud
Changes:

Discussion:


Snapshot of the page:
Better GEDCOM Requirements Catalog snapshot 2may2011.pdf