"J. P. Gilliver (John)" <[email protected]> wrote in message news:[email protected] > In message <[email protected]>, Ian Goddard > <[email protected]> writes: > [dates] >>We need to be careful here as the ISO standard not only covers date >>formats, it also mandates the Gregorian calendar with provision for >>extending it back beyond its starting date. This, however, is > > I suppose I shouldn't have said the ISO format, just year-month-date. > [] >>ISO format still doesn't help anyone not familiar with it to work out >>which part is the month. 1960-04-23 is clear enough, 1960-04-01 is still >>ambiguous. My practice when writing up is to give months as letters, e.g. >>23 Apr 1960 with leading zeros for the single digit days - but only when I >>remember :o . Having said that I have Informix, > > Me too - well, I say 1960-4-23 or 1960-04-23, but if before the 13th > (except on e. g. 7/7!), I say 1960-Apr-1. > > I agree it's still unclear to anyone unfamiliar with it: my main reason > (as well as computer sorting reasons) for using it, in everyday life as > well as genealogy, is that year-first (I _always_ use four-digit) is > sufficiently unfamiliar to most people that I hope it makes them stop and > check anyway. (If it's a short note where it isn't clear, I do use the > month-as-letters form.) > > _Is_ the form yyyy-dd-mm actually in use anywhere? > [] >>> Places > [] >>There's a problem here in that there are multiple schemes for dividing up >>the country. And I don't just mean boundary changes. At the same time a >>given place could belong to a parish, a township and a manor. I > [] >>Upperthong geographically. This is multi-dimensional data and there's no >>easy way to deal with it. > > Indeed. > [] >>If you're recording this in genealogical software there seems to be an >>assumption that we live in cities. I suspect genealogical S/W writers >>have simply taken over what seem to be US postal address schemas in which >>they are not alone as a good deal of on-line shops, even those in the UK, >>seem to do the same. In practice, therefore, I find myself having to use >>the city field for the township. > > In the part you'd snipped, I think I referred to the field below > country-subdivision as "village/town"; I certainly agree that the > assumption (at least as far as titling the field goes) that we all live in > cities is irritating. Of course, in genealogy, once you go back a century > or two, a lot didn't even live in villages, though I suppose they came > under the local village/parish/whatever for administrative purposes. > [] >>Ideally S/W should allow you to record the name exactly as found and to >>have a standard form so if, for instance the township is written Overthong >>or Overthwonge or whatever you should be able to record this but still be >>able to refer it to a standard record with the modern standard spelling of >>Upperthong. Incidentally, until fairly recently > > Agreed. > [names] >>IMV good genealogical S/W would keep the name as spelled with the record >>where it was spelled, not just as a floating alternative name and allow >>you to have a standard name for the person with some sort of epithet to >>distinguish it from some other person of the same name, e.g William >>Goddard II, John Goddard of Scholes etc. >> > Not totally unlike the placenames I suppose. > > > Basically, this is all good discussion: I started it because the thread > with GENI in the title made we think that someone was possibly about to > start on the hobby, and I thought they (and anyone else in a similar > position) would benefit from thinking hard, before they started, about > what form they were going to store at least dates and placenames in, > because some thought before starting is likely to save much time later. I > hoped it would provoke debate as well, which it has, good; it's branched > into discussion of what good g. software should offer in these respects, > which is also good, as long as the original point isn't obscured too much. > (I appeal to people to consider changing the thread title where > appropriate.) > -- > J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)[email protected]+Sh0!:`)DNAf > > `Computers are useless. They can only give you answers.' Pablo Picasso, > 1968 A computer should never be called upon to sort a date string expressed with year, month, and day components - irrespective of the order of those components John. A major point I was making above is that y/m/d, d-m-y, etc., etc., are all "external representations" designed for humans. If a computer program is asked to sort such data as simple text then it has been badly designed and will always fail at some point. Those external representations would be known to the UI part of the program such that when you enter dates then it knows which representation you were using, and also the degree of uncertainty (e.g. +/- a day, or +/- a year). It can then compile them into an "internal" integer representation which can be sorted, collated, and analysed efficiently and with no ambiguity. This is true whether you're using Gregorian, Julian, Chinese, or whatever dates.What you originally entered can still be used in your reports and charts but it's designed for humans, not computer software. [For anyone with a computer background, this point is analogous to the source code for a computer program. A human writes it, say, in Java and that gets compiled into the binary code that the computer itself understands. The original source code is retained as the compilation process is not generally reversible] The principle is also true of time-zones. If someone was born on 9-June in the US and someone else on 9-June in UK then they aren't necessarily the same day and should not collate as equals. Once those dates are compiled into the internal format then the distinction is no longer applicable and the computer treats all compiled dates in the same fashion. Tony Proctor

On Mon, 08 Aug 2011 21:08:57 +0200, Steve Hayes <[email protected]> wrote: >Thanks very much for checking. Perhaps it was Avast, if people with other AV >software didn't have the problem. I use MBAM and it didn't react to my request this morning. Did Avast block the website in general or the specific file you were downloading? -- Dennis

I belong to a number of genealogy mailing lists hosted by YahooGroups, which also have facilities for exchanging files, posting photos, links etc. Yesterday my wife tried to download a file from one of these, and her anti-virus program (Avast) had a hissy fit about a malicious site. I checked on my machine, and the same thing happened, which has never happened before. I noticed that if one clicked on the link to a file, one was redirected to another site, called "yahoofs", which looks like a spoof of Yahoo. I've blogged about it here: http://hayesgreene.blogspot.com/2011/08/yahoo-hacked-warning.html and have asked Yahoo about it, but have heard nothing from them or anyone else. It is a common trick used by phishermen and other malicious sites to display one address and then when you click on it takes you to another site, and that seems to be what is happening in this case. I'd be grateful if any experienced computer fundis could check it out, and let me know if they also have this problem, and also if other antivirus software reacts to this in the same way as Avast. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

On Mon, 08 Aug 2011 12:42:03 +0200, Steve Hayes <[email protected]> wrote: >I belong to a number of genealogy mailing lists hosted by YahooGroups, which >also have facilities for exchanging files, posting photos, links etc. > >Yesterday my wife tried to download a file from one of these, and her >anti-virus program (Avast) had a hissy fit about a malicious site. > >I checked on my machine, and the same thing happened, which has never happened >before. > >I noticed that if one clicked on the link to a file, one was redirected to >another site, called "yahoofs", which looks like a spoof of Yahoo. > >I've blogged about it here: > >http://hayesgreene.blogspot.com/2011/08/yahoo-hacked-warning.html > >and have asked Yahoo about it, but have heard nothing from them or anyone >else. It is a common trick used by phishermen and other malicious sites to >display one address and then when you click on it takes you to another site, >and that seems to be what is happening in this case. > >I'd be grateful if any experienced computer fundis could check it out, and let >me know if they also have this problem, and also if other antivirus software >reacts to this in the same way as Avast. I have one file posted in a Yahoo group that I run. When I hover over the link I get... http://f1.grp.yahoofs.com/v1/sME_TnHR2Rlpk_YbuC627FmgdZnZA7dsA-su3d6Fj-3F-v295Y_Yn8pA7_-0sldCe5j1QxZagGE1Sio20dTKwg/vbaPrettyDate.txt Clicking on it sends me to the file that I posted. So it looks alright to me. 'whois' says the registrant is Yahoo. Maybe "yahoofs" means "Yahoo File Server" or something like that? Could Avast be giving you a false positive? -- Dennis

On 2011-08-07, singhals <[email protected]> wrote: > ... > > Meanwhile a few years back my ISP quit offering usenet; I > haven't had the energy to dig up another source. About that > time, Yahoogroups started up, and FamilySearch's family > discussions got traction, and yes, mid-Jun to early > September is historically slow on usenet as colleges empty, > and other folks take vacations. > > ... In case it might be of help getting connected back up with Usenet, there are a bunch of free and non-free news services to choose from. I have had very good luck with (new.)individual.net, and I have heard others speak highly of several others. A scan of the archives of alt.online-service.verizon should yield a bunch of info. -- Robert Riches [email protected] (Yes, that is one of my email addresses.)

On 08-07-2011 15:32, Charles Ellson wrote: > On Sun, 07 Aug 2011 11:11:37 +0100, Ian Goddard >> And, of course, a good genealogical dating system shouldn't blink if >> given a date such as June 31 if that's what the original document said. >> It should just quietly collate it between June 30 and July 1. >> > It should at the least ask "are you sure?" even if it still accepts it > but even then ought to have some kind of flag to indicate that the > information is anomolous. I wish some systems wouldn't take so literally GEDCOM's dictates that a month without a year is not a date. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On 08-07-2011 05:51, Ian Goddard wrote: > I'll cross-post this to s.g.c to reassure Wes that some of us are still > alive... I didn't figure anyone had died. It was just the total silence for a couple of weeks when the flame wars on other groups show no signs of let up. PLUS the fact that my first test post never appeared in the feed coming back. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

Charles Ellson wrote: > On Sun, 07 Aug 2011 11:11:37 +0100, Ian Goddard > <[email protected]> wrote: >> And, of course, a good genealogical dating system shouldn't blink if >> given a date such as June 31 if that's what the original document said. >> It should just quietly collate it between June 30 and July 1. >> > It should at the least ask "are you sure?" even if it still accepts it > but even then ought to have some kind of flag to indicate that the > information is anomolous. Actually I was just thinking about the indexing mechanism in the background which doesn't talk to the user directly. But you're right, of course; the front end should challenge the user in such a situation. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On Sun, 07 Aug 2011 11:11:37 +0100, Ian Goddard <[email protected]> wrote: >Tony Proctor wrote: >> "Ian Goddard" <[email protected]> wrote in message >> news:[email protected] >>> Tony Proctor wrote: >>>> "Ian Goddard" <[email protected]> wrote in message >>>> news:[email protected] >>>>> Tony Proctor wrote: >>>>>> ISO 8601 is definitely good John, if you know the date. As a software >>>>>> architect I was always surprised how few companies - particularly in >>>>>> the US - were aware of it. >>>>> Actually it's a problem when used for genealogy. It mandates Gregorian. >>>>> Once you get back to 1752 (in UK & colonies) dates in sources will be >>>>> given in Julian. If you adhere to the standard you'll have to convert >>>>> them to Gregorian which will confuse anyone comparing your data with the >>>>> sources. >>>>> >>>>>> However, in genealogy - and historical data in general - the date is >>>>>> not always known exactly. As you point out, you may know the 'quarter', >>>>>> say for a registration (as opposed to the BMD event itself), or you may >>>>>> know the month of an event but not the day. You might similarly know >>>>>> the decade (e.g. 1950's) or the century (e.g. 1800's). >>>>>> >>>>>> Any product for storing or representing such data would therefore have >>>>>> to consider arbitrary degrees of uncertainty and to be able to store >>>>>> what you know without having to 'bend the rules' or somehow cheat the >>>>>> product. I did spend some time researching into the development of a >>>>>> 'universal object model' (I won't elaborate - unless asked - but this >>>>>> isn't the same as a storage format or database design) for representing >>>>>> historical data but the paid job got in the way. > >>>>> OK, consider yourself asked! It's something I've given the occasional >>>>> thought to without coming to any useful conclusion. It would be >>>>> straightforward enough to have a date class with subclasses for Julian, >>>>> Gregorian, Britain and colonies etc. But when I considered the >>>>> possibility of devising a data type for object relational databases such >>>>> as Informix or Postgres the need for comparison code crops up. How do >>>>> you collate 01 Jun 1810, 1810, "first quarter of C19th" and "early >>>>> C19th"? >>>>> >>>>> -- >>>>> Ian >>>>> >>>>> The Hotmail address is my spam-bin. Real mail address is iang >>>>> at austonley org uk >>>> SQL databases have made a complete pig's ear of date/time support Ian. >>>> They fail to acknowledge the different between a point in time >>>> (technically called a 'timestamp') and a calendar or clock marker (e.g. a >>>> d.o.b or a wake-up time). The first is independent of any time-zone >>>> change and also independent of any particular date/time representation. >>>> It would normally be stored as an offset - say in milliseconds - from >>>> some absolute (apologies to Einstein there) epoch. The latter would need >>>> to store the elements of the date/time separately (e.g. y/m/d) and >>>> time-zones would not be applicable to it. >>> If I've followed you correctly it looks as if Postgresql provides both: >>> (see http://www.postgresql.org/docs/8.4/static/datatype-datetime.html ) in >>> that it allows for timestamps with and without timezone although it keeps >>> both as an offset time. >>> >>> In addition both Informix and Postgresql provide for user-defined types so >>> it would be perfectly possible to create a data type storing each element >>> separately. Providing, of course, subtracting July from August doesn't >>> give January as a result ;) In other words ensure that you use interval >>> types as required. >>> >>> However I think this is the least of our worries compared to calendar >>> issues and the imprecision of some sources. >>> >>>> Anyway, no relational database that I'm aware of has a single data-type >>>> that could be used for all the cases required in genealogy. It would have >>>> to be some clever composite. >>>> >>>> An object model, though, is a run-time representation of the data rather >>>> than a stored format. If such a standard model existed then it could >>>> allow interoperability between products without mandating a particular >>>> database or storage format. Good news if you want the option of moving >>>> your data between products, or of picking-and-choosing some analysis or >>>> reporting product without changing your database. In effect, it would >>>> allow the software products to specialise as either >>>> database/storage/query or reporting/analysis. Well, that's the theory >>>> although I can't see it happening any time soon. As is usually the case, >>>> vendors want complete control over everything. Standards like that come >>>> too late, if at all. >>>> >>>> Such a model might allow an analysis product to contrast/compare two >>>> different databases, e.g. yours and someone else's. It might also be >>>> applicable to 'cloud computing' (depending on its design) where you could >>>> publish your data in a shared location and allow various disparate >>>> products to access it, subject to security controls of course. > >>> The runtime format can't be cleanly unpicked from storage however. Queries >>> and reporting both need to have workable collating sequences. If you >>> search, for instance, for data with a date between 01 Jan 1810 and 31 Dec >>> 1810 do you return data where the date was simply given and first quarter >>> of the C19th? And where, in a sorted report, do you include something >>> with that sort of date? But a genealogical system would need to handle >>> that sort of material presented at runtime and to be able to store it >>> usefully. >>> >>> -- >>> Ian >>> >>> The Hotmail address is my spam-bin. Real mail address is iang >>> at austonley org uk >> >> With dates in particular Ian, there's a lot that can be done. For instance, >> irrespective of the representation of a date, or the calendar being used >> (e.g. Gregorian, Julian), a date can be compiled into a timestamp which >> would be a simple "long integer" that relational databases excel at using >> for queries. The original representation of the date would probably need to >> be stored for viewing/editing purposes but the database would work from the >> compiled version for both unambiguity and efficiency. >> >> Given that all historical dates have some degree of uncertainty, they all >> implicitly represent an interval. For instance, the start/end of a day, or >> quarter, or year, etc. Hence, any attempt to correlate dates should always >> treat them as potentially-overlapping intervals. > >With a date type as opposed to a date-time type a date is atomic, of course. > >To go back to my original thoughts on coding comparisons for many cases >it's possible providing the S/W doesn't get thrown by situations such as: > >A = B >A = C >B < C > >(A is a lower resolution data such as 1810 and B and C are higher >resolution dates such as Jan 1810 and 23 Apr 1810) > >The real problem is in the vaguer dates such as the catalogued date of >early C14th I've seen given for a document although I suspect it to be >earlier than one which gave itself an exact date in (IIRC) 1295. > >And, of course, a good genealogical dating system shouldn't blink if >given a date such as June 31 if that's what the original document said. > It should just quietly collate it between June 30 and July 1. > It should at the least ask "are you sure?" even if it still accepts it but even then ought to have some kind of flag to indicate that the information is anomolous.

On Sat, 06 Aug 2011 23:37:20 -0400, Wes Groleau <[email protected]> wrote: >Well, I just noticed that every genealogy group in my list has been >completely empty for many weeks, until this. And the first "hello" >I posted today to a different group never appeared. > >Meanwhile all of the non-genealogy groups I visit have continued to >contain the sort of insanity Usenet is known for. > >-- >Wes Groleau I blame two events - the proliferation of data on Internet as discussed by others and Google problems. One user group that usually has 200-400 posts per day had 16 today, 20-something yesterday and not many more for several days. Hugh

In message <[email protected]>, Ian Goddard <[email protected]> writes: [dates] >We need to be careful here as the ISO standard not only covers date >formats, it also mandates the Gregorian calendar with provision for >extending it back beyond its starting date. This, however, is I suppose I shouldn't have said the ISO format, just year-month-date. [] >ISO format still doesn't help anyone not familiar with it to work out >which part is the month. 1960-04-23 is clear enough, 1960-04-01 is >still ambiguous. My practice when writing up is to give months as >letters, e.g. 23 Apr 1960 with leading zeros for the single digit days >- but only when I remember :o . Having said that I have Informix, Me too - well, I say 1960-4-23 or 1960-04-23, but if before the 13th (except on e. g. 7/7!), I say 1960-Apr-1. I agree it's still unclear to anyone unfamiliar with it: my main reason (as well as computer sorting reasons) for using it, in everyday life as well as genealogy, is that year-first (I _always_ use four-digit) is sufficiently unfamiliar to most people that I hope it makes them stop and check anyway. (If it's a short note where it isn't clear, I do use the month-as-letters form.) _Is_ the form yyyy-dd-mm actually in use anywhere? [] >> Places [] >There's a problem here in that there are multiple schemes for dividing >up the country. And I don't just mean boundary changes. At the same >time a given place could belong to a parish, a township and a manor. I [] >Upperthong geographically. This is multi-dimensional data and there's >no easy way to deal with it. Indeed. [] >If you're recording this in genealogical software there seems to be an >assumption that we live in cities. I suspect genealogical S/W writers >have simply taken over what seem to be US postal address schemas in >which they are not alone as a good deal of on-line shops, even those in >the UK, seem to do the same. In practice, therefore, I find myself >having to use the city field for the township. In the part you'd snipped, I think I referred to the field below country-subdivision as "village/town"; I certainly agree that the assumption (at least as far as titling the field goes) that we all live in cities is irritating. Of course, in genealogy, once you go back a century or two, a lot didn't even live in villages, though I suppose they came under the local village/parish/whatever for administrative purposes. [] >Ideally S/W should allow you to record the name exactly as found and to >have a standard form so if, for instance the township is written >Overthong or Overthwonge or whatever you should be able to record this >but still be able to refer it to a standard record with the modern >standard spelling of Upperthong. Incidentally, until fairly recently Agreed. [names] >IMV good genealogical S/W would keep the name as spelled with the >record where it was spelled, not just as a floating alternative name >and allow you to have a standard name for the person with some sort of >epithet to distinguish it from some other person of the same name, e.g >William Goddard II, John Goddard of Scholes etc. > Not totally unlike the placenames I suppose. Basically, this is all good discussion: I started it because the thread with GENI in the title made we think that someone was possibly about to start on the hobby, and I thought they (and anyone else in a similar position) would benefit from thinking hard, before they started, about what form they were going to store at least dates and placenames in, because some thought before starting is likely to save much time later. I hoped it would provoke debate as well, which it has, good; it's branched into discussion of what good g. software should offer in these respects, which is also good, as long as the original point isn't obscured too much. (I appeal to people to consider changing the thread title where appropriate.) -- J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)[email protected]+Sh0!:`)DNAf `Computers are useless. They can only give you answers.' Pablo Picasso, 1968

J. P. Gilliver (John) wrote: > Basically, this is all good discussion: I started it because the thread > with GENI in the title made we think that someone was possibly about to > start on the hobby, and I thought they (and anyone else in a similar > position) would benefit from thinking hard, before they started, about > what form they were going to store at least dates and placenames in, > because some thought before starting is likely to save much time later. > I hoped it would provoke debate as well, which it has, good; it's > branched into discussion of what good g. software should offer in these > respects, which is also good, as long as the original point isn't > obscured too much. (I appeal to people to consider changing the thread > title where appropriate.) The underlying problem with thinking it through first lies in the lack of knowledge on the part of the average beginner. The beginner on the West Coast of the Atlantic generally doesn't know that he will eventually need to know exactly when each country changed calendar formats (in fact, a good chunk of them don't know countries DID change calendar formats); more large cohorts of genie searchers don't use computers in their day-job and don't realize that April 25 will sort before January 25 (and non-IT types might not even recognize "sort" as being important). By the time you've the experience to know it matters, it's too late. Worse, no matter how long one spends building the "perfect" data model, some ya-hoo will come along and bollix it up for you. I've found Quaker documents where the fifteenth day of the fourth month was counted from the day the meeting was organized, which made this MM minutes out-of-sync with the neighboring MMs who both used the then-current calendar's "first" month. Non-standard, atypical, but all there is for that MM and one or two others I've seen. Cheryl

