[TSC-public] Filing Sources
packrat74 at gmail.com
Mon Nov 3 12:37:15 CST 2014
So source records can be arranged in hierarchical trees, but they don't
> have to be. Totally up to you and up to data providers. Do it your way, and
> be comfortable in the rightness of your being. If you can't stand the idea
> of hierarchical sources, don't use them.
So what happens then if I exchange a file with someone where I've done
things one way, and my correspondent has done them a different way? Don't
we end up with the same chaos we have now, where programs puke on each
other's GEDCOM files because of non-standard extensions?
packrat74 at gmail.com
On Mon, Nov 3, 2014 at 10:21 AM, Thomas Wetmore <ttw4 at verizon.net> wrote:
> At the risk of sounding like a broken record once again, the whole source
> thing can be modeled very easily. It takes care of all war stories and
> examples and approaches that are being bandied about. I have been
> explaining this approach for more than twenty years. It is so easy, basic
> and obvious, it should make you fall off your couch.
> 1. A source record can represent a whole Source, or a part of a Source, or
> a part of a part of a Source, and so on and so on, depending upon the
> predilections of either software or website or user or data provider or
> published convention or archive policy and so on and so on.
> ["Source" in upper-case means a real source in the real world, whereas
> "source record" means a representation of that Source or a part of that
> Source in computerese.]
> 2. When a source record represents a part of a Source, it should have a
> source reference to a containing source record that represents the full (or
> next higher level part of the) Source. When a source record represents a
> full Source is does not have a source reference to anything higher. So
> source records can be arranged in hierarchical trees, but they don't have
> to be. Totally up to you and up to data providers. Do it your way, and be
> comfortable in the rightness of your being. If you can't stand the idea of
> hierarchical sources, don't use them.
> 3. Any other record in a database that holds or refers to information
> extracted from a Source (my favorite example is the persona record, but it
> doesn't have to be), uses a source reference to the source record that best
> represents its Source in the real world.
> 4. A source record has a type (e.g., book, journal, journal-number,
> journal-article, website, webpage, census, census-page, and up the kazoo).
> 5. Each source record type has lots of possible "metadata" (which are what
> are called properties or assertions in other record types), and our model
> must handle all the possibilities, probably with some extension
> 6. This can be handled with TRIVIAL extensions to GEDCOM. a) Add more
> properties (level 1 lines) to the "0 @X@ SOUR" record, including a "1
> TYPE" line; and b) add a "1 SOUR @X@" line to the "0 @X@ SOUR" record to
> allow the hierarchy.
> 7. Citations can be generated by following up the source chain (which only
> has one link when the source record represents the full Source), extracting
> properties ("metadata") along the way, and using that metadata to construct
> the citation. One pattern can be followed for footnotes, another for
> bibliographic entries and another for end notes. Use another set of
> templates if you want another style.
> This would take care of every example discussed lately. But not only every
> example, but every way anyone would want to handle every example. Do it
> your way. If you want one source per census, you got it. If you want one
> source per page per census, you got it. If you want to treat a page as a
> source within a census as a higher level source, you got it.
> Tom Wetmore
> TSC-public mailing list
> TSC-public at fhiso.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TSC-public