From: Benny M. <ben...@gm...> - 2009-12-18 18:50:54
|
2009/12/18 Gerald Britton <ger...@gm...>: > Ah yes. The certificate idea: > > http://www.gramps-project.org/wiki/index.php?title=GEPS_012:_Ecosystem_definition#Certificates > > It's really just one special case of what I'm talking about. Sources > are of course very broad in format, readability, reliability, etc. > I'd like to see a way to easily manage these different types. So if > you start working on a census event, a box pops up asking "which one?" > where we build up sets of custom entry forms for the censi that we > know about, _and_ do it in such a way so that a new user with a (to > us) unknown census can easily add support for that one. > > If it's a publication, we might have dialogs for newspapers (you need > name, publisher, year, volume, section, page, column, etc.), magazines > (similar to newspapers but probably no section or column), > multi-volume works, privately-published genealogies, etc, etc, > > If it's a birth, death, marriage, military etc. certificate, there > would be separate dialogs for each type, possibly customized by > jurisdiction. Which brings up another thought: > > The dialogs should be dynamic and respond to data as entered. So if I > say "census!" the start typing "Canada" it would prompt me for the > available censi (1851/2, 1861, 1871, 1881, 1891, 1901, 1906, 1911, > 1916) and have the smarts to know if there are multiple schedules > available (e.g. for 1901). If I get to province and start typing > "Ontario" it could prompt me for the county (the list may differ by > date). Note: You may not want to do a whole country this way since > the data would be large if you drilled down to the township/city > level. > > However we do it (and if we do it), I would like to see a system that > is easy to understand and easy to extend. Also, the system would not > be just for data entry but also for display. So if I entered a census > source this way, the next time I went to look at it the same dialog > would be there, with the data I had already filled in. > Richard once started a separate application for storing 'certificates' or however he called it. How far did you design that Richard? The main problem of doing it in Gramps (where it belongs I think) is to design how we would evolve from the present structure which is very close to Gedcom, to this different way of doing things, and upgrade existing data in some sensible way. Well, for 3.3, I'll concentrate the little time I have on 3.2 now. Benny > On Fri, Dec 18, 2009 at 10:07 AM, Benny Malengier > <ben...@gm...> wrote: >> There are some things I want to note here: >> >> 1/any developer changing things in the source system of Gramps must be >> very careful not to change things as he uses sources. Many people use >> the source system in different ways. This does not mean things cannot >> change, only that they must be planned and designed carefully. I think >> things can improve a lot, the question is only how to best achieve >> this. >> >> 2/we have dynamic building of the filter rules, and dynamic binding of >> the report plugin options. I think this is a better system than glade >> files. So, a set of predefined widgets that can be reused, a way to >> set the layout from these elements, and a framework into which to do >> this. The suggestion of Gerals looks to me like another angle to the >> certificate approach I advocated instead of the data entry gramplets. >> In that view the present data entry gramplets can be seen as test >> cases for what such a certificate approach must make more easy. >> >> Benny >> >> 2009/12/17 Nick Hall <nic...@ho...>: >>> Jerome, >>> >>> Thanks for the links. >>> >>> The date on the source reference is: "The date that this event data was >>> entered into the original source document." >>> >>> This seems to me to be most appropriate for registers and ledgers which >>> are continuously being added to, not to published documents. In Geralds >>> examples, the census had a date but the entry for his ancestor was made >>> on a different date. This is a good use of this field. The other >>> example of a periodical also works quite well; the date of publication >>> for the source spans many months or years, but we are interested in one >>> issue for a given date. >>> >>> I think that one of the problems for new users is knowing what to use >>> certain fields for. The source type suggestion would help with this. >>> >>> For a register the date could be described as "Entry Date", for a census >>> it could be "Date Recorded", and for a periodical it could be "Issue Date". >>> >>> Nick. >>> >>> jerome wrote: >>>> When I started to use Gramps, I set the date of my search on the date field (i.e find this event/sourceref on 2007, an other person/sourceref on 2008 for the same source, etc ...) >>>> >>>> Then with "Bibliography in reports (display of source information)" - mailing list (2007), I understand that we should rather use this field for the date written into the source, or the time log if source = someone). >>>> >>>> Now, I add this information on Publication information (Source object) ... (but could be source title) >>>> Just because I try to avoid secondary objects. Primary object with less secondary "levels" as possible because informations are also displayed on views and could be filtered, etc ... >>>> >>>> >>>>> So I might say that I was married 5 April 1975 and refer to a source with a date of 10 Dec 1980, when the source was published. Is that what you mean ? >>>>> >>>> >>>> Yes ! It is the date on source reference, when the event is highlighted on the source. >>>> >>>> Note, I also find the date of search (when we find event/person/family on the source), not false ... >>>> >>>> But Benny highlights the way to use date field on source reference : >>>> >>>> "As I understand it, GEDCOM date in sourceref means to do the following: A source is ag: baptize acts 1902-1912. Then, in a baptize record (same for marriage, death), the individual acts are numbered according to date, so: "1910-05-02, baptized John, son of ....." >>>> So the date is the log date of the event hapening as written down in the source. >>>> So date is there to allow you to find the birth record in the source, the same as page helps you to find the relevant section in a book (the old records don't have page numbers and numbering is often something added by present day researchers, not by the person who wrote the record). So date and page in sourceref serve the same purpose." >>>> --- Benny (archives May 21, 2007 - Bibliography in reports) >>>> >>>> >>>> Note, Gramps was just following Gedcom spec ! >>>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_CITATION >>>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#WHERE_WITHIN_SOURCE >>>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#ENTRY_RECORDING_DATE >>>> http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_PUBLICATION_FACTS >>>> >>>> >>>> Jérôme >>>> >>>> --- En date de : Jeu 17.12.09, Gerald Britton <ger...@gm...> a écrit : >>>> >>>> >>>>> De: Gerald Britton <ger...@gm...> >>>>> Objet: Re: Re : [Gramps-devel] Source types and source management >>>>> À: "jerome" <rom...@ya...> >>>>> Cc: "Nick Hall" <nic...@ho...>, "gramps-devel" <gra...@li...> >>>>> Date: Jeudi 17 Décembre 2009, 18h16 >>>>> I'm not sure I understand you >>>>> properly Jerome, but I think you are >>>>> highlighting the difference between an event (such as a >>>>> marriage) and >>>>> when a source record became available. So I might say >>>>> that I was >>>>> married 5 April 1975 and refer to a source with a date of >>>>> 10 Dec 1980, >>>>> when the source was published. Is that what you >>>>> mean? >>>>> >>>>> On Thu, Dec 17, 2009 at 12:13 PM, jerome <rom...@ya...> >>>>> wrote: >>>>> >>>>>>> What is the Date field for? Again in most cases >>>>>>> >>>>> the date >>>>> >>>>>>> will apply to >>>>>>> the source: a publication date or a census date >>>>>>> >>>>> for >>>>> >>>>>>> example. Where it is >>>>>>> applicable for a reference, such as for a >>>>>>> >>>>> marriage >>>>> >>>>>>> register, I tend to >>>>>>> put the date on the event only and don't put a >>>>>>> >>>>> copy in the >>>>> >>>>>>> SourceRef. >>>>>>> >>>>>> Date on a reference seems to be like a time log ! >>>>>> >>>>> [1][2] >>>>> >>>>>> ie. event (with date), which is noted on sources could >>>>>> >>>>> happen few or many days/months/years before the source has >>>>> been written (reported event). >>>>> >>>>>> For the source type, we could also have a level >>>>>> >>>>> question ! >>>>> >>>>>> http://www.gramps-project.org/wiki/index.php?title=Sources#Definition >>>>>> >>>>>> >>>>>> [1] http://old.nabble.com/Bibliography-in-reports-(display-of-source-information)-p10702537.html >>>>>> (sorry cannot find the exact post, but Benny or Brian >>>>>> >>>>> has given the correct/logical answer : time log) >>>>> >>>>>> [2] http://old.nabble.com/Date-field-on-SourceRef-to12047334.html#a12047334 >>>>>> >>>>>> >>>>>> Jérôme R. >>>>>> >>>>>> >>>>>> --- En date de : Jeu 17.12.09, Nick Hall <nic...@ho...> >>>>>> >>>>> a écrit : >>>>> >>>>>>> De: Nick Hall <nic...@ho...> >>>>>>> Objet: [Gramps-devel] Source types and source >>>>>>> >>>>> management >>>>> >>>>>>> À: "Gerald Britton" <ger...@gm...> >>>>>>> Cc: "gramps-devel" <gra...@li...> >>>>>>> Date: Jeudi 17 Décembre 2009, 17h26 >>>>>>> This is a good idea. >>>>>>> >>>>>>> A source type could customise the input fields for >>>>>>> >>>>> both the >>>>> >>>>>>> Source and >>>>>>> SourceRef records. >>>>>>> >>>>>>> For example an English Census would need the >>>>>>> >>>>> following >>>>> >>>>>>> fields in SourceRef: >>>>>>> >>>>>>> * PRO Reference, Piece, Folio, Page >>>>>>> >>>>>>> and in the Source record it would really just >>>>>>> >>>>> need: >>>>> >>>>>>> * Title, Publisher, Date >>>>>>> >>>>>>> Whereas a book probably only needs one field in >>>>>>> >>>>> SourceRef: >>>>> >>>>>>> * Page >>>>>>> >>>>>>> but a few in the Source record: >>>>>>> >>>>>>> * Title, Author, Publisher, Date, ISBN Number >>>>>>> >>>>>>> >>>>>>> I think that the extension to SourceRef would >>>>>>> >>>>> probably be >>>>> >>>>>>> the most >>>>>>> useful benefit. As the fields are likely to be >>>>>>> >>>>> text only >>>>> >>>>>>> all that is >>>>>>> really needed to define a source type is a list of >>>>>>> >>>>> field >>>>> >>>>>>> names. The >>>>>>> SourceRef fields could then be built by a script >>>>>>> >>>>> rather >>>>> >>>>>>> than having to >>>>>>> supply a glade file. The existing database field >>>>>>> >>>>> could be >>>>> >>>>>>> used to store >>>>>>> the data, but as a list rather than a string. >>>>>>> >>>>>>> A couple of unrelated comments - >>>>>>> >>>>>>> I don't use the Confidence field, but I would use >>>>>>> >>>>> it if I >>>>> >>>>>>> could supply >>>>>>> the confidence of a source as a whole rather than >>>>>>> >>>>> for each >>>>> >>>>>>> reference >>>>>>> individually. >>>>>>> >>>>>>> What is the Date field for? Again in most cases >>>>>>> >>>>> the date >>>>> >>>>>>> will apply to >>>>>>> the source: a publication date or a census date >>>>>>> >>>>> for >>>>> >>>>>>> example. Where it is >>>>>>> applicable for a reference, such as for a >>>>>>> >>>>> marriage >>>>> >>>>>>> register, I tend to >>>>>>> put the date on the event only and don't put a >>>>>>> >>>>> copy in the >>>>> >>>>>>> SourceRef. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Nick. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Gerald Britton wrote: >>>>>>> >>>>>>>> Back in June, John (jh...@ea...) >>>>>>>> >>>>>>> posed a question about using >>>>>>> >>>>>>>> the expanded approach to sources espoused by >>>>>>>> >>>>> Elizabeth >>>>> >>>>>>> Shown Millls in >>>>>>> >>>>>>>> her books "Evidence!" and "Evidence >>>>>>>> >>>>> Explained." >>>>> >>>>>>> At the time, I was >>>>>>> >>>>>>>> skeptical as I was not familiar with the >>>>>>>> >>>>> author or >>>>> >>>>>>> that approach. >>>>>>> >>>>>>>> Since then, I have familiarized myself with >>>>>>>> >>>>> her work >>>>> >>>>>>> and become very >>>>>>> >>>>>>>> receptive to the concepts contained therein. >>>>>>>> >>>>>>>> The basic idea is, that "source" is too >>>>>>>> >>>>> general and >>>>> >>>>>>> one needs a way to >>>>>>> >>>>>>>> categorize sources. For example, if the >>>>>>>> >>>>> source >>>>> >>>>>>> is a census, you will >>>>>>> >>>>>>>> want to capture data like the year of the >>>>>>>> >>>>> census, the >>>>> >>>>>>> state, city, >>>>>>> >>>>>>>> parish (or other administrative district) >>>>>>>> >>>>> page number, >>>>> >>>>>>> household, >>>>>>> >>>>>>>> family number etc. On the other hand, if >>>>>>>> >>>>> the >>>>> >>>>>>> source is a published >>>>>>> >>>>>>>> pedigree in a book, you will want the title >>>>>>>> >>>>> and author >>>>> >>>>>>> of the book, >>>>>>> >>>>>>>> (possibly) a volume number, the page number >>>>>>>> >>>>> and >>>>> >>>>>>> publisher. These two >>>>>>> >>>>>>>> source categories call for different sorts of >>>>>>>> >>>>> data >>>>> >>>>>>> capture. >>>>>>> >>>>>>>> Several commercial programs have adopted this >>>>>>>> >>>>> approach >>>>> >>>>>>> and built >>>>>>> >>>>>>>> templates for source data by category. >>>>>>>> >>>>> This >>>>> >>>>>>> makes is easy to >>>>>>> >>>>>>>> consistently capture the right data for a >>>>>>>> >>>>> given type >>>>> >>>>>>> of source. I've >>>>>>> >>>>>>>> been wondering for a while if we should do >>>>>>>> >>>>> something >>>>> >>>>>>> similar in >>>>>>> >>>>>>>> gramps. It would work something like this: >>>>>>>> >>>>>>>> 1. When you want to add a source, the first >>>>>>>> >>>>> thing you >>>>> >>>>>>> would do is >>>>>>> >>>>>>>> select a source type from a drop-down list >>>>>>>> >>>>> (it would >>>>> >>>>>>> default to >>>>>>> >>>>>>>> "Unknown" which would be similar to what we >>>>>>>> >>>>> have in >>>>> >>>>>>> place today). >>>>>>> >>>>>>>> 2. Once a source type is selected, gramps >>>>>>>> >>>>> would >>>>> >>>>>>> present a dialog >>>>>>> >>>>>>>> crafted specifically for that source type >>>>>>>> >>>>> which the >>>>> >>>>>>> user can then >>>>>>> >>>>>>>> easily fill in. >>>>>>>> >>>>>>>> 3. The data would be stored in a structured >>>>>>>> >>>>> form in >>>>> >>>>>>> the database which >>>>>>> >>>>>>>> can be accessed for reports and future edits >>>>>>>> >>>>>>>> 4. The source types would be represented by >>>>>>>> >>>>> glade >>>>> >>>>>>> dialogs (stored as >>>>>>> >>>>>>>> XML). The type of the source would be >>>>>>>> >>>>> stored in >>>>> >>>>>>> the glade file and in >>>>>>> >>>>>>>> a special directory. >>>>>>>> >>>>>>>> 5. At startup, gramps would read the source >>>>>>>> >>>>> types >>>>> >>>>>>> directory and build >>>>>>> >>>>>>>> a dictionary mapping the source type to the >>>>>>>> >>>>> glade >>>>> >>>>>>> file, for use when >>>>>>> >>>>>>>> actually displaying or editing the source >>>>>>>> >>>>> material. >>>>> >>>>>>>> With glade files stored in a special >>>>>>>> >>>>> directory for >>>>> >>>>>>> source types, it >>>>>>> >>>>>>>> will be easy to add new source types either >>>>>>>> >>>>> as part of >>>>> >>>>>>> the package or >>>>>>> >>>>>>>> for custom work by one user. We should >>>>>>>> >>>>> probably also >>>>> >>>>>>> recognize a >>>>>>> >>>>>>>> directory under ~/.gramps for user-built >>>>>>>> >>>>> source type >>>>> >>>>>>> glade files. >>>>>>> >>>>>>>> One challenge with this is that there will be >>>>>>>> >>>>> some >>>>> >>>>>>> work to do on >>>>>>> >>>>>>>> upgrades, exports and imports, as well as >>>>>>>> >>>>> work to do >>>>> >>>>>>> on reports etc. >>>>>>> >>>>>>>> One possible mitigation would be to return a >>>>>>>> >>>>> string >>>>> >>>>>>> built from the >>>>>>> >>>>>>>> individual elements when reading the >>>>>>>> >>>>> "volume/page" >>>>> >>>>>>> info for a source. >>>>>>> >>>>>>>> Such an approach might mean less downstream >>>>>>>> >>>>> impacts. >>>>> >>>>>>>> For now, I just want to socialize this idea >>>>>>>> >>>>> among the >>>>> >>>>>>> gramps' >>>>>>> >>>>>>>> developer community. Please criticize, add >>>>>>>> >>>>> to it >>>>> >>>>>>> or tear it down (if >>>>>>> >>>>>>>> it is completely loony!) >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Dec 17, 2009 at 8:18 AM, Doug Blank >>>>>>>> >>>>> <dou...@gm...> >>>>> >>>>>>> wrote: >>>>>>> >>>>>>>>> On Thu, Dec 17, 2009 at 7:09 AM, Duncan >>>>>>>>> >>>>> Lithgow >>>>> >>>>>>>>> <dun...@gm...> >>>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>>>> Like me a lot of amateur genealogists >>>>>>>>>> >>>>> have the >>>>> >>>>>>> goal of writing a >>>>>>> >>>>>>>>>> family history as a book, perhaps >>>>>>>>>> >>>>> illustrated, >>>>> >>>>>>> hopefully with source >>>>>>> >>>>>>>>>> notes. >>>>>>>>>> >>>>>>>>>> So, what can Gramps do to help with >>>>>>>>>> >>>>> this? I >>>>> >>>>>>> have two ideas: >>>>>>> >>>>>>>>>> * Make a way of referencing sources >>>>>>>>>> >>>>> directly >>>>> >>>>>>> from a note, so notes can >>>>>>> >>>>>>>>>> become part of a narrative with >>>>>>>>>> >>>>> sources. >>>>> >>>>>>>>>> * Make the Gramps source list >>>>>>>>>> >>>>> exportable in >>>>> >>>>>>> some standard form which >>>>>>> >>>>>>>>>> apps like OpenOffice can use. >>>>>>>>>> >>>>>>>>>> Personally I prefer the second idea, >>>>>>>>>> >>>>> Gramps >>>>> >>>>>>> should not become a word >>>>>>> >>>>>>>>>> processor. What do others think? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> The second can be done as an addon >>>>>>>>> >>>>> Report. I have >>>>> >>>>>>> some Python code >>>>>>> >>>>>>>>> that can format BibTex and EndNote [1]. >>>>>>>>> >>>>> If you >>>>> >>>>>>> write up some notes on >>>>>>> >>>>>>>>> how that would work, I can provide a >>>>>>>>> >>>>> basic addon. >>>>> >>>>>>>>> The first would involve some work, but >>>>>>>>> >>>>> might be >>>>> >>>>>>> related to something >>>>>>> >>>>>>>>> else I'm working on. I've been working on >>>>>>>>> >>>>> a >>>>> >>>>>>> mechanism for providing >>>>>>> >>>>>>>>> "links" in the GUI to take you to other >>>>>>>>> >>>>> parts of >>>>> >>>>>>> gramps. For example, >>>>>>> >>>>>>>>> in the TODO Gramplet, it would be nice to >>>>>>>>> >>>>> add a >>>>> >>>>>>> list of people with >>>>>>> >>>>>>>>> links, so that it would take you to that >>>>>>>>> >>>>> person. >>>>> >>>>>>> Perhaps this same >>>>>>> >>>>>>>>> idea could be "rendered" in other >>>>>>>>> >>>>> doctypes to >>>>> >>>>>>> include a >>>>>>> >>>>>>>>> bibliography... >>>>>>>>> >>>>>>>>> -Doug >>>>>>>>> >>>>>>>>> [1] - http://biblio.roboteducation.org/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Duncan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>>>>>>> This SF.Net email is sponsored by the >>>>>>>>>> >>>>> Verizon >>>>> >>>>>>> Developer Community >>>>>>> >>>>>>>>>> Take advantage of Verizon's >>>>>>>>>> >>>>> best-in-class app >>>>> >>>>>>> development support >>>>>>> >>>>>>>>>> A streamlined, 14 day to market >>>>>>>>>> >>>>> process makes >>>>> >>>>>>> app distribution fast and easy >>>>>>> >>>>>>>>>> Join now and get one step closer to >>>>>>>>>> >>>>> millions >>>>> >>>>>>> of Verizon customers >>>>>>> >>>>>>>>>> http://p.sf.net/sfu/verizon-dev2dev >>>>>>>>>> >>>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>>>>> Gramps-devel mailing list >>>>>>>>>> Gra...@li... >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>>>>>> This SF.Net email is sponsored by the >>>>>>>>> >>>>> Verizon >>>>> >>>>>>> Developer Community >>>>>>> >>>>>>>>> Take advantage of Verizon's best-in-class >>>>>>>>> >>>>> app >>>>> >>>>>>> development support >>>>>>> >>>>>>>>> A streamlined, 14 day to market process >>>>>>>>> >>>>> makes app >>>>> >>>>>>> distribution fast and easy >>>>>>> >>>>>>>>> Join now and get one step closer to >>>>>>>>> >>>>> millions of >>>>> >>>>>>> Verizon customers >>>>>>> >>>>>>>>> http://p.sf.net/sfu/verizon-dev2dev >>>>>>>>> >>>>>>>>> >>>>> _______________________________________________ >>>>> >>>>>>>>> Gramps-devel mailing list >>>>>>>>> Gra...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>>>> This SF.Net email is sponsored by the Verizon >>>>>>> >>>>> Developer >>>>> >>>>>>> Community >>>>>>> Take advantage of Verizon's best-in-class app >>>>>>> >>>>> development >>>>> >>>>>>> support >>>>>>> A streamlined, 14 day to market process makes app >>>>>>> distribution fast and easy >>>>>>> Join now and get one step closer to millions of >>>>>>> >>>>> Verizon >>>>> >>>>>>> customers >>>>>>> http://p.sf.net/sfu/verizon-dev2dev >>>>>>> _______________________________________________ >>>>>>> Gramps-devel mailing list >>>>>>> Gra...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Gerald Britton >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> > > > > -- > Gerald Britton > |