JD <jd4x4@ wrote: > Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: > > <snip> > >> BUT: with regards to genealogy, one has the problem of either some >>organization defining a "doctype" for use (having a "doctype" file >>defining the construct of a valid XML file allows for validation of XML >>files -- without using a custom validator; the validator read the >>defining doctype file and uses IT to validate the construct of the XML >>file), or one leaves it freely defined. >> >> But... more... if one is going to use a validating XML parser, and > > a > >>validation doctype supplied by some organization, one has the same >>problem as GEDCOM... It is quite likely that the doctype definition > > will > >>not support all features of the most complex programs (typically those >>of the event-based systems: the late Ultimate Family Tree and the > > living > >>The Master Genealogist) or will specify stuff not supported by the >>simpler programs (Family Tree Maker; from the GEDCOMs I've seen, >>practically any data item that is not a pure BMDB or relationship >>becomes a generic "fact" or "note"). >> >> Unvalidated XML would allow each program to define the structures >>that are best matches for its data... but will not be usable by other > > > Well, it's hard to remedy complex to simple data scenarios, but I don't > think it's impossible. At a minimum if a schema is agreed to that is a > "lowest common denominator", then evolution happens, and the defacto > common denominator gets extended naturally. As for "proprietary" > granularity, it's somewhat transparant by virtue of a schema with known > rules, and at least a minimum schema standard that requires a software > name & version. > > >>programs... How is a program that expects: >> >><date>mm/dd/yyyy</date> >> >>going to handle a file generated by a program that produces: >> >><date> >> <year>yyyy</year> >> <month>mm</month> >> <day>dd</dd> >></date> >> > Simply by "remapping" back & forth because the expected formats are > defined in each schema. We can even add an attribute that indicates the > calendar type without mucking things up. Don't forget 12 Thermidor XII when you're indicating calendar types; and don't miss the Hebrew and Hindu calendars which are lunar, or the occasional 13th month in the Hindu calendar or the difference between light 2nd and dark 2nd of the month and what's going to happen to the 2nd 14th of the month? Cheryl

JD <jd4x4@ wrote: > mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote: > > >>JD <jd4x4@<del.this>verizon.net> writes: >> >>>Ian Goddard <goddai01@hotmail.co.uk> wrote: >> >>>>In practice it seems that the GEDCOM type of model has >>>>influenced genealogical S/W to the extent that there doesn't >>>>seem to be any real advance on it. >>> >>>Again, one of the problems coming out of GEDCOM is that the DATA is >>>getting mixed with the model. The data is and will always be what it >>>is, right? The differences are in how we each use it and think of it, >>>imo. >> >>All this discussion is interesting (and we hope useful), but >>could there be some elaboration on the above points? It would >>seem that genealogical info describes a network of parents >>to/from children with nets spliced/joined by marriages. How >>does one "improve" on this "model"? >> > > > Not just this particular "model", because there are others that use the > same core data. I'm thinking that since many "data babies" get thrown > out with "genealogy", "family history", and who knows what other bath > water every day that goes by which baths are taken... that at least a > mechanism to capture and improve the data sets with machines is in > order. > > And, I see "XML" as being a help with that. Now, "XML" covers a LOT of > ground, not just a "data model", or a "standard", or even a "language".. > it's strength lies in smart use of it together in the correct > ever-expanding implementation of all of these aspects, imo. Data that's > taggged in at least a basic improved fashion every day could be of use. > Also, apps for genealogy should help with the exchanges and tagging at > least in the background (like in the date example & my scenario in the > previous post) if they were XML compliant. > > Hope this makes a little sense.. I'm late for a task & in a rush! The thing is, it doesn't explain what you're wanting it to if someone doesn't already know what you mean by what you say, if you see what I mean? Cheryl

mojaveg@mojaveg.lsan.mdsg-pacwest.com (Everett M. Greene) wrote: > JD <jd4x4@<del.this>verizon.net> writes: >> Ian Goddard <goddai01@hotmail.co.uk> wrote: > >> > In practice it seems that the GEDCOM type of model has >> > influenced genealogical S/W to the extent that there doesn't >> > seem to be any real advance on it. >> >> Again, one of the problems coming out of GEDCOM is that the DATA is >> getting mixed with the model. The data is and will always be what it >> is, right? The differences are in how we each use it and think of it, >> imo. > > All this discussion is interesting (and we hope useful), but > could there be some elaboration on the above points? It would > seem that genealogical info describes a network of parents > to/from children with nets spliced/joined by marriages. How > does one "improve" on this "model"? > Not just this particular "model", because there are others that use the same core data. I'm thinking that since many "data babies" get thrown out with "genealogy", "family history", and who knows what other bath water every day that goes by which baths are taken... that at least a mechanism to capture and improve the data sets with machines is in order. And, I see "XML" as being a help with that. Now, "XML" covers a LOT of ground, not just a "data model", or a "standard", or even a "language".. it's strength lies in smart use of it together in the correct ever-expanding implementation of all of these aspects, imo. Data that's taggged in at least a basic improved fashion every day could be of use. Also, apps for genealogy should help with the exchanges and tagging at least in the background (like in the date example & my scenario in the previous post) if they were XML compliant. Hope this makes a little sense.. I'm late for a task & in a rush!

Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote: <snip> > BUT: with regards to genealogy, one has the problem of either some > organization defining a "doctype" for use (having a "doctype" file > defining the construct of a valid XML file allows for validation of XML > files -- without using a custom validator; the validator read the > defining doctype file and uses IT to validate the construct of the XML > file), or one leaves it freely defined. > > But... more... if one is going to use a validating XML parser, and a > validation doctype supplied by some organization, one has the same > problem as GEDCOM... It is quite likely that the doctype definition will > not support all features of the most complex programs (typically those > of the event-based systems: the late Ultimate Family Tree and the living > The Master Genealogist) or will specify stuff not supported by the > simpler programs (Family Tree Maker; from the GEDCOMs I've seen, > practically any data item that is not a pure BMDB or relationship > becomes a generic "fact" or "note"). > > Unvalidated XML would allow each program to define the structures > that are best matches for its data... but will not be usable by other Well, it's hard to remedy complex to simple data scenarios, but I don't think it's impossible. At a minimum if a schema is agreed to that is a "lowest common denominator", then evolution happens, and the defacto common denominator gets extended naturally. As for "proprietary" granularity, it's somewhat transparant by virtue of a schema with known rules, and at least a minimum schema standard that requires a software name & version. > programs... How is a program that expects: > > <date>mm/dd/yyyy</date> > > going to handle a file generated by a program that produces: > > <date> > <year>yyyy</year> > <month>mm</month> > <day>dd</dd> > </date> > Simply by "remapping" back & forth because the expected formats are defined in each schema. We can even add an attribute that indicates the calendar type without mucking things up. >> standard (ie Microsoft), rather than >> a proper standard for all such as >> GEDCOM. >> >> So should not we avoid a proprietary >> standard? >> Yes, but more importantly I think we need to look at the actual data, and not build "trees" or other judgements into the DATA, other than in the form of a heirarchy (which can be changed without loss of data integrity if we think about it analytically, imo). >> >> >> Cheers, >> >> Tom [Tom Perrett] <tomp@st.net.au> >> >>

T.M. Sommers wrote: > > I fail to see any technological advantages of XML over GEDCOM. Their > syntax is different, but their semantics are essentially the same: both > are lists of trees. The advantage of XML is the range of tools it provides. Given an XMLT engine such as Saxon you could transform your XML output into HMLT by writing a suitable stylesheet. Or into FO for a pretty-printer report. Or into an SVG file for a diagram. > > The availability of parsing tools for XML is not a real advantage. You > still have to write the callbacks, and that is where most of the work > is. A GEDCOM line is trivial to parse: it is either LEVEL TAG DATA or > LEVEL XREF TAG. That's for a SAX parser. I've used the Woods SAX parser in Delphi. The handler and call-backs are small compared to the volume of code which is simply reused. That was some time ago. I've also used XMLT to transform the XML into a series of SQL statements which could be presented directly to RDMBS engine. If I were doing this now I'd also consider the possibility of using an engine which can parse the XML directly and load it into the database. > > GEDCOM allows users > to define their own tags, and I don't know if XML validating parsers can > handle that. > The main advantage of a validating parser is to prevent just that! In any thread about GEDCOM one usually finds complaints about limited inter-operability resulting from one package's not understanding anther's tags. One way to handle optional stuff like that in XML would be to use attributes, e.g. <OptionalData type="CauseOfDeath">Drowning</OptionalData> -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

JD <jd4x4@ wrote: > > http://www.genopro.com/ I had a quick look at the site. It's a Windows package so I'd need to find out if it runs under Wine. It looks as if it's essentially a graphical interface. I wonder how standard their symbology actually is. In the past I've used the class diagram facility of a UML package for diagramming family relationships, mostly because it was there and I could cobble up a diagram on it fairly quickly. A good UML package should be able to export data as XMI. So, If I were to put a little effort into setting up proper stereotypes.....hmmm. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

I am always in search of a better job. Check out http://www.2getemployment.com that I came across.Great resource site.I found the large job search section very useful.

JD <jd4x4@ wrote: > Ian Goddard <goddai01@hotmail.co.uk> wrote: > > >>JD <jd4x4@ wrote: >> >>>Having written the diatribe about XML, now I'm asking if anyone can >>>point me to either software apps, or utilities that use XML-compliant >>>file/schema which help deal with genealogy data? >>> >>>I'm not looking for format translators, but rather something that >>>uses an XML format file and is applicable to genealogy/family >>>history. >>> >>>Thanks. >>> >> >>I understand that Gramps at >>http://www.gramps-project.org/wiki/index.php?title=Main_Page used XML >>as its database format in earlier versions. It now uses RDBMS >>internally but will still import and export XML. >> >>This is more or less the pair of choices I'd have made for myself. I >>might not, however, have chosen Berkeley DB as the database as not >>only is it not SQL-based, it isn't, as I understand it, suitable for >>storing its data on networked drives. >> >>It's the package I use but it's still far from what I'd like to have >>available. >> > > > Ah, yes! Thanks Ian. I heard someone else mention it but never checked it > out! > > Check this link- if I understood your gggfather situation, I think it > would handle it, but it made me dizzy when I looked at it! (your > situation as well, but I really meant this software!). > > http://www.genopro.com/ you do in fact have two unconnected trees because you have no evidence of which is correct and without deeds or wills you may never know you may of course look for the descendacy of the other one your problem is of method pedigree has to end somewhere GIGO which is why family history is more fun 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

JD <jd4x4@<del.this>verizon.net> writes: > Ian Goddard <goddai01@hotmail.co.uk> wrote: > > In practice it seems that the GEDCOM type of model has > > influenced genealogical S/W to the extent that there doesn't > > seem to be any real advance on it. > > Again, one of the problems coming out of GEDCOM is that the DATA is > getting mixed with the model. The data is and will always be what it is, > right? The differences are in how we each use it and think of it, imo. All this discussion is interesting (and we hope useful), but could there be some elaboration on the above points? It would seem that genealogical info describes a network of parents to/from children with nets spliced/joined by marriages. How does one "improve" on this "model"?

Ian Goddard wrote: > > Let me give you an example of what I mean by ambiguities. I would have > no problems in getting GEDCOM to represent my ggg-father and his > descendants. However when I come to his ancestry I have a problem. I > know his father's name, the date of his burial and his age at death. I > know his mother's name, the date of her burial but not her age at death. > I have a copy of the registry record of their marriage. However there > are two individuals of the same name as the father born in the same year > and his age and date of death do not enable me to separate them so > either of these children are candidates. What's more, for one of these > children there were two individuals of the appropriate name and > generation to have been his father. In other words I have three > possible lines to take my ggg-father back two generations. Except I > don't - I have six because there are also two individuals with the same > name as the mother. Admittedly one was somewhat young but not > impossibly so. As far as I'm aware the nearest that GEDCOM could come > to representing this would be as a set of unlinked genealogical > fragments, one starting my gggg-parents marriage and working forwards, > three others representing the alternative lines for my gggg-father and > two representing the alternative lines of my gggg-mother. Take a look at the ASSO structure (p. 29 of the 5.5 document). You can use it to represent any type of relationship, such as possible father/son/spouse/whatever. Just because your software doesn't use it doesn't mean GEDCOM doesn't have it. -- Thomas M. Sommers -- tms@nj.net -- AB2SB

Ian Goddard wrote: > There are several distinct issues here: > > 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. Take a look at LifeLines (http://lifelines.sourceforge.net/). I haven't looked at the internals, but it stores GEDCOM in some sort of database. > 4. GEDCOM as a data exchange format. > This is a more appropriate application as scalability would not be an > issue. I should hope so, since that is what it was designed for. > The parsing requirements remain, however. Any kind of data exchange format will have to be parsed. > 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. I fail to see any technological advantages of XML over GEDCOM. Their syntax is different, but their semantics are essentially the same: both are lists of trees. The availability of parsing tools for XML is not a real advantage. You still have to write the callbacks, and that is where most of the work is. A GEDCOM line is trivial to parse: it is either LEVEL TAG DATA or LEVEL XREF TAG. Validating parsers might be an advantage of XML, but GEDCOM allows users to define their own tags, and I don't know if XML validating parsers can handle that. -- Thomas M. Sommers -- tms@nj.net -- AB2SB

Ian Goddard <goddai01@hotmail.co.uk> wrote: > JD <jd4x4@ wrote: >> Having written the diatribe about XML, now I'm asking if anyone can >> point me to either software apps, or utilities that use XML-compliant >> file/schema which help deal with genealogy data? >> >> I'm not looking for format translators, but rather something that >> uses an XML format file and is applicable to genealogy/family >> history. >> >> Thanks. >> > I understand that Gramps at > http://www.gramps-project.org/wiki/index.php?title=Main_Page used XML > as its database format in earlier versions. It now uses RDBMS > internally but will still import and export XML. > > This is more or less the pair of choices I'd have made for myself. I > might not, however, have chosen Berkeley DB as the database as not > only is it not SQL-based, it isn't, as I understand it, suitable for > storing its data on networked drives. > > It's the package I use but it's still far from what I'd like to have > available. > Ah, yes! Thanks Ian. I heard someone else mention it but never checked it out! Check this link- if I understood your gggfather situation, I think it would handle it, but it made me dizzy when I looked at it! (your situation as well, but I really meant this software!). http://www.genopro.com/

Ian Goddard <goddai01@hotmail.co.uk> wrote: > Tom Perrett wrote: > >> >> I thought that XML was a proprietary >> standard (ie Microsoft), > <snip> > > In theory this limitation of GEDCOM doesn't prevent someone from > writing a program to represent things in a better way (it might be on > my list of things to do but it never seems to get near the top!). > Such a program would need a data model capable of maintaining > alternative links, maybe attaching a measure of confidence to each. > In fact, as I've written in Well, it's not the DATA model that has a problem, rather it's the fact that there is (possibly) an implied relationship muddled into the gedcom file format, and perpetuated by a traditional software display that only allows tree/family views. GEDCOM allows for a source record to be related to any of the actual data items as well as a surity level if I'm not mistaken, but regardless you simply don't have a suitable display in existing software for the condition. > another post, we don't even need a program to represent this - it can > be done with file cards and paper clips - and nobody has responded to > my challenge to name a package which can emulate this. But if you and > I I may have found one in my XML quest... http://www.genopro.com/ I don't know just yet if it supports XML, but it may just display the situation you described (if I understood it correctly!). And, if it did support an XML schema, I'd bet that the actual DATA it uses would likely overlap with genealogy and family history data. Note that I said overlap.. maybe more, maybe less, but overlap. > had such a program and it were confined to GEDCOM as a means of data > interchange it would be quite cumbersome to transfer such data from my > program to yours. My program would have to throw away the information > describing the ambiguities in order to write a GEDCOM. Your program Yes it would. Which is fine if that's all I need, isn't it? > would then be able to import that but we would need to find some other > way of communicating the missing information so that you could enter > it Unless I was using at least the same DATA granularity as you. Even if I used it for something else, XML would let me call it what I like. And if my use built upon your data (I needed it to be more granular) I'd be adding data anyhow. And, it wouldn't impact the integrity of your data set because if it didn't match your schema (rules) you'd know it because you'd have a different schema when I give it to you, or it would be remapped to your schema. The rules and mapping are usually handled in software so it sounds worse than it really is. > by hand. In practice it seems that the GEDCOM type of model has > influenced genealogical S/W to the extent that there doesn't seem to > be any real advance on it. Again, one of the problems coming out of GEDCOM is that the DATA is getting mixed with the model. The data is and will always be what it is, right? The differences are in how we each use it and think of it, imo. >

On Mon, 17 Dec 2007 16:07:28 -0600, Steve W. Jackson wrote: >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 Thanks Ian and Steve for the clarification for "lazy bones". Comforting to know it is a language in its own right. Cheers, Tom [Tom Perrett] <tomp@st.net.au>

JD <jd4x4@ wrote: > Having written the diatribe about XML, now I'm asking if anyone can point > me to either software apps, or utilities that use XML-compliant file/schema > which help deal with genealogy data? > > I'm not looking for format translators, but rather something that uses an > XML format file and is applicable to genealogy/family history. > > Thanks. > I understand that Gramps at http://www.gramps-project.org/wiki/index.php?title=Main_Page used XML as its database format in earlier versions. It now uses RDBMS internally but will still import and export XML. This is more or less the pair of choices I'd have made for myself. I might not, however, have chosen Berkeley DB as the database as not only is it not SQL-based, it isn't, as I understand it, suitable for storing its data on networked drives. It's the package I use but it's still far from what I'd like to have available. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

"Steve W. Jackson" <stevewjackson@knology.net> wrote: > 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 Well, at least one that could read a schema and fit the data into it's own "slots" and/or ask the user how to map it to do so or discard it. Then be able to export the native data to an XML compliant file & schema. I just keep thinking that now the actual data is muddled in with relationship logic and categorization labels due either to software or user preferences, and that XML could help start to clear some of that up. Even if the schema was a direct match for GEDCOM 5.5 or something even more crude as a base minimum, XML would allow for more granular data but at the same time backward compatability. > 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. > Funny how that works & is so hard to explain, eh? :-) > = Steve =

Tom Perrett wrote: > > I thought that XML was a proprietary > standard (ie Microsoft), Emphatically not. This is its home: http://www.w3.org/XML/ However, it's not a standard about genealogy or any other subject area. It's a set of general purpose standards and technologies. Using these standards and technologies it's possible to specify how data for some application area be represented. However before specifying such an application-specific standard one has to work out a data model. > rather than a proper standard for all such as GEDCOM. This is the crux of the problem. GEDCOM isn't "a proper standard for all". It's a file format designed for one particular purpose, the transfer of material into and out of LDS databases. Its data model is adequate for that. In fact, it includes a component which exists specifically to support LDS beliefs. On the other hand it doesn't provide anything to support situations where one has ambiguities in the data. Let me give you an example of what I mean by ambiguities. I would have no problems in getting GEDCOM to represent my ggg-father and his descendants. However when I come to his ancestry I have a problem. I know his father's name, the date of his burial and his age at death. I know his mother's name, the date of her burial but not her age at death. I have a copy of the registry record of their marriage. However there are two individuals of the same name as the father born in the same year and his age and date of death do not enable me to separate them so either of these children are candidates. What's more, for one of these children there were two individuals of the appropriate name and generation to have been his father. In other words I have three possible lines to take my ggg-father back two generations. Except I don't - I have six because there are also two individuals with the same name as the mother. Admittedly one was somewhat young but not impossibly so. As far as I'm aware the nearest that GEDCOM could come to representing this would be as a set of unlinked genealogical fragments, one starting my gggg-parents marriage and working forwards, three others representing the alternative lines for my gggg-father and two representing the alternative lines of my gggg-mother. In theory this limitation of GEDCOM doesn't prevent someone from writing a program to represent things in a better way (it might be on my list of things to do but it never seems to get near the top!). Such a program would need a data model capable of maintaining alternative links, maybe attaching a measure of confidence to each. In fact, as I've written in another post, we don't even need a program to represent this - it can be done with file cards and paper clips - and nobody has responded to my challenge to name a package which can emulate this. But if you and I had such a program and it were confined to GEDCOM as a means of data interchange it would be quite cumbersome to transfer such data from my program to yours. My program would have to throw away the information describing the ambiguities in order to write a GEDCOM. Your program would then be able to import that but we would need to find some other way of communicating the missing information so that you could enter it by hand. In practice it seems that the GEDCOM type of model has influenced genealogical S/W to the extent that there doesn't seem to be any real advance on it. -- Ian Hotmail is for spammers. Real mail address is igoddard at nildram co uk

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>

Having written the diatribe about XML, now I'm asking if anyone can point me to either software apps, or utilities that use XML-compliant file/schema which help deal with genealogy data? I'm not looking for format translators, but rather something that uses an XML format file and is applicable to genealogy/family history. Thanks.

Total personal opinion follows: Many years ago I read that business avoided SGML/XML for a variety of reasons, not the least of which was complexity vs. benefit. The same article said that after some time, those that worked with a structured language became enthusiastic advocates. I read the article because I was forced (another reason it's avoided) to deal with data that was in SGML format and I was trying to figure out how to publish printed material with it so I was trying to understand it. After some years of dealing with the SGML source, it became XML that I was forced to deal with. To this day I still wouldn't call myself anywhere near an expert but I'm enough of an SGML/XML "hack" that I can deal with it, and I'm now an ML zealot. There is only one reason I can see NOT to use XML, and that's because there are not any software apps or utilities related to genealogy/family history that benefit large user groups in their daily activity. Meanwhile imo, it's a shame because since people continue to manually add, edit, verify, and otherwise add value (or reduce it!) to genealogy/family history data in their daily activities, a lot of duplication of effort exists. Since XML is an extensible format, data and applications that use it keep getting better and easier. Imo if software did nothing more than become XML-compliant in reading (any) schema, and wrote to a schema that duplicated GEDCOM 5.5 we would be on the road to a good solution for a HUGE number of people in a variety of genealogy/family history efforts.