There have been posts about Mr Google not behaving very good. I don't use Mr G but still have had limited number of posts. A couple of quotes: A lot of listers also have facebook, maybe they are busy with that. Its been the same on most lists for a couple of years now. Barb You could be right Barbara, I have a FB Group that has been rather busy of late. (Australian Genealogy) Carolyn People don't have to ask these days for look ups, as in the past - so much is on line courtesy of Google, Ancestry, the various state archives, cemeteries and so on. All the lists I'm on have slowed down to almost nothing, whereas 12 years ago when I started family research, my Inbox was bursting every day. My thoughts anyway. Denise I'm inclined to agree with Denise - and add that whereas in the past we relied on each other for assistance and advice, these days the sites such as ancestry mean we no longer have to get other people involved - we don't have to mingle - we don't have to share anything - we just get on with it - in isolation - .which is pretty sad really - (snipped remainder) cheers Robert It has been suggested that people are going over to Facebook. I don't like Facebook so won't be going there. Di "Wes Groleau" <[email protected]> wrote in message news:[email protected] > Has genealogy been declared illegal, > or did I somehow screw up my killfile? > > -- > Wes Groleau > > There are two types of people in the world . > http://Ideas.Lang-Learn.us/barrett?itemid=1157

Bob Melson wrote: > On Saturday 06 August 2011 21:37, Wes Groleau ([email protected]) > opined: > <snip> >> Well, I just noticed that every genealogy group in my list has been >> completely empty for many weeks, until this. And the first "hello" >> I posted today to a different group never appeared. >> >> Meanwhile all of the non-genealogy groups I visit have continued to >> contain the sort of insanity Usenet is known for. > <snip> > > I understand what y'r sayin'. Most of "my" groups are pretty quiet at the > moment, but I chalk that up to what I suggested previously. I suspect > things will return to "normal" ere long, though. > > Still, it really is a shame that usenet seems to be dying a lingering death > and most of what's replacing it isn't worth the powder it'd take to blow > it to hell. Maybe it's just as well I'm now well into my dotage and will > likely pass before it does, tho' not by much, in all likelihood. > > Sunburned Ol' Bob > I think those folks who only wanted to talk about Sloegin county are all on one of the newer mail-lists, and so are the folks who only wanted to talk about "their" family. The rest of us, who have more than one family line in more than one locale, are sticking around here. Meanwhile a few years back my ISP quit offering usenet; I haven't had the energy to dig up another source. About that time, Yahoogroups started up, and FamilySearch's family discussions got traction, and yes, mid-Jun to early September is historically slow on usenet as colleges empty, and other folks take vacations. Still, it'll never be what it was back in the day when there was ONE group (Roots-L) and ONE "echo" and each of them several hundred messages a day. Cheryl

Tony Proctor wrote: > "Ian Goddard" <[email protected]> wrote in message > news:[email protected] >> Tony Proctor wrote: >>> "Ian Goddard" <[email protected]> wrote in message >>> news:[email protected] >>>> Tony Proctor wrote: >>>>> ISO 8601 is definitely good John, if you know the date. As a software >>>>> architect I was always surprised how few companies - particularly in >>>>> the US - were aware of it. >>>> Actually it's a problem when used for genealogy. It mandates Gregorian. >>>> Once you get back to 1752 (in UK & colonies) dates in sources will be >>>> given in Julian. If you adhere to the standard you'll have to convert >>>> them to Gregorian which will confuse anyone comparing your data with the >>>> sources. >>>> >>>>> However, in genealogy - and historical data in general - the date is >>>>> not always known exactly. As you point out, you may know the 'quarter', >>>>> say for a registration (as opposed to the BMD event itself), or you may >>>>> know the month of an event but not the day. You might similarly know >>>>> the decade (e.g. 1950's) or the century (e.g. 1800's). >>>>> >>>>> Any product for storing or representing such data would therefore have >>>>> to consider arbitrary degrees of uncertainty and to be able to store >>>>> what you know without having to 'bend the rules' or somehow cheat the >>>>> product. I did spend some time researching into the development of a >>>>> 'universal object model' (I won't elaborate - unless asked - but this >>>>> isn't the same as a storage format or database design) for representing >>>>> historical data but the paid job got in the way. >>>> OK, consider yourself asked! It's something I've given the occasional >>>> thought to without coming to any useful conclusion. It would be >>>> straightforward enough to have a date class with subclasses for Julian, >>>> Gregorian, Britain and colonies etc. But when I considered the >>>> possibility of devising a data type for object relational databases such >>>> as Informix or Postgres the need for comparison code crops up. How do >>>> you collate 01 Jun 1810, 1810, "first quarter of C19th" and "early >>>> C19th"? >>>> >>>> -- >>>> Ian >>>> >>>> The Hotmail address is my spam-bin. Real mail address is iang >>>> at austonley org uk >>> SQL databases have made a complete pig's ear of date/time support Ian. >>> They fail to acknowledge the different between a point in time >>> (technically called a 'timestamp') and a calendar or clock marker (e.g. a >>> d.o.b or a wake-up time). The first is independent of any time-zone >>> change and also independent of any particular date/time representation. >>> It would normally be stored as an offset - say in milliseconds - from >>> some absolute (apologies to Einstein there) epoch. The latter would need >>> to store the elements of the date/time separately (e.g. y/m/d) and >>> time-zones would not be applicable to it. >> If I've followed you correctly it looks as if Postgresql provides both: >> (see http://www.postgresql.org/docs/8.4/static/datatype-datetime.html ) in >> that it allows for timestamps with and without timezone although it keeps >> both as an offset time. >> >> In addition both Informix and Postgresql provide for user-defined types so >> it would be perfectly possible to create a data type storing each element >> separately. Providing, of course, subtracting July from August doesn't >> give January as a result ;) In other words ensure that you use interval >> types as required. >> >> However I think this is the least of our worries compared to calendar >> issues and the imprecision of some sources. >> >>> Anyway, no relational database that I'm aware of has a single data-type >>> that could be used for all the cases required in genealogy. It would have >>> to be some clever composite. >>> >>> An object model, though, is a run-time representation of the data rather >>> than a stored format. If such a standard model existed then it could >>> allow interoperability between products without mandating a particular >>> database or storage format. Good news if you want the option of moving >>> your data between products, or of picking-and-choosing some analysis or >>> reporting product without changing your database. In effect, it would >>> allow the software products to specialise as either >>> database/storage/query or reporting/analysis. Well, that's the theory >>> although I can't see it happening any time soon. As is usually the case, >>> vendors want complete control over everything. Standards like that come >>> too late, if at all. >>> >>> Such a model might allow an analysis product to contrast/compare two >>> different databases, e.g. yours and someone else's. It might also be >>> applicable to 'cloud computing' (depending on its design) where you could >>> publish your data in a shared location and allow various disparate >>> products to access it, subject to security controls of course. >> The runtime format can't be cleanly unpicked from storage however. Queries >> and reporting both need to have workable collating sequences. If you >> search, for instance, for data with a date between 01 Jan 1810 and 31 Dec >> 1810 do you return data where the date was simply given and first quarter >> of the C19th? And where, in a sorted report, do you include something >> with that sort of date? But a genealogical system would need to handle >> that sort of material presented at runtime and to be able to store it >> usefully. >> >> -- >> Ian >> >> The Hotmail address is my spam-bin. Real mail address is iang >> at austonley org uk > > With dates in particular Ian, there's a lot that can be done. For instance, > irrespective of the representation of a date, or the calendar being used > (e.g. Gregorian, Julian), a date can be compiled into a timestamp which > would be a simple "long integer" that relational databases excel at using > for queries. The original representation of the date would probably need to > be stored for viewing/editing purposes but the database would work from the > compiled version for both unambiguity and efficiency. > > Given that all historical dates have some degree of uncertainty, they all > implicitly represent an interval. For instance, the start/end of a day, or > quarter, or year, etc. Hence, any attempt to correlate dates should always > treat them as potentially-overlapping intervals. With a date type as opposed to a date-time type a date is atomic, of course. To go back to my original thoughts on coding comparisons for many cases it's possible providing the S/W doesn't get thrown by situations such as: A = B A = C B < C (A is a lower resolution data such as 1810 and B and C are higher resolution dates such as Jan 1810 and 23 Apr 1810) The real problem is in the vaguer dates such as the catalogued date of early C14th I've seen given for a document although I suspect it to be earlier than one which gave itself an exact date in (IIRC) 1295. And, of course, a good genealogical dating system shouldn't blink if given a date such as June 31 if that's what the original document said. It should just quietly collate it between June 30 and July 1. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On 7-Aug-2011 10:53 am, Wes Groleau wrote: > Has genealogy been declared illegal, > or did I somehow screw up my killfile? > Both :-) Paul

I'll cross-post this to s.g.c to reassure Wes that some of us are still alive... J. P. Gilliver (John) wrote: > The GENI thread made me think of this, but I thought I'd put it as a > separate thread. I'm writing as if for a guide for a beginner like I > think the GENI OP is, but thought it might provoke some interesting > discussions. > > Ideally near the start of creating your data - think very carefully > about the format in which you're going to record some things, such as > dates and places. To some extent, it will be determined by the software > you're using. > > Dates > ----- > If I'd been starting out now, I'd have used the ISO format - year, > month, day. It has several advantages: mainly, if there's anywhere where > it appears in plain text and things are sorted by it, then it sorts by > date. (Provided you put leading zeros in, such as 1960-04-23 rather than > 1960-4-23. I add the dashes for readability: 19600423 would sort as > well, but is less legible.) Another reason for using it is that it's > different from both the UK and US format, which forces anyone to stop > and think, rather than just assuming it is one or other. However, I'm > not saying you must use this format (for a start, I don't know if all g. > software allows it) - just give it some thought. We need to be careful here as the ISO standard not only covers date formats, it also mandates the Gregorian calendar with provision for extending it back beyond its starting date. This, however, is inadequate for our purposes as at not only at some point, which will vary from country to country, older dates need to be Julian but other cultures will have their own calendar. Not surprisingly, therefore, the format makes no provision for the dual format often used form January to March in the Julian period, e.g. 1645/6. A great deal of what you record is likely to be before the switch over date if you make any progress at all with your research. I tend to use what I suppose could be called the Unix calendar - the United Kingdom and her colonies but with the year starting on January 1st if only because most non-genealogical S/W handles it that way. ISO format still doesn't help anyone not familiar with it to work out which part is the month. 1960-04-23 is clear enough, 1960-04-01 is still ambiguous. My practice when writing up is to give months as letters, e.g. 23 Apr 1960 with leading zeros for the single digit days - but only when I remember :o . Having said that I have Informix, where I keep a lot of raw data and OOO Calc set to UK format. > (Another point is don't use two-digit years, but I think this becomes > obvious to any genealogist fairly soon.) Annoyingly both OOO & LibreOffice (at least up to 3.3) have the default UK format set to two digit years. > Decide (again, probably influenced by your software) how you're going to > indicate quarters: a lot of the available information (principally the > birth, marriage and death indices) only gives the information to the > nearest quarter. Personally I use something like "1960Q2", but whatever > works for you. What I personally _don't_ like is the practice - which > ancestry told me is common when I mentioned it to them as part of > another matter - of recording "Jan 1900" or "Mar 1900" when what is > meant is "Jan/Feb/Mar 1900"; it gives the impression that the event has > been pinned down to the month, when it hasn't. I'm only saying I don't > like it, not don't do it, however! > > Think how you're going to consider the fact that _registration_ of BMD > isn't when it happened, only when it was registered: also > baptism/christening isn't when the birth happened. There's no right > answer to this, just think about how (or even if at all) you're going to > indicate the possible discrepancy. The second part should be straightforward enough - you simply record what the event was. > Places > ------ > Again, if I were starting out again now, I'd have used the - not > intuitive - "country, country subdivision, town/village" (where > subdivision is a county for UK, a state for US, and so on). The reason > I'd have done this is down to the fact that the software I use can > produce lists of events sorted by place. I have most of my data as > "town/village, country subdivision, country", which means that the list > looks like > > Martlesham, Suffolk, England > birth of ... > New York, New York, USA > birth of ... > marriage of ... > New Zealand > death of ... > Ormskirk ... > > , whereas if I'd had country first, all the England places would have > been in the same part of the list, with the counties within that chunk, > and so on; it also means where I only knew the country, it wouldn't get > jammed in in an odd place. There's a problem here in that there are multiple schemes for dividing up the country. And I don't just mean boundary changes. At the same time a given place could belong to a parish, a township and a manor. I remember on one occasion helping someone on Genforums over an individual who gave his place of birth on a census as "Almondbury". In his baptismal record an abode wasn't given but his siblings had a quite precise location of "Scar fold" which was in Upperthong township; he'd given his parish of birth. Clearly "Almondbury" and "Upperthong" sort quite differently and Almondbury township is several miles from Upperthong geographically. This is multi-dimensional data and there's no easy way to deal with it. > Also, I store the fine detail, if I have it ("44, Clarges Street") in a > comment field: that way, at least all the events in the same town are > listed together. (However, if I'd been putting country first, it could > maybe have been left in the place field.) > > You may initially consider either not putting the country in, or only > putting it in where it isn't xxx (where xxx is where most of the family > you start with is). However, it's tedious to go back and add it later, > so I'd say it's probably worth doing from the start. > > I'm certainly not saying you should use this "backwards" format - only, > give some long thought to what format you _are_ going to use, preferably > before you start. If you're recording this in genealogical software there seems to be an assumption that we live in cities. I suspect genealogical S/W writers have simply taken over what seem to be US postal address schemas in which they are not alone as a good deal of on-line shops, even those in the UK, seem to do the same. In practice, therefore, I find myself having to use the city field for the township. > Another aspect of place to be considered, is are you going to use > placenames as they were recorded, or as they are now? There are (at > least) two aspects to this: the spelling of placenames changes, and what > county (or even country) they are in does too. The most common variation > for English people is that most of what we now think of as London is > recorded as Middlesex (with some Surrey and Kent), before dates in the > 18xx; there are also county boundary movements (Northumberland used to > extend south of the Tyne more than now), the brand new counties (Tyne > and Wear, Avon, Cleveland, ...), ones that disappeared (and reappeared > in the case of Rutland!), and so on. There is no right answer to this > question, it's just something you should think about; in my own case, > I've generally tried to use the same spelling and county for a > placename, so that all events in it are kept together - but I don't > think I've been completely consistent about whether to use the original > or present form. Ideally S/W should allow you to record the name exactly as found and to have a standard form so if, for instance the township is written Overthong or Overthwonge or whatever you should be able to record this but still be able to refer it to a standard record with the modern standard spelling of Upperthong. Incidentally, until fairly recently one lane in Upperthong had a signboard at one end which spelled it as Wickens Lane and another spelling it as Wickins Lane. > (At least part of the reason for keeping to one variant > is that the software I use lets me type a few letters then press F8, and > it brings up a list of places I've used before, so I like to keep the > total down. Also, when this list pops up, I see what I've used in the > past, and might realise that the place I'm entering is really one I've > already entered.) Gramps has places as a separate database table and at each point where a place is required there are icons to choose from the table or to enter a new place. It can also merge duplicates. > There are other things it's probably worth thinking about your strategy > before you start, too: at the moment I can think of names. In my own > case, where a family has changed the way they spell their surname, I've > recorded each individual as how s/he spelt it. What gets more difficult > is where an individual's name - forename or surname - is spelt > differently at different times. (If they were illiterate, they didn't > spell it at all: other people spelt it for them.) Again, there is no > "right" way to do this, just think about it. A good g. software will > allow you to store alternative names for a person - and let you find > them by either name. IMV good genealogical S/W would keep the name as spelled with the record where it was spelled, not just as a floating alternative name and allow you to have a standard name for the person with some sort of epithet to distinguish it from some other person of the same name, e.g William Goddard II, John Goddard of Scholes etc. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On 08-06-2011 23:26, Bob Melson wrote: > As well, given that - in the US, at least - July and August are the months > in which most people take their summer vacations, it's not surprising that > things are relatively quiet. I expect things will return to what passes > for normal shortly after (US) Labor Day. Well, I just noticed that every genealogy group in my list has been completely empty for many weeks, until this. And the first "hello" I posted today to a different group never appeared. Meanwhile all of the non-genealogy groups I visit have continued to contain the sort of insanity Usenet is known for. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On Saturday 06 August 2011 21:37, Wes Groleau ([email protected]) opined: <snip> > Well, I just noticed that every genealogy group in my list has been > completely empty for many weeks, until this. And the first "hello" > I posted today to a different group never appeared. > > Meanwhile all of the non-genealogy groups I visit have continued to > contain the sort of insanity Usenet is known for. <snip> I understand what y'r sayin'. Most of "my" groups are pretty quiet at the moment, but I chalk that up to what I suggested previously. I suspect things will return to "normal" ere long, though. Still, it really is a shame that usenet seems to be dying a lingering death and most of what's replacing it isn't worth the powder it'd take to blow it to hell. Maybe it's just as well I'm now well into my dotage and will likely pass before it does, tho' not by much, in all likelihood. Sunburned Ol' Bob -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- The greatest tyrannies are always perpetrated in the name of the noblest causes -- Thomas Paine

On Saturday 06 August 2011 19:59, Di Maloney ([email protected]) opined: > There have been posts about Mr Google not behaving very good. I don't > use Mr G but still have had limited number of posts. > A couple of quotes: > A lot of listers also have facebook, maybe they are busy with that. > Its been the same on most lists for a couple of years now. > Barb > > You could be right Barbara, > I have a FB Group that has been rather busy of late. (Australian > Genealogy) > Carolyn > > People don't have to ask these days for look ups, as in the past - so > much > is on line courtesy of Google, Ancestry, the various state archives, > cemeteries and so on. > All the lists I'm on have slowed down to almost nothing, whereas 12 > years > ago when I started family research, my Inbox was bursting every day. > My thoughts anyway. > Denise > > I'm inclined to agree with Denise - and add that whereas in the past > we relied on each other for assistance and advice, these days the > sites such as ancestry mean we no longer have to get other people > involved - > we don't have to mingle - we don't have to share anything - we just > get on with it - in isolation - .which is pretty sad really - > (snipped > remainder) > cheers > Robert > > It has been suggested that people are going over to Facebook. > > I don't like Facebook so won't be going there. > > Di > "Wes Groleau" <[email protected]> wrote in message > news:[email protected] >> Has genealogy been declared illegal, >> or did I somehow screw up my killfile? >> >> -- >> Wes Groleau >> >> There are two types of people in the world . >> http://Ideas.Lang-Learn.us/barrett?itemid=1157 I'm more inclined to believe in the cyclic nature of usenet in general and the geni newsgroups in particular - although usenet is no longer the vibrant exchange it was even 10 years ago. Groups'll go gang-busters for a while, folks will pause to digest and there'll be an "unnatural" silence, then something new will spark a new round of 'cussin' and discussin'. As well, given that - in the US, at least - July and August are the months in which most people take their summer vacations, it's not surprising that things are relatively quiet. I expect things will return to what passes for normal shortly after (US) Labor Day. Swelterin' Ol' Bob -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- The greatest tyrannies are always perpetrated in the name of the noblest causes -- Thomas Paine