Louis Kessler has posted an interesting blog about the fact that a copy of the original V3 Gedcom standard. The main thrust of the post is about the fact that SOURCE was an official tag that was removed in later versions (unfortunately).
http://www.beholdgenealogy.com/blog/?p=1653
What a pity this wasn't retained in later versions of Gedcom.
* Gedcom V3 and source records
-
tatewise
- Megastar
- Posts: 27088
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Gedcom V3 and source records
Do you really mean the tag?
There is no significant difference between SOUR and SOURCE as a tag.
In fact the specification says the TAG is SOUR and its TAG NAME is SOURCE but then uses a mixture in the example code!
Or do you mean the predefined Source Record structures?
You are joking? That would be horrendous!
It only gives examples of about three Source Record structures that are inconsistent and incomplete.
There is nothing that uniquely identifies the syntax of the different structures.
Every time a new type of Source Record was required then the GEDCOM specification would need updating, along with all the implemented software!
There is no significant difference between SOUR and SOURCE as a tag.
In fact the specification says the TAG is SOUR and its TAG NAME is SOURCE but then uses a mixture in the example code!
Or do you mean the predefined Source Record structures?
You are joking? That would be horrendous!
It only gives examples of about three Source Record structures that are inconsistent and incomplete.
There is nothing that uniquely identifies the syntax of the different structures.
Every time a new type of Source Record was required then the GEDCOM specification would need updating, along with all the implemented software!
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
-
Valkrider
- Megastar
- Posts: 1534
- Joined: 04 Jun 2012 19:03
- Family Historian: V7
- Location: Lincolnshire
- Contact:
Re: Gedcom V3 and source records
Mike
I meant the Source record structures.
I don't agree that it would be horrendous. If it had stayed in the spec I expect it would have evolved into something usable.
We will have to agree to disagree.
I meant the Source record structures.
I don't agree that it would be horrendous. If it had stayed in the spec I expect it would have evolved into something usable.
We will have to agree to disagree.
-
AdrianBruce
- Megastar
- Posts: 1962
- Joined: 09 Aug 2003 21:02
- Family Historian: V7
- Location: South Cheshire
- Contact:
Re: Gedcom V3 and source records
I think that the Source Record that Louis refers to was meant to embody all the information from a "physical" source. (The terminology isn't helping here). Louis' ideal, again so far as I remember, is to extract the facts, with no interpretation.
I have to agree with Mike that every time a new type of source was discovered, you would potentially need to create a new type of "extracted fact record" (i.e. the Source Record under discussion). So, how many different types of personnel-related document did the British Army produce? How many did the London & North Western Railway? How many did.... You get my picture. Now, I suspect that the immediate response to that is to say that you would only extract the information that relates to what we would be storing in a GEDCOM file. Aside from the fact that this still comes in a massive number of combinations, my response is that selecting stuff immediately invalidates the no interpretation idea. And it's pretty certain, if selection were made, that rare pieces of research would still need information not captured in that selection. For instance, in trying to interpret an oddity in the British Army data of one of Jan Murphy's relatives, I had to bring in the Army reference number of the form in question - more specifically, the print date of that precise blank form.
Of course, these odd items could be encoded in user-defined information items, similar to the way that user-defined events are now. But then exchange of "extracted fact records" wouldn't work because so much would be locked inside user-defined information items. And the more of those you have, the more I think you just end up with a text version of the record with none of the readability. If you are going down that route, then a much more sensible idea is to start with a text version of the source and mark up the text in situ. At least you keep the readability, even if you still have thousands(?) of types of user defined information tags.
I have to agree with Mike that every time a new type of source was discovered, you would potentially need to create a new type of "extracted fact record" (i.e. the Source Record under discussion). So, how many different types of personnel-related document did the British Army produce? How many did the London & North Western Railway? How many did.... You get my picture. Now, I suspect that the immediate response to that is to say that you would only extract the information that relates to what we would be storing in a GEDCOM file. Aside from the fact that this still comes in a massive number of combinations, my response is that selecting stuff immediately invalidates the no interpretation idea. And it's pretty certain, if selection were made, that rare pieces of research would still need information not captured in that selection. For instance, in trying to interpret an oddity in the British Army data of one of Jan Murphy's relatives, I had to bring in the Army reference number of the form in question - more specifically, the print date of that precise blank form.
Of course, these odd items could be encoded in user-defined information items, similar to the way that user-defined events are now. But then exchange of "extracted fact records" wouldn't work because so much would be locked inside user-defined information items. And the more of those you have, the more I think you just end up with a text version of the record with none of the readability. If you are going down that route, then a much more sensible idea is to start with a text version of the source and mark up the text in situ. At least you keep the readability, even if you still have thousands(?) of types of user defined information tags.
Adrian