Ian Goddard wrote: > There are several distinct issues here: > > 1. GEDCOM 6 vs earlier. > GEDCOM 6 is an XML version. There is a document describing it but I'm > not sure of its status - is it still work in progress? In any event it > doesn't seem to be used. It follows the same data model as the current > 5.5 so any references to the data model apply to both. Where we > consider "GEDCOM" vs XML in terms of parsing files, etc. them "GEDCOM" > is likely to mean 5.5 or earlier and XML would include GEDCOM 6. But, > to repeat myself, 6 doesn't seem to be in use. > I had the opportunity to speak to someone on the Family History Library software team that was responsible for Gedcom back at Salt Lake City in 2004. The impression he gave was there would be no effort to finalize Gedcom 6 as Gedcom 5.5 was effectively fit for its purpose - that purpose being the submission of information to the LDS. I think it likely that the LDS/FHL/FamilySearch believe that the future of family history research is web applications (New FamilySearch?) and the need for improvements in data transfer file formats then becomes moot. In other words, Gedcom 6 was just a draft and will remain so. Chad Hanna -- Chad Hanna Systems Developer FamilyHistoryOnline www.familyhistoryonline.net FreeBSD Apache MySQL Perl mod_perl PHP

Subject: Re: GEDCOM as a database format FLAPDOODLE! Recent contributions on this SIG contain confusing, often argumentative, rhetoric about genealogy and GEDCOMs ... Please, gurus all: it would really help IF you would use a spell check (e.g. the subject line error) and edit messages; IF you would use English without descent into jargon (which has as many dialects as there are discussants), replacing gobbledygook with plainspeak; IF you would refrain from using self-serving arch comments (see how clever i am), sophisticated putdowns, and demeaning childish yah yah yahs (yer mother wears army boots, stoopid); IF you would recommit to fostering an understanding of the technical aspect of compugenealogy for non-experts as well as cognoscente; IF you would continue to question, to respect suggestions, and to re-evaluate; IF you would admit that you might be wrong or have no answer; Please:: more wise comments, less wise cracks and ... FLAPDOODLE ... hava happy holiday ken gompertz gomog@optusnet.com.au Message: 10 Date: Sat, 15 Dec 2007 19:49:15 -0500 From: "T.M. Sommers" <tms@nj.net> Subject: Re: GEDOM as a database format To: gencmp@rootsweb.com Message-ID: <4764760a$0$30082$470ef3ce@news.pa.net> Content-Type: text/plain; charset=us-ascii; format=flowed singhals wrote: > JD <jd4x4@ wrote: >> singhals <singhals@erols.com> wrote in >> news:HY-dnZWMyuQFNP_anZ2dnUVZ_sytnZ2d@rcn.net: >>> JD <jd4x4@ wrote: >>> >>>> Certainly everyone can agree on items such as Name, Date, Source, >>>> Notes, Comments, etc. >>>> Yes?? >>> >>> No. >> >> When you say "No." are you saying that there is a disagreement about >> the usefulness of these items, or the labels that I used to describe >> them? > > Neither. I'm saying that there is no general agreement as to the > appropriate content of a field with nearly any label at all. > > Name: should this contain the name on the birth certificate, the name on > the marriage license, or the name by which the individual was known? Yes. GEDCOM allows multiple names. > Date: the date of the event as reported, or the date of the report of > the event? Is it dd MMM yyyy or yyyy mm dd or mm dd yyyy? GEDCOM says day month year. > Whose > calendar are we using? GEDCOM allows you to specify your calendar. > Source: you mean, where did _I_ get the info or where the info originate? That's a semantic issue, not a syntactic one, but I believe the former is the scholarly standard, with a note citing the source's source. > "Notes": Many of us feel "NOTES" is the proper place to put source > citations, That's what the SOUR tag is for. > as well as narrative about the person or family group. > Others feel "NOTES" should be confined to check lists of things that > need checking/doing/researching on this person. The NOTE tag can be used for anything. > Others feel that > "NOTES" are the only place to put details of physical descriptions and > the like. That's what the DSCR tag is for. > SOME other folk call some of those COMMENTS instead of NOTES. Call it what you want, the tag is NOTE. > So long as those definitions are all in play, then enforced > standardization is impossible and probably undesirable. Worse, once > there is somesort of enforced standardization, a certain number of > people (probably including me) will spend enormous amounts of time > circumventing the requirements, for the perfectly valid reason: I don't > like to do it that way. As a lagniappe, we can then proceed to foul up > YOUR system. No standard, on any subject, will be 100% agreeable to everyone. Someone will always find some part or other "wrong". However, if we want to work and communicate with each other, we have to use standards, so some compromise is required. Take spelling. If you insist on spelling words the way you think is proper, you have only yourself to blame if no one understands or even reads what you ruheet. -- Thomas M. Sommers -- tms@nj.net -- AB2SB

Ian Goddard <goddai01@hotmail.co.uk> wrote: > There are several distinct issues here: > I agree, and I apologize for my earlier posts under this topic because I really wanted to discuss the use/benefits (imo) of adopting XML. To that end, I'm going to start a new thread because I'm still interested in the topic.

There are several distinct issues here: 1. GEDCOM 6 vs earlier. GEDCOM 6 is an XML version. There is a document describing it but I'm not sure of its status - is it still work in progress? In any event it doesn't seem to be used. It follows the same data model as the current 5.5 so any references to the data model apply to both. Where we consider "GEDCOM" vs XML in terms of parsing files, etc. them "GEDCOM" is likely to mean 5.5 or earlier and XML would include GEDCOM 6. But, to repeat myself, 6 doesn't seem to be in use. 2. GEDCOM (pre-6) as a database format. By database format I mean the internal database used by an application to store and manipulate data. GEDCOM wouldn't be my choice irrespective of data model considerations. My choice would probably be an RDBMS. Familiarity is part of this but there is a huge choice of database engines, there is a (more or less) standard language, SQL and there are technologies which to some extent decouple the choice of programming language from the choice of engine. In comparison GEDCOM would have to be stored as a text file between program runs, parsed on each run and rewritten at the end of any run which amends the file. The parser would have to be a dedicated GEDCOM parser. Unless a supplementary index is used alongside the text file the data would have to be re-indexed on each run (probably using a dedicated GEDCOM indexer) or else the benefits of indexing would have to be foregone. If indexing is not used scalability would be more difficult. As a text file the data store would be open to modification with a text editor which is a problem for integrity and death to an external index. 3. GEDCOM 6 (and other XML) as a database format. As a text format this has some of the disadvantages as plain XML in terms of having to be parsed and indexed for each run. Unlike plain GEDCOM, however, there is plenty of ready-made technology for this including XQUERY. XMLT technology will assist web-site and report generation. 4. GEDCOM as a data exchange format. This is a more appropriate application as scalability would not be an issue. The parsing requirements remain, however. 5. GEDCOM 6 (and other XML) as a data exchange format. This would be a preferable data exchange format as it has the technological advantages of XML. 6. GEDCOM as a data model. Whether as a database or data exchange format GEDCOM cannot be better than its underlying data model. This is a fairly simple model Presumably it meets LDS's requirements but for some of us it's too limited. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

In article <gbzcfgargnh.jt8z9b1.pminews@news.st.net.au>, "Tom Perrett" <tomp@st.net.au> wrote: > On Mon, 17 Dec 2007 21:01:21 GMT, JDverizon.net> wrote: > > >Having written the diatribe about XML > > I suppose I should dig around, but > perhaps something might be clarified for > me. > > I thought that XML was a proprietary > standard (ie Microsoft), rather than > a proper standard for all such as > GEDCOM. > > So should not we avoid a proprietary > standard? > > > > Cheers, > > Tom [Tom Perrett] <tomp@st.net.au> GEDCOM is a "standard" to the extent that it's been accepted widely as a common format for data storage. When all is said and done, however, it is only a text file whose contents must adhere to a specific set of rules in order to be properly understood by those who read it. XML is a language -- eXtensible Markup Language -- much the same way as HTML is a language. It has a defined set of rules for its use, and it's established by a governing body...not by Microsoft, thanks. If you look at many web pages, your browser will let you view the "source" and see how it's built. XML, like HTML, has a series of "tags" and those tags can include "attributes" with values. Unlike HTML, XML is required to close every tag and case does matter. Essentially, though, it's just a "markup language" which one can use any way they see fit in order to carry information. In my day job, I've been developing and maintaining an application for over seven years now that uses XML for its data storage -- and what's inside those XML tags, attributes, etc., is unique to our application and therefore "proprietary" in a sense. But a whole range of readily available software could readily open and parse the files we create -- they just wouldn't know what it's all supposed to mean the way our app does. So what the OP seeks is a genealogy/family history program that uses XML as the basis for its information content. I know that there was supposed to be an effort underway to promote a new GEDCOM standard (6.0, whereas the current one is 5.5) that uses XML, but I'm not aware of its current status. Nor am I aware of any software to date that uses XML for its own "proprietary" data format. But I will agree with the OP that using XML as the basis for the data managed by any app (whether or not it's genealogy-related) greatly improves the ability of third parties to see what's contained therein, and perhaps even to offer some extensibility for many software packages as a result. After more than seven years as a user of XML, I too have become an advocate. = Steve = -- Steve W. Jackson Montgomery, Alabama

ken gompertz wrote: > Subject: Re: GEDCOM as a database format > > FLAPDOODLE! > > Recent contributions on this SIG contain confusing, often argumentative, > rhetoric about genealogy > and GEDCOMs ... > > Please, gurus all: it would really help > > IF you would use English without descent into jargon (which has as many > dialects as there are discussants), replacing gobbledygook with plainspeak; > OK, the serious comment. A working library of XML books will occupy at minimum 6" of shelf space and probably a great deal more. It will define and use a great deal of technical vocabulary - or jargon if you prefer. The alternative would be to explain everything at tedious length. But that jargon has only one "dialect" as you put it, not many (unless you include the book on XML Schema which gratingly insists on treating "schema" as a plural form). Likewise genealogy has its own specialist vocabulary. Again it would be tedious to explain every term at length. (If you are not persuaded of this maybe you should remember that there are many terms in everyday life which were once specialist technical terms. These include the components of a car. You might find it enlightening to try the exercise of writing out instructions on how to drive a car round the block without using such technical terms as "starter", "steering wheel" and "clutch".) This newsgroup deals with genealogy and computing. In that case it seems to me that use of the technical terms of both disciplines is not only perfectly proper but essential. I certainly didn't find the discussion you quoted to be gobbledygook. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

ken gompertz wrote: > Subject: Re: GEDCOM as a database format > > FLAPDOODLE! > > > IF you would use a spell check (e.g. the subject line error) and edit > messages; > > IF you would refrain from using self-serving arch comments (see how clever i am Did your spell checker really pass a lower case i as a word? -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

"Tony Proctor" <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote in news:fdifec$v25$1@reader01.news.esat.net: > I was thinking of "interoperability" though Ian. I agree with the > principles of first defining an abstract data model, and then ensuring > there's an exchange format that can be used for import/export, email, > etc. However, if each proprietary database provides an implementation > standard API then it means other software can examine (& optionally > update) data still in that proprietary database, without the need for > convoluted import/export. > To some extent XML also specifys interoperability, if you consider that to read it you need to be able to do something with the data (at least read and hopefully show it in the context of the schema), and should be able to write it back someplace in the context of the schema you got it in. Most of the comments I see about XML being inappropriate deal with either the labels or usage logic or the granularity of the schema. Everyone overlooks the "extensible" benefit of strict XML and the data itself in context with a known scheme. > A software designer with a great idea, for instance, could write their > utility conforming to the description of that API. Anyone could then > use it if the supplier of their current database offers an > implementation of that API. > > Tony Proctor > > "Ian Goddard" <goddai01@hotmail.co.uk> wrote in message > news:78idneS-vee9p2HbnZ2dnUVZ8sylnZ2d@pipex.net... >> Tony Proctor wrote: >> > My case is for a standardised database representation Jack. There >> > mere > fact >> > a program is using SQL doesn't mean another program can come along >> > and > use >> > the same data. I suggested a standardised 'SQL schema' but I'm not >> > sure > what >> > bodies would have to be involved in defining and ratifying such a > schema. >> > >> > Such a schema would not compromise the flair and ingenuity of >> > existing programs, but it would "open up the field" by separating >> > the data from > the >> > programs >> > >> > GEDCOM/XML would then be purely interchange formats, which is >> > probably > what >> > they're best at anyway. >> > >> > Tony Proctor >> > >> >> I think that what needs to be got right in the first place is the >> data model. >> >> From that you would head off along two development paths. One would >> be >> implementation within an application and the other would be data >> exchange. >> >> For implementation purposes the developers could choose their own >> internal representation. They could use non-SQL RDBMS, SQL, XML, >> object-relational, persistent objects or even punched cards (that >> dates me!) if it did the job for them. >> >> For data exchange XML is pretty well a no-brainer so the second >> standardisation step would be to define an XML schema. Given that >> one would have some degree of control over standards conformance of >> applications. For instance a conformant program would have to be >> able to import any valid XML document (for non-XMLers a "document" is >> what you would probably call a file, a "valid" document is one which >> is in accord with the schema) and any exported document would have to >> be valid and it should be able to import a document and, in the >> absence of any editing by the user, export a functionally equivalent >> document. > >

I've just come across the GeoPic II will which record latitude/longitude/altitude/ UTC time as EXIF data in the digitial photos on certain Nikon DSLRs - see www.customidea.com Many other cameras can interface with third party GPS units and recording with photos seem a very good way to record information.

Dennis Lee Bieber wrote: > On Fri, 14 Dec 2007 11:29:11 -0500, singhals <singhals@erols.com> > declaimed the following in soc.genealogy.computing: > > > >>Yeah, it'll show me the street address and the map location, >>but NOT the lat/lon. >> > > Sounds more like something from TomTom, meant to give driving > directions for on-road usage... > > Even the smallest Garmin eTrex model should handle what you want > https://buy.garmin.com/shop/compare.do?cID=144&compare=compare&compareProduct=6403 > 500 waypoints; they don't mention how many coordinate systems and datums > are supported. Typically you can toggle the coordinate system after > recording a waypoint in one format to view it in another. You'll also > want to take note of the datum -- native for GPS is WGS-84, but most > USGS topographic maps are still in NAD-27; to use a coordinate from the > GPS you'd want to set the datum to NAD-27 so the numbers match what the > map was referenced against. > > My current unit is > https://buy.garmin.com/shop/compare.do?cID=145&compare=compare&compareProduct=351 > 1000 waypoints/50 routes (digging up my manual as the site doesn't > mention how many points per route -- 50 routes of 250 points each). This > unit is probably more than you are interested in (and 4.5 times the $$$ > of the basic eTrex). It even has a parachute "jumpmaster" program in > which you preload expected winds at altitude intervals > (speed/direction), the expected jump altitude, the expected chute open > altitude (HALO freefall jump or immediate chute open HAHO no freefall), > and the landing site -- the program will then indicate where/when you > reach an appropriate jump location to account for wind drift. And silly > games (a virtual "whack-a-mole" where you have to run over something the > size of a football field to get to the "mole" before it disappears). I > have it loaded with the extra$$ US street and Topo maps for California, > Nevada, Oregon, Washington, and Michigan -- took about 200MB of a 1GB > memory cartridge. > > >>Except, I _understand_ lat/lon (g). >> > > As mentioned, you can change the coordinate units at any time and > see the waypoints in that way. > > >>There's a stream nearby but nothing else guaranteed not to > > > Don't trust a stream... a few springs of good flooding could move > its channel a few dozen feet <G> Why, you li'l ol' optimist, you! (G) I'll take a longer look at Garmin. Thanks. Cheryl

< 5 hrs to go...bidding @ < $100 e bay item >> 190181526890 On Dec 6, 4:38 pm, "~^ beancounter ~^" <richboni...@gmail.com> wrote: > Due to a fraudulant bidder/winner...auction re started > @ $.01 (again)...>> New item number is 190181526890 > > On Dec 2, 12:10 pm, "~^ beancounter ~^" <richboni...@gmail.com> wrote: > > > > > Nikon 35mm slide scanner equipment...(FS) > > ------------------------------------------------------------------------ > > ebay item # 190178460082...Nikon quality...excellent > > digitial results, fast and easy to use. state of the art > > software....bidding starts @ $.01 > > > thank you !!!!- Hide quoted text - > > - Show quoted text -

singhals <singhals@erols.com> wrote in news:DNKdnaASAKwG3_nanZ2dnUVZWhednZ2d@rcn.net: > JD <jd4x4@ wrote: > >> singhals <singhals@erols.com> wrote in >> news:HY-dnZWMyuQFNP_anZ2dnUVZ_sytnZ2d@rcn.net: >> >> >>>JD <jd4x4@ wrote: >>> >>>>Certainly everyone can agree on items such as Name, Date, Source, >>>>Notes, Comments, etc. >>>>Yes?? >>> >>> >>>No. >>> >>>Cheryl >> >> >> When you say "No." are you saying that there is a disagreement about >> the usefulness of these items, or the labels that I used to describe >> them? > When I wrote the reply, I had a feeling you would be going in a couple of different places eventually, and I had a longer reply but decided to take then one step at a time. :-) > Neither. I'm saying that there is no general agreement as > to the appropriate content of a field with nearly any label > at all. > Re-reading my example, I could see that I was mixing some items for the sake of not being totally XML-compliant (anal).. for conceptual brevity. But, here goes... > Name: should this contain the name on the birth certificate, > the name on the marriage license, or the name by which the > individual was known? > Yes. What the actual value for this data item depends on where it came from. See Source, below. > Date: the date of the event as reported, or the date of the > report of the event? Is it dd MMM yyyy or yyyy mm dd or mm > dd yyyy? Whose calendar are we using? > Both, all. Which date data item are we talking about, and what's the source and/or context? > Source: you mean, where did _I_ get the info or where the > info originate? > OK, Source shouldn't have been used so generally because it needs to be made up of a name & a date as well as a required element of the other elements, and it (depending on your location in the info chain, because if you add/modify it and pass it on you're now a source) may itself be made up of multiple instances. > "Notes": Many of us feel "NOTES" is the proper place to > put source citations, as well as narrative about the person > or family group. Others feel "NOTES" should be confined to > check lists of things that need checking/doing/researching > on this person. Others feel that "NOTES" are the only place > to put details of physical descriptions and the like. SOME > other folk call some of those COMMENTS instead of NOTES. > Yup. Knew notes & comments were a mistake, too. Again, I meant these kind of conceptually as in what you find in them now. I can't say that I agree with whoever thinks citations are notes, but whatever floats their boat is fine. Their software & schema can remap the source element(s) to whatever they like if they get my data that has a source element. If they enter a new item that they might consider a citation, but has a note tag on it I'll evaluate it, but without it being tagged as a source record... it isn't .. in my schema, and I know that in their schema it's a note. But I'll have their schema and I can evaluate their context. > So long as those definitions are all in play, then enforced > standardization is impossible and probably undesirable. I'm simply saying that XML provides a way to tag data, and see what the context is by virtue of a schema. As part of it's design, I can see their rules. ie, a name requires a source, or it doesn't. If it doesn't then I'm no worse off than I am now. If my rules differ from theirs but they at least agree to tag things according to SOME scheme and it's XML compliant then I know the context and I can have a machine do a lot of work for me. The only thing that's forced is a tag for what you call the data and show me how you group them together. > Worse, once there is somesort of enforced standardization, a > certain number of people (probably including me) will spend > enormous amounts of time circumventing the requirements, for > the perfectly valid reason: I don't like to do it that way. > As a lagniappe, we can then proceed to foul up YOUR system. > > The fact that I don't care how you organize, record, store, > or retrieve your data, so long as I can do it the way _I_ > prefer in my own data, is the reaon there are so many genie > programs out there and the reason none of them do a real > fine job of GEDCOM transport anything past name, date, > place, relationship. > GEDCOM only requires a tag and a suggested model of what relates to what. If every piece of software gave you a file that only gave you the data with a tag that was the same as the name of the box that you typed the data into, and the file also showed you how there was a relationship (if any) between the data boxes, would you be better off? > Cheryl

Hugh Watkins <hugh.watkins@gmail.com> wrote in news:5shj2oF19lp72U1@mid.individual.net: > genealogy or pedigree is for domestic animals > > > family history and social networking is where it is all going on > your most vital task is to record the memories of the living , > including your own, eg names, dates and places of photographs before > they are lost forever > > Hugh W > > Interesting info. I draw the conclusion that important elements to you are <people> <names> <dates> <places> <photographs> <memories>. I have info that I classify using the same labels. :-)

singhals wrote: > > Understood. In my primary interest case, if you can get within 30 ft > you ought to see the fence ... and it ought to still be there, it was > built to LAST. Doesn't the US have anything equivalent to the UK's OS grid references? If you have a grid ref. - which you would work out by comparing what's on the ground with a current map - then even if there is considerable redevelopment, new roads, diversions of streams, etc. once the area ha been remapped you could look up the reference on the new map and thus refind the location on the ground. And don't be too sure about lasting! If you enter 414300,408300 into www.streetmap.co.uk as grid coordinates it will point to what was a burial ground. This isn't the cemetery currently marked on the map because the local council turned it into a mini-park and removed as many of the grave markers as they could get away with. Those left aren't in the original locations, some of them are being used as paving stones! -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

singhals wrote: > > Name: should this contain ... the name on the marriage license And just to complicate it further, should the name on the license be registrar's spelling entered or spelling as signed? In the case of my ggg-mother they varied. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

>> >>Will Family Tree Maker 2008 run on Win 98se?? >> >>I tryed it and could not get it to run. Kept getting some message >>about debugging something. Finally went back to 2006 version. > >Microsoft stopped to support Win 98 this year. This means >among other things that they won't include Win 98 support in >the softwares they are selling, including for instances the >libraries that can be used by genealogy softwares. > >A recent software made from Microsoft compilers or libraries won't >run on Win 98 or 98SE while if it is made with 3rd party development >tools, it more likely will run. Thanks all for the replies. Appreciate it.

singhals <singhals@erols.com> wrote in news:HY-dnZWMyuQFNP_anZ2dnUVZ_sytnZ2d@rcn.net: > JD <jd4x4@ wrote: >> Certainly everyone can agree on items such as Name, Date, Source, >> Notes, Comments, etc. >> Yes?? > > > No. > > Cheryl When you say "No." are you saying that there is a disagreement about the usefulness of these items, or the labels that I used to describe them?

singhals wrote: > JD <jd4x4@ wrote: >> singhals <singhals@erols.com> wrote in >> news:HY-dnZWMyuQFNP_anZ2dnUVZ_sytnZ2d@rcn.net: >>> JD <jd4x4@ wrote: >>> >>>> Certainly everyone can agree on items such as Name, Date, Source, >>>> Notes, Comments, etc. >>>> Yes?? >>> >>> No. >> >> When you say "No." are you saying that there is a disagreement about >> the usefulness of these items, or the labels that I used to describe >> them? > > Neither. I'm saying that there is no general agreement as to the > appropriate content of a field with nearly any label at all. > > Name: should this contain the name on the birth certificate, the name on > the marriage license, or the name by which the individual was known? Yes. GEDCOM allows multiple names. > Date: the date of the event as reported, or the date of the report of > the event? Is it dd MMM yyyy or yyyy mm dd or mm dd yyyy? GEDCOM says day month year. > Whose > calendar are we using? GEDCOM allows you to specify your calendar. > Source: you mean, where did _I_ get the info or where the info originate? That's a semantic issue, not a syntactic one, but I believe the former is the scholarly standard, with a note citing the source's source. > "Notes": Many of us feel "NOTES" is the proper place to put source > citations, That's what the SOUR tag is for. > as well as narrative about the person or family group. > Others feel "NOTES" should be confined to check lists of things that > need checking/doing/researching on this person. The NOTE tag can be used for anything. > Others feel that > "NOTES" are the only place to put details of physical descriptions and > the like. That's what the DSCR tag is for. > SOME other folk call some of those COMMENTS instead of NOTES. Call it what you want, the tag is NOTE. > So long as those definitions are all in play, then enforced > standardization is impossible and probably undesirable. Worse, once > there is somesort of enforced standardization, a certain number of > people (probably including me) will spend enormous amounts of time > circumventing the requirements, for the perfectly valid reason: I don't > like to do it that way. As a lagniappe, we can then proceed to foul up > YOUR system. No standard, on any subject, will be 100% agreeable to everyone. Someone will always find some part or other "wrong". However, if we want to work and communicate with each other, we have to use standards, so some compromise is required. Take spelling. If you insist on spelling words the way you think is proper, you have only yourself to blame if no one understands or even reads what you ruheet. -- Thomas M. Sommers -- tms@nj.net -- AB2SB

Jeff wrote: > singhals wrote: > >> >> I have an unmarked, tiny, family cemetery, the location of which is >> currently known to fewer than a dozen living beings. I want to get >> the lat/lon on record somewhere in my data so that 50 or 60 years from >> now after my cousin and I lose touch my side of the family can find it >> again. >> >> We were talking at a party t'other night and turns out none of us have >> a GPS unit that will allow us to RETRIEVE the lat/lon afterward. All >> will show us the point we marked, all will provide driving directions, >> all _record_ the lat/lon for internal use, but NONE would let us see >> it a 2nd time. >> > > Why not just mark the location on Google Earth and print out the map? Or > for that matter mark it on a local topographical map? Perhaps I'm misunderstanding something about Google Earth, but don't I have to know where something is before I can mark it? Cheryl

JD <jd4x4@ wrote: > singhals <singhals@erols.com> wrote in > news:HY-dnZWMyuQFNP_anZ2dnUVZ_sytnZ2d@rcn.net: > > >>JD <jd4x4@ wrote: >> >>>Certainly everyone can agree on items such as Name, Date, Source, >>>Notes, Comments, etc. >>>Yes?? >> >> >>No. >> >>Cheryl > > > When you say "No." are you saying that there is a disagreement about the > usefulness of these items, or the labels that I used to describe them? Neither. I'm saying that there is no general agreement as to the appropriate content of a field with nearly any label at all. Name: should this contain the name on the birth certificate, the name on the marriage license, or the name by which the individual was known? Date: the date of the event as reported, or the date of the report of the event? Is it dd MMM yyyy or yyyy mm dd or mm dd yyyy? Whose calendar are we using? Source: you mean, where did _I_ get the info or where the info originate? "Notes": Many of us feel "NOTES" is the proper place to put source citations, as well as narrative about the person or family group. Others feel "NOTES" should be confined to check lists of things that need checking/doing/researching on this person. Others feel that "NOTES" are the only place to put details of physical descriptions and the like. SOME other folk call some of those COMMENTS instead of NOTES. So long as those definitions are all in play, then enforced standardization is impossible and probably undesirable. Worse, once there is somesort of enforced standardization, a certain number of people (probably including me) will spend enormous amounts of time circumventing the requirements, for the perfectly valid reason: I don't like to do it that way. As a lagniappe, we can then proceed to foul up YOUR system. The fact that I don't care how you organize, record, store, or retrieve your data, so long as I can do it the way _I_ prefer in my own data, is the reaon there are so many genie programs out there and the reason none of them do a real fine job of GEDCOM transport anything past name, date, place, relationship. Cheryl