<div dir="ltr">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.<div><br></div><div>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</div><div><br></div><div>- A (multi?)map of key:value pairs</div><div>- Where keys are URIs (see <a href="https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#enumerated-value">https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#enumerated-value</a> for why he likes URIs), with a non-exhaustive set of standard keys</div><div>- With suggested (but probably not enforced) guidelines such as the following examples (illustrative of structure, not content):</div><div>    - if the "type" key has value "book", expect keys "author", "title", and "publisher"</div><div>    - the value associated with the "publication date" key should be a in EDTF 1.0 format</div><div>- 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.)</div><div><br></div><div>I thus put the following questions to this group:</div><div><br></div><div>1. Do we want to shoot for having something done in time for GEDCOM-X version 1.0 to include it?</div><div><br></div><div>2. Are there goals the outlined map model does not permit?  If so, can correcting them keep the model simple?</div><div><br></div><div>3. Is there a different model we should suggest?</div><div><br></div><div><br></div></div>