"Nigel Bufton" <nigel@bufton.org> wrote: > > I see nothing here that is not self-explanatory. What is it in the > OP's question that I am not understanding? :-) Dunno. I thought maybe it had more to do with what sort of text was appropriate but I wasn't totally sure myself. That's why I thought the auto-generated Ancestry entry might be of help.

Tony Proctor wrote: > "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message > news:13mrvtst5hh523c@corp.supernews.com... > >>On Sun, 23 Dec 2007 04:33:37 GMT, JD <jd4x4@<del.this>verizon.net> >>declaimed the following in soc.genealogy.computing: >> >> >>>I personally wouldn't want software that ignored something and didn't at >>>least provide me with a means of dealing with it. But if it did, as you >>>say it can be transformed with xslt, which is exactly what I did with my >>>publishing source data. I had several sources each with slightly >> >>XSLT still requires a known source and destination format; it can't >>take an unknown source tag and create a known destination tag with >>meaning... Maybe it can produce some sort of blanket output for unknown >>tags, but that will quite likely not be a reversible transformation. >> >> >>>differing source schemas, but all of the data was related and I created >>>my own "final" schema from them, for the use I required. And, the >> >>You "created"... The software didn't derive a consistent schema... >> >>Who "creates" the schema and transforms for all the many programs >>that currently exists? >> >> >>>See the above. The "standardization" you refer to doesn't mean that the >>>data has been changed, only reordered.. to YOUR schema. Software doesn't >>>have to do that alone. YOUR schema can be YOUR ordering of the data. >>> >> >>To me, said ordering requires prior knowledge of what the meaning of >>various tags IS... What if "my" data considers "fourth flood of the >>river <x> in the reign of <y>" to be acceptable as a date (okay, even >>TMG would consider that a very irregular date). How would your software >>treat something that output such as "<date>....</date>", vs >>"<date><month>...</month><day>...</day><year>...</year></date>" >> >>Besides... I'm buying the software to handle the genealogical data >>and reporting... I'm not writing my own package in which I have the >>option of defining transforms into what I think should be used... Unless >>all the producers of said software all agree on what is valid data, >>commercial software will not be able to /losslessly/ accept the data of >>others. >> >> >>>And should you be in a position (as I was) to need a third application >>>for the data that would have a somewhat different output... you could >>>then define your own schema and validate against it. >>> >> >>How many weekend genealogists are going to even know what an XML >>transform is, much less write one to handle one source of data? >> >> >>>So we don't need to perpetuate that by not providing a mechanism that >>>could facilitate automation, imo. >> >>Well, we could insist that all extant genealogy programs be modified >>to refuse to accept any data entry that doesn't have some sort of source >>citation, even if it is nothing more than "personal knowledge of <xyz>" >>-- >>Wulfraed Dennis Lee Bieber KD6MOG >>wlfraed@ix.netcom.com wulfraed@bestiaria.com >>HTTP://wlfraed.home.netcom.com/ >>(Bestiaria Support Staff: web-asst@bestiaria.com) >>HTTP://www.bestiaria.com/ > > > XML is touted as some sort of panacea. It is an improvement on the plethora > of data formats (in all IT areas) that existed previously, but it has to be > understood for what it is. It is merely a standardised syntax for > representing hierarchical data. That standardisation therefore only applies > to the syntax, not to the semantics. What this means, in layman speak, is > that any XML file is instantly recognisable as "XML" but it doesn't make the > content any more understandable. > As examples of the obvious in Tony's last sentence: I may _recognize_ that a letter is written in Hindi or Russian without having ANY clue what the letter is about. I may even recognize that the paper upon which the letter is written is high-ticket paper but I don't necessarily know from which company or how high the ticket was. Notes from some of Einstein's (or Hawking's) research log are instantly recognizable as being written in plain-text, but not too many of us actually _understand_ most of the work being logged. > Sure, there are lots of tools for loading/viewing/manipulating XML but they > only know about the syntax, not the semantics. Yes, you can write your only > XSLT (which I have to say is an awful language) but all those > transformations would be doing is manipulating the syntax, e.g. removing > stuff, moving stuff around, extracting stuff, etc. In principle, this would > all be possible with any documented data format, including GEDCOM, at the > expense (& risk) of having to write a little more of the necessary software > yourself. > > I firmly believe that a "data model" has to be defined and accepted first. > This subject has come up several times in this group, and links have been > posted here about ongoing projects striving to achieve this. Once such a > data model specification exists then representation of it in any data format > (XML, GEDCOM, some other) is almost a mechanical operation Total agreement on the data-model will be achieved when If And ONLY IF (IFF) only one person has to be pleased by it. I don't care to record the names of 200 wedding guests, others want that information. Some people want to include the GPS data on the precise place of burial; I figure the name of the cemetery and a place-name is all the precision I need 90% of the time (and the other 10%, I put in notes to myself). But so long as there is "room" in the market for conflicting views on whether the GPS data is necessary or whether the names of all witnesses (as opposed to only the official witnesses as opposed to only the names of the participants) are necessary ... there's gonna be a need for a data-model so flexible it may as well not exist (see also: Gedcom standard). IME, YMMV, and so on. Cheryl

"Wes Groleau" <groleau+news@freeshell.org> wrote in message news:TBkcj.4619$XW3.2403@trnddc04... > JD <jd4x4@ wrote: >> For what its worth, here is how the Ancestry.com gedcom export cites a >> residence that was auto-entered (via adding to my online tree). > > Thanks, that's a reasonable answer, though it still seems > like overkill to me. Is it just me that is confused by this thread? The OP's question was simply: "Anyone aware of well-argued recommendations for how to cite census in GEDCOM SOUR structures?" As a reminder, the GEDCOM standard SOUR structure is: n @<XREF:SOUR>@ SOUR {1:1} +1 DATA {0:1} +2 EVEN <EVENTS_RECORDED> {0:M} +3 DATE <DATE_PERIOD> {0:1} +3 PLAC <SOURCE_JURISDICTION_PLACE> {0:1} +2 AGNC <RESPONSIBLE_AGENCY> {0:1} +2 <<NOTE_STRUCTURE>> {0:M} +1 AUTH <SOURCE_ORIGINATOR> {0:1} +2 [CONT|CONC] <SOURCE_ORIGINATOR> {0:M} +1 TITL <SOURCE_DESCRIPTIVE_TITLE> {0:1} +2 [CONT|CONC] <SOURCE_DESCRIPTIVE_TITLE> {0:M} +1 ABBR <SOURCE_FILED_BY_ENTRY> {0:1} +1 PUBL <SOURCE_PUBLICATION_FACTS> {0:1} +2 [CONT|CONC] <SOURCE_PUBLICATION_FACTS> {0:M} +1 TEXT <TEXT_FROM_SOURCE> {0:1} +2 [CONT|CONC] <TEXT_FROM_SOURCE> {0:M} +1 <<SOURCE_REPOSITORY_CITATION>> {0:1} +1 <<MULTIMEDIA_LINK>> {0:M} +1 <<NOTE_STRUCTURE>> {0:M} +1 REFN <USER_REFERENCE_NUMBER> {0:M} +2 TYPE <USER_REFERENCE_TYPE> {0:1} +1 RIN <AUTOMATED_RECORD_ID> {0:1} +1 <<CHANGE_DATE>> {0:1} and the citation within a referencing record structure is: n SOUR @<XREF:SOUR>@ /* pointer to source record */ {1:1} +1 PAGE <WHERE_WITHIN_SOURCE> {0:1} +1 EVEN <EVENT_TYPE_CITED_FROM> {0:1} +2 ROLE <ROLE_IN_EVENT> {0:1} +1 DATA {0:1} +2 DATE <ENTRY_RECORDING_DATE> {0:1} +2 TEXT <TEXT_FROM_SOURCE> {0:M} +3 [ CONC | CONT ] <TEXT_FROM_SOURCE> {0:M} +1 QUAY <CERTAINTY_ASSESSMENT> {0:1} +1 <<MULTIMEDIA_LINK>> {0:M} +1 <<NOTE_STRUCTURE>> {0:M} I see nothing here that is not self-explanatory. What is it in the OP's question that I am not understanding? Nigel www.tcgr.bufton.org

Wes Groleau <groleau+news@freeshell.org> wrote: > JD <jd4x4@ wrote: >> For what its worth, here is how the Ancestry.com gedcom export cites a >> residence that was auto-entered (via adding to my online tree). > > Thanks, that's a reasonable answer, though it still seems > like overkill to me. > That's the main reason that I do my rough tree online and export it to the PC.. Ancestry auto-includes the source info without me typing it! And, they seem to be enhancing it more lately as time goes on. That's one of my hopes for the use of XML, etc. with some other web sources & future software. Let the PC do the grunt work!

Hugh Watkins <hugh.watkins@gmail.com> wrote: > > http://hughw36.blogspot.com/2007/12/happy-christmas-2007.html > > my Christmas card is our own tree decorated by my daughter in Copenhagen > Denmark > > Hugh W > Nice tree, Hugh. Solihull, eh? I used to visit there a lot in my previous adventures with a used-to-be-all-British-now-American-owned-soon-to-be-Indian-owned world's best 4-wheel drive vehicle manufacturer! Very pretty town. And, you scare me with how much alike we look, except I keep my beard shorter. :-O

JD <jd4x4@ wrote: > For what its worth, here is how the Ancestry.com gedcom export cites a > residence that was auto-entered (via adding to my online tree). Thanks, that's a reasonable answer, though it still seems like overkill to me. -- Wes Groleau "Beware the barrenness of a busy life." -- George Verwer

Hello Listers, While my normal mail is with Bigpond, I also have a Hotmail account for some genealogy. I have not received anything for a few days which is most unusual. Is anyone else having trouble with their hotmail? Regards. Kathryn Rogers

Head Geek <headgeek@Kubuntu.local> wrote: > Anyone aware of well-argued recommendations for how to cite census in > GEDCOM SOUR structures? > > I've read Mills' PRINT suggestions, but print is not something I have > any plans for. For what its worth, here is how the Ancestry.com gedcom export cites a residence that was auto-entered (via adding to my online tree). This is one (of many) residence detail cite & then the master citation: 1 RESI 2 DATE 1860 2 PLAC Cambridge, Dorchester, Maryland 2 SOUR @S2239539411@ 3 PAGE Year: 1860; Census Place: Cambridge, Dorchester, Maryland; Roll: M653_473; Page: 357; Image: 536. 3 NOTE http://trees.ancestry.com/rd?f=sse&db=1860usfedcenancestry&h= 53770455&ti=0&indiv=try 0 @S2239539411@ SOUR 1 TITL 1860 United States Federal Census 1 AUTH Ancestry.com 1 PUBL Online publication - Provo, UT, USA: MyFamily.com, Inc., 2004.Original data - United States of America, Bureau of the Census. Eighth Census of the United States, 1860. Washington, D.C.: National Archi 2 CONC ves and Records Administration, 1860. M653, 1,438 rolls.

Kurt wrote: > "Head Geek" <headgeek@Kubuntu.local> wrote in message >> Anyone aware of well-argued recommendations for how to cite census > in >> GEDCOM SOUR structures? > > Write them in the same form as references in scientific publications. References in scientific publications are rarely put in a form that can be legal GEDCOM. > The main point is that it must be possible for other persons to find > the source. Exactly. And "1930 Census, Missouri, Monroe County, Bon Femme Twp., page 101A" is _more_ than adequate for that. What is demanded by the NGS Quarterly is overkill. I was just wondering whether a "happy medium" had ever been discussed to a consensus anywhere. Obviously no such thing is binding on anyone, but I was wondering. -- Wes Groleau You always have time for what you do first.

Nigel Bufton wrote: > "Head Geek" <headgeek@Kubuntu.local> wrote in message >> Anyone aware of well-argued recommendations for how to cite census in >> GEDCOM SOUR structures? >> > Surely census data elements are no different from any other discovered data. I didn't ask about data elements. I asked about the SOUR structure. -- Wes Groleau "Two things are infinite, the universe and human stupidity. But I'm not so sure about the universe." -- Albert Einstein

First off..Merry Christmas, Happy Holidays, and a good winter solstice to all. "Tony Proctor" <tony_proctor@aimtechnology_NoMoreSPAM_.com> wrote: > "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message > news:13mrvtst5hh523c@corp.supernews.com... >> On Sun, 23 Dec 2007 04:33:37 GMT, JD <jd4x4@<del.this>verizon.net> >> declaimed the following in soc.genealogy.computing: >> >> > >> > I personally wouldn't want software that ignored something and >> > didn't at least provide me with a means of dealing with it. But if >> > it did, as you say it can be transformed with xslt, which is >> > exactly what I did with my publishing source data. I had several >> > sources each with slightly >> >> XSLT still requires a known source and destination format; it can't >> take an unknown source tag and create a known destination tag with >> meaning... Maybe it can produce some sort of blanket output for >> unknown tags, but that will quite likely not be a reversible >> transformation. >> >> > differing source schemas, but all of the data was related and I >> > created my own "final" schema from them, for the use I required. >> > And, the >> >> You "created"... The software didn't derive a consistent schema... >> >> Who "creates" the schema and transforms for all the many programs >> that currently exists? >> Whomever finds it relevant. Really though, Tony's point about the "data model" is where it has to start, imo. But more on that later.. >> > >> > See the above. The "standardization" you refer to doesn't mean that >> > the data has been changed, only reordered.. to YOUR schema. >> > Software doesn't have to do that alone. YOUR schema can be YOUR >> > ordering of the data. >> > >> To me, said ordering requires prior knowledge of what the meaning of >> various tags IS... What if "my" data considers "fourth flood of the >> river <x> in the reign of <y>" to be acceptable as a date (okay, even >> TMG would consider that a very irregular date). How would your >> software treat something that output such as "<date>....</date>", vs >> "<date><month>...</month><day>...</day><year>...</year></date>" >> >> Besides... I'm buying the software to handle the genealogical data >> and reporting... I'm not writing my own package in which I have the >> option of defining transforms into what I think should be used... >> Unless all the producers of said software all agree on what is valid >> data, commercial software will not be able to /losslessly/ accept the >> data of others. >> I really don't think there is much variation in the agreement of the actual "core" data.. but that means different things to different people, mainly those that are stuck on "names" for the data, etc. A person is a person, a date is a date. It all depends on where you are starting in your "relevancy" model as to what "extra" bits are attached to the core data. >> > >> > And should you be in a position (as I was) to need a third >> > application for the data that would have a somewhat different >> > output... you could then define your own schema and validate >> > against it. >> > >> How many weekend genealogists are going to even know what an XML >> transform is, much less write one to handle one source of data? >> They shouldn't have to. That's part of my point for having the software deal with it in meaningful & useful context. >> > So we don't need to perpetuate that by not providing a mechanism >> > that could facilitate automation, imo. >> >> Well, we could insist that all extant genealogy programs be modified >> to refuse to accept any data entry that doesn't have some sort of >> source citation, even if it is nothing more than "personal knowledge >> of <xyz>" -- >> Wulfraed Dennis Lee Bieber KD6MOG >> wlfraed@ix.netcom.com wulfraed@bestiaria.com >> HTTP://wlfraed.home.netcom.com/ >> (Bestiaria Support Staff: web-asst@bestiaria.com) >> HTTP://www.bestiaria.com/ > Refuse is pretty harsh/final. Give you an overview of the usage in the context of the sending schema, and allowing you and/or the software to automate (via xslt, etc) it's transformation is preferred. > XML is touted as some sort of panacea. It is an improvement on the > plethora of data formats (in all IT areas) that existed previously, > but it has to be understood for what it is. It is merely a > standardised syntax for representing hierarchical data. That > standardisation therefore only applies to the syntax, not to the > semantics. What this means, in layman speak, is that any XML file is > instantly recognisable as "XML" but it doesn't make the content any > more understandable. > > Sure, there are lots of tools for loading/viewing/manipulating XML but > they only know about the syntax, not the semantics. Yes, you can write > your only XSLT (which I have to say is an awful language) but all > those transformations would be doing is manipulating the syntax, e.g. > removing stuff, moving stuff around, extracting stuff, etc. In > principle, this would all be possible with any documented data format, > including GEDCOM, at the expense (& risk) of having to write a little > more of the necessary software yourself. > > I firmly believe that a "data model" has to be defined and accepted > first. This subject has come up several times in this group, and links > have been posted here about ongoing projects striving to achieve this. > Once such a data model specification exists then representation of it > in any data format (XML, GEDCOM, some other) is almost a mechanical > operation > I agree totally. Where I seem to differ with everyone else is that I think the "data model" has been discussed with a confused mixture of the actual data element definitions and the use of them in various heirarchies, as well as with differing attributes and expansions. I think once XML would be used as simply a transport (meaning at least a basic expandable core data set and (maybe) even a rough heirarchy defined), then extensions of the data set and differing heirarchies would emerge naturally. > Tony Proctor > > > I haven't really begun to evaluate it yet, but on the surface I think GenoPro may be on the right track. It lacks some traditional display concepts and needs work in possibly the research data organization and entry areas, but it appears to be a very flexible, extendable start I think. It's at http://www.genopro.com It's strength I think is in it's use of remapping data through "reports" into XML files as well as displays. I don't think it helps much with the schema & transforms, but I've only just installed the trial.

Tim Powys-Lybbe wrote: > In message of 25 Dec, Hugh Watkins <hugh.watkins@gmail.com> wrote: > > >>Kurt wrote: >> >>>"Head Geek" <headgeek@Kubuntu.local> wrote in message >>>news:J8Dbj.1615$nh7.315@trnddc01... >>> >>> >>>>Anyone aware of well-argued recommendations for how to cite census >>> >>>in >>> >>> >>>>GEDCOM SOUR structures? >>> >>> >>>Write them in the same form as references in scientific publications. >>> >>>The main point is that it must be possible for other persons to find >>>the source. >>> > > > Thoroughly agreed. Source references are no good unless they lead you > directly to finding the original or a secure copy, or even abstract, > thereof. > > A very Happy Xmas follows... > > >>the url of the image > > > URLs fade and lose their round ones. They are not secore it does not matter it is the true source of my data and a measure of the quality of the source to an infomed researcher mss and books get burned too >>and >> >>copy paste from the ancestry person page > > > I regret I can't follow this one! ============= search result after I got sent her marriage for the LAPHAM one-name study Exact Search Results - 1841 England Census You searched for Rhoda Brain View Record Name Estimated Birth Year Birthplace Civil Parish County/Island View Image View Record =========================== Person page or in ancestry-speak :- Rhoda Brain 1841 England Census Rhoda Brain Record Page =============== http://search.ancestry.co.uk/cgi-bin/sse.dll?indiv=1&db=uki1841%2c&rank=0&gsfn=rhoda&gsln=brain&sx=&gsco=&s0RealGL=UKICen&f1=&f2=&f5=&f18=&rg_81004011__date=&rs_81004011__date=0&f14=&f15=&_8000C002=&_80008002=&_80018002=&f7=&f8=&f9=&gskw=&prox=1&ti=5538&ti.si=0&gss=angs-d&pcat=UKICEN&fh=0&recid=1611885&recoff=1+2 1841 England Census about Rhoda Brain Name: Rhoda Brain Age: 25 Estimated Birth Year: abt 1816 Gender: Female Where born: Gloucestershire, England Civil Parish: Mangotsfield Hundred: Barton Regis County/Island: Gloucestershire Country: England Street address: MANGOTSFILED STREET << ADDED BY ME Registration district: Keynsham Sub-registration district: Oldland Neighbors: View others on page Household Members: Name Age Rhoda Brain 25 Wile Brain 1 Wm Brain 25 <<< GROCER View original image http://content.ancestry.co.uk/iexec?htx=view&r=5538&dbid=8978&iid=GLSHO107_377_378-0086&fn=Rhoda&ln=Brain&st=r&ssrc=&pid=2213082 Source Citation: Class: HO107; Piece 377; Book: 17; Civil Parish: Mangotsfield; County: Gloucestershire; Enumeration District: 5; Folio: 28; Page: 22; Line: 1; GSU roll: 288786. >> Source Information: Ancestry.com. 1841 England Census [database on-line]. Provo, UT, USA: The Generations Network, Inc., 2006. Original data: Census Returns of England and Wales, 1841. Kew, Surrey, England: The National Archives of the UK (TNA): Public Record Office (PRO), 1841. Data imaged from the National Archives, London, England. The National Archives gives no warranty as to the accuracy, completeness or fitness for the purpose of the information provided. Images may be used only for purposes of research, private study or education. Applications for any other use should be made to the National Archives, Kew, Richmond, Surrey TW9 4DU. Infringement of the above condition may result in legal action. << I don't bother with all this normally - taken as read regards Hugh W -- For genealogy and help with family and local history in Bristol and district http://groups.yahoo.com/group/Brycgstow/ http://snaps4.blogspot.com/ photographs and walks GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG

In message of 25 Dec, Hugh Watkins <hugh.watkins@gmail.com> wrote: > Kurt wrote: > > "Head Geek" <headgeek@Kubuntu.local> wrote in message > > news:J8Dbj.1615$nh7.315@trnddc01... > > > >>Anyone aware of well-argued recommendations for how to cite census > > > > in > > > >>GEDCOM SOUR structures? > > > > > > Write them in the same form as references in scientific publications. > > > > The main point is that it must be possible for other persons to find > > the source. > > Thoroughly agreed. Source references are no good unless they lead you directly to finding the original or a secure copy, or even abstract, thereof. A very Happy Xmas follows... > the url of the image URLs fade and lose their round ones. They are not secore > and > > copy paste from the ancestry person page I regret I can't follow this one! -- Tim Powys-Lybbe                                          tim@powys.org              For a miscellany of bygones: http://powys.org/

Kurt wrote: > "Head Geek" <headgeek@Kubuntu.local> wrote in message > news:J8Dbj.1615$nh7.315@trnddc01... > >>Anyone aware of well-argued recommendations for how to cite census > > in > >>GEDCOM SOUR structures? > > > Write them in the same form as references in scientific publications. > > The main point is that it must be possible for other persons to find > the source. > the url of the image and copy paste from the ancestry person page Hugh W -- For genealogy and help with family and local history in Bristol and district http://groups.yahoo.com/group/Brycgstow/ http://snaps4.blogspot.com/ photographs and walks GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG

"Head Geek" <headgeek@Kubuntu.local> wrote in message news:J8Dbj.1615$nh7.315@trnddc01... > Anyone aware of well-argued recommendations for how to cite census in > GEDCOM SOUR structures? Write them in the same form as references in scientific publications. The main point is that it must be possible for other persons to find the source. Kurt F

"Head Geek" <headgeek@Kubuntu.local> wrote in message news:J8Dbj.1615$nh7.315@trnddc01... > Anyone aware of well-argued recommendations for how to cite census in > GEDCOM SOUR structures? > Surely census data elements are no different from any other discovered data. The census data elements would be recorded respectively as AGE, BIRT, RESI, OCCU, etc.. Each of these would then reference the data source (the census record) with the normal tags of TITL, REPO, PAGE, QUAL, etc. If there are any other data from the census which do not fit the normal data fields for an individual, then these would be attached as NOTEs or custom EVENs at the individual record level, or to a subordinate data item as appropriate. Nigel www.tcgr.bufton.org

Hugh Watkins wrote: > Head Geek wrote: > >> Anyone aware of well-argued recommendations for how to cite census in >> GEDCOM SOUR structures? >> >> I've read Mills' PRINT suggestions, but print is not something I have >> any plans for. > > I just put it all in notes these days That's a recommendation, but I'm not sure it's "well-argued" > beter when uploaded to Worldconnect.rootysweb.com Ancestry says WorldConnect will remain as is when they rearrange everything else. But I don't trust them. I was taking my time to relocate; now I think I'll speed things up. -- Wes Groleau Pat's Polemics = http://Ideas.Lang-Learn.us/barrett

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message news:13mrvtst5hh523c@corp.supernews.com... > On Sun, 23 Dec 2007 04:33:37 GMT, JD <jd4x4@<del.this>verizon.net> > declaimed the following in soc.genealogy.computing: > > > > > I personally wouldn't want software that ignored something and didn't at > > least provide me with a means of dealing with it. But if it did, as you > > say it can be transformed with xslt, which is exactly what I did with my > > publishing source data. I had several sources each with slightly > > XSLT still requires a known source and destination format; it can't > take an unknown source tag and create a known destination tag with > meaning... Maybe it can produce some sort of blanket output for unknown > tags, but that will quite likely not be a reversible transformation. > > > differing source schemas, but all of the data was related and I created > > my own "final" schema from them, for the use I required. And, the > > You "created"... The software didn't derive a consistent schema... > > Who "creates" the schema and transforms for all the many programs > that currently exists? > > > > > See the above. The "standardization" you refer to doesn't mean that the > > data has been changed, only reordered.. to YOUR schema. Software doesn't > > have to do that alone. YOUR schema can be YOUR ordering of the data. > > > To me, said ordering requires prior knowledge of what the meaning of > various tags IS... What if "my" data considers "fourth flood of the > river <x> in the reign of <y>" to be acceptable as a date (okay, even > TMG would consider that a very irregular date). How would your software > treat something that output such as "<date>....</date>", vs > "<date><month>...</month><day>...</day><year>...</year></date>" > > Besides... I'm buying the software to handle the genealogical data > and reporting... I'm not writing my own package in which I have the > option of defining transforms into what I think should be used... Unless > all the producers of said software all agree on what is valid data, > commercial software will not be able to /losslessly/ accept the data of > others. > > > > > And should you be in a position (as I was) to need a third application > > for the data that would have a somewhat different output... you could > > then define your own schema and validate against it. > > > How many weekend genealogists are going to even know what an XML > transform is, much less write one to handle one source of data? > > > So we don't need to perpetuate that by not providing a mechanism that > > could facilitate automation, imo. > > Well, we could insist that all extant genealogy programs be modified > to refuse to accept any data entry that doesn't have some sort of source > citation, even if it is nothing more than "personal knowledge of <xyz>" > -- > Wulfraed Dennis Lee Bieber KD6MOG > wlfraed@ix.netcom.com wulfraed@bestiaria.com > HTTP://wlfraed.home.netcom.com/ > (Bestiaria Support Staff: web-asst@bestiaria.com) > HTTP://www.bestiaria.com/ XML is touted as some sort of panacea. It is an improvement on the plethora of data formats (in all IT areas) that existed previously, but it has to be understood for what it is. It is merely a standardised syntax for representing hierarchical data. That standardisation therefore only applies to the syntax, not to the semantics. What this means, in layman speak, is that any XML file is instantly recognisable as "XML" but it doesn't make the content any more understandable. Sure, there are lots of tools for loading/viewing/manipulating XML but they only know about the syntax, not the semantics. Yes, you can write your only XSLT (which I have to say is an awful language) but all those transformations would be doing is manipulating the syntax, e.g. removing stuff, moving stuff around, extracting stuff, etc. In principle, this would all be possible with any documented data format, including GEDCOM, at the expense (& risk) of having to write a little more of the necessary software yourself. I firmly believe that a "data model" has to be defined and accepted first. This subject has come up several times in this group, and links have been posted here about ongoing projects striving to achieve this. Once such a data model specification exists then representation of it in any data format (XML, GEDCOM, some other) is almost a mechanical operation Tony Proctor

Head Geek wrote: > Anyone aware of well-argued recommendations for how to cite census in > GEDCOM SOUR structures? > > I've read Mills' PRINT suggestions, but print is not something I have > any plans for. I just put it all in notes these days beter when uploaded to Worldconnect.rootysweb.com http://hughw36.blogspot.com/2007/12/happy-christmas-2007.html my Christmas card is our own tree decorated by my daughter in Copenhagen Denmark Hugh W -- For genealogy and help with family and local history in Bristol and district http://groups.yahoo.com/group/Brycgstow/ http://snaps4.blogspot.com/ photographs and walks GENEALOGE http://hughw36.blogspot.com/ MAIN BLOG

Anyone aware of well-argued recommendations for how to cite census in GEDCOM SOUR structures? I've read Mills' PRINT suggestions, but print is not something I have any plans for.