Tom Wetmore wrote: > Note one very interesting thing about the five answers so far. No one > says they use their genealogical application to store their evidence. > Is this a failing of genelaogical software in general, or is handling the > evidence and handling the persons such two fundamentally different > things that we need two completely different programs for handling them? Gramps has a feature which I do sometimes use for handling evidence files but AFAIK it just points to a file it's told about. I don't think it makes a copy in the database. > My answer is that genealogical programs should be able to handle evidence, > but no one has figured out how to do it yet. Figured but not done. If you look back to the thread "Data import from the new Familysearch site" I have an XML example where the "evidence" is copy & pasted from the web-page: <SourceObjects> <SourceObject> <Content><![CDATA[Name: Mary Collier Gender: Female Baptism/Christening Date: 27 Dec 1760 Baptism/Christening Place: ALMONDBURY,YORK,ENGLAND Birth Date: Birthplace: Death Date: Name Note: Race: Father's Name: George Collier Father's Birthplace: Father's Age: Mother's Name: Mother's Birthplace: Mother's Age: Indexing Project (Batch) Number: P01712-1 System Origin: England-ODM Source Film Number: 230649 Reference Number:]]> </Content> <ObjectID>1C42DFF7-299E-44C8-91FB-F5A805A78AAE</ObjectID> <MimeType>text/plain</MimeType> </SourceObject> </SourceObjects> Several points: 1. The object itself is wrapped up with a mime type ( http://en.wikipedia.org/wiki/MIME ). This tells the program how to display it, assuming the program can handle that type itself, or pass it on to whatever utility the OS has associated with that type. 2. As a consequence of the above the system is future-proofed. If some new format is introduced then provided that a mime type is provided then it can be handled. 3. A collection of objects can be wrapped in a binder. This makes provision for multi-page scans, scan and transcription, transcript and translation or whatever. 4. This is intended to be a publication medium. 5. A UUID is provided. This means that if I send a copy of this object to you and someone else who has also received a copy sends a further copy to you your S/W will be able to identify and discard the duplicate. 6. A consequence of 4 & 5 is that once the object is published it should not be amended. If someone wants to make some amendment, such as provide a transcript to a scan, a translation to a transcript, etc. it should be done as a separate object with a pointer to the original. 7. There are a few changes I'd make. Firstly the binder object should have the UUID instead of the inner to discourage braking up the object. Secondly there should be text as a human-readable title/description/handle to the inner object. Thirdly there needs to be a content encoding element as well as the mime type although this could be optional. 8. The whole shebang, binder and all, would best be enclosed in a further wrapper with its own UUID, a UUID pointing further up the source tree and other information such as text to be used as a citation. In the case of an amendment record the source UUID would be that of the amended record. Note that this is an external representation. S/W realisations would be free to store the data in an RDBMS or whatever. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk