[Sources-Citations] Opportunity from FamilySearch; possible path to meeting it

Luther Tychonievich ltychonievich at fhiso.org
Mon Jun 15 11:20:29 CDT 2015


Last week I visited with Ryan Heaton of FamilySearch, who is the lead
developer of the GEDCOM-X specification currently used for communication
between FamilySearch and all of its partners (including, as I understand
it, Ancestry, MyHeritage, and FindMyPast).  Amongst other things, he told
me that he anticipated that the GEDCOM-X SourceDetail record would be
updated starting perhaps a year from now, and that if FHISO had an
acceptable standard he would like to say simply "GEDCOM-X used FHISO
standard ___ for its SourceDetial element".  He suggested that once such
was in place they would roll the GEDCOM-X version 1.0, and that if FHISO
did not have one he could use by then they would probably design their own.

To explore what he was thinking in more detail, I discussed several
possible bibliographic metadata models with him.  He seemed interested in
something simple and extensible.  One idea that seemed to interest him was

- A (multi?)map of key:value pairs
- Where keys are URIs (see
https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#enumerated-value
for why he likes URIs), with a non-exhaustive set of standard keys
- With suggested (but probably not enforced) guidelines such as the
following examples (illustrative of structure, not content):
    - if the "type" key has value "book", expect keys "author", "title",
and "publisher"
    - the value associated with the "publication date" key should be a in
EDTF 1.0 format
- Where one of the valid types a value could have would be a reference to
another map like this (for, e.g., "part of" keys to link chapters to their
owning book, "in repository" keys, etc.)

I thus put the following questions to this group:

1. Do we want to shoot for having something done in time for GEDCOM-X
version 1.0 to include it?

2. Are there goals the outlined map model does not permit?  If so, can
correcting them keep the model simple?

3. Is there a different model we should suggest?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fhiso.org/pipermail/sources-citations_fhiso.org/attachments/20150615/06986cce/attachment.html>


More information about the Sources-Citations mailing list