From: Brian M. <br...@gr...> - 2007-05-20 12:19:54
|
Benny, >My source/sourceref discussion made clear there are quite some problems with >this in GRAMPS. > >It would be nice to agree on my proposal and work towards that :-) It would >simplify things. I don't see any way that your proposal makes the bibliography aspect of reports easier. If anything, it makes it more difficult. >Concerning your proposal, it is not bad, but some issues related to what I >mentioned then: >* many double references. See the census tutorial on wiki: scratchpad is used >for making identical references! So, you should merge identical references in >an output, or it quickly becomes ugly and comical, eg: > >1.1984 Monty University Yearbook; Monty University Yearbook Committee >a. p. 22 >b. p. 22 >c. p. 22 >d. p. 22 >e. p. 22 >f. p. 22 I thought of that. I compare the source references and if one already exists with the same content, I don't add a second one. So in your example, "1.a" would appear in the report 6 times and the "p. 22" source ref would only be in the bibilography once. >* You normally reference a source as follows: John [1] or John [1 pag. >22]. This is absolutely true in academic research (APA or MLA style). But in genealogy you don't always have page numbers. Information is often from census information or microfilm categories. So in that case, there might be more than just a page number to be included in the citation. This method avoids having long references in the text. >You >don't have : >3. www.softwareengineersrus.com; An online list of software engineers >a. Edwin is listed in three categories: publishing, manufacturing, and >graphics.; 2003-12-12 >This 3.a is more like a footnote to a text about Edwin. In a report of >30 pages >having this in the Endnote section is of little use. Again, this is the >problem >of the sourceref object, which as it is now gives the impression you >should put >logical deductions in the sourceref. This however gives very awkward >situations >when you try to list the sources seperately of the object containing the >sourceref. This is neither a note about Edwin nor a logical deduction. It is information about which sections of the source information was found about Edwin. I typed it in the "text" field in the source ref. We could choose to leave it out, but it could include valuable information necessary for someone else to retrace the steps of the original researcher. >My suggestion, as before, would be: work out a workable workflow on how >to work >with sources, the present one just is no good for serious stuff. Document that >and work the interface reports around this. Trying to fix a broken design by >redoing the reports will only help people who use the broken design in a >specific way, and will leave the people doing it another way in the cold. Again, everything I saw about your proposal added complexity. There is no way it will make this job easier. Thanks for your feedback! ~Brian |
From: Brian M. <br...@gr...> - 2007-05-20 15:54:55
|
Jerome, >But did you improve the displaying method or the storage ? Excellent question. I should have been more clear. I'm not proposing any change to the storage nor GUI display of source information. The only thing I am proposing to change is how we display source information in reports. ~Brian |
From: <rom...@ya...> - 2007-05-20 16:32:09
|
> The only thing I am proposing to change is how we display source information in reports. Then you should not care/pay attention to GEDCOM, it is a GRAMPS issue for displaying his data ;) For the style, I like mixtures italic/small/normal characters and comas on references. In fact, endnotes are only quotations but more developed, no ? And this may avoid a too formatted list !!! But I do not know if there is a standard for us, and I am not sure you will be able to separate data of the style for all supported formats ? |
From: Brian M. <br...@gr...> - 2007-05-20 18:45:28
|
>> The only thing I am proposing to change is how we display source information in reports. > >Then you should not care/pay attention to GEDCOM, it is a GRAMPS issue >for displaying his data ;) Good point. Let me explain. The Gramps storage and display of sources is based loosely on the GEDCOM standard. With that constraint in mind, it is difficult to map the data that Gramps stores into a strict APA format. Read about APA format here: http://owl.english.purdue.edu/owl/resource/560/01/ Here is one example. In APA style, you list each reference in the text using the (Author, page#) format. But in Gramps, there is no explicit page number field, it is "volume/page". I have used this field like this before: "Volume 51, Issue 4, page 22". That wouldn't conform to the APA style very well. Here is another example. In APA style, you list the publishing date of each source. In Gramps, sources have the following fields: Title, Author, and Publication Information. I presume you would put the date in the Publication Information field. But there is no good way to extract a date from it to be used in the reports. Here is another example. In Gramps, each source reference has a date field. I have no idea how that could be mapped into an APA formatted reference as APA requires the data of publication of the source, not the reference. >For the style, I like mixtures italic/small/normal characters and comas >on references. In fact, endnotes are only quotations but more developed, >no ? And this may avoid a too formatted list !!! >But I do not know if there is a standard for us, and I am not sure you >will be able to separate data of the style for all supported formats ? APA is one of many standards that define how to do this. And it could be done in Gramps within the capacity that we can use the fields provided by Gramps. Like I already explained, the publishing date of a source is not readily available. So it can not be formatted. Like I already said, I certainly don't have this figured out. I don't know if genealogists use APA format or some other format. Does anyone have any example reports from other genealogy programs, or professional genealogical societies that we could look at? ~Brian |
From: Brian M. <br...@gr...> - 2007-05-20 21:51:20
|
Benny, Thanks for your response. I should explain that I do not believe that source storage, display, and work flow is within my sphere of influence. By that, I mean that I don't have the expertise, knowledge, inspiration, motivation, or gumption to change the way Gramps handles sources. The only way that I feel I can contribute is by changing the way Gramps prints the currently existing source information in reports. I have a lot of respect for your proposal. What I don't have is an opinion about it - mostly because I am ignorant of the whole subject. Surely there is someone more qualified than I to make that determination. So I elect to stand on the sidelines and watch the experts figure that part out. >first, if you look in the TODO on 2.3, you'll see we decided on removing the >text field in sourceref. So please, don't start to use it know. The present >text field will become a note with a still to determine type (I would choose >transcript). The reason is that with multiple notes implemented in 2.3 having >both text and notes tabs looks stupid, plus, we shouldn't encourage people to >add text of a source in sourceref anyway (the GEDCOM says the same by >the way). That's good feedback. Based on your comments, I think I'll not display the text information (for source references) in the reports. I don't use that field for anything, anyway. >Second, it's easy to say my sourceref proposal is too complex without >elaborating. It's even stranger to then see you suggest to try to solve in >software what I would design into the database (that is, removing doubles in >sourceref from reports). I'm not trying to solve any problems that exist with respect to how sources are designed into the database. I'm just trying display what we have better. >Should you reread my proposal, you would see I suggest to add full publication >data to source, and ordering of sourceref based on number/section/page/log >date. That would be handy for refereeing. I certainly can't argue with that. See my previous comments about ignorance and not having an opinion. >Concerning the art of refereeing, looking at my genealogical organization, I >would not take whatever they use to be a standard! They just work in a void, >everybody using the style their word processor comes with. It would be more >correct to look at academic research on sources, and they use the standard >refereeing style. > >See eg http://www.historiaeninformatica.org/11_1/03.htm, at the bottom >references. General in this: references do *not* contain information which is >on the level of sourceref. This is also valuable. What I seem to be hearing from you and others is that genealogists don't seem to generally follow any standard for their documentation. Perhaps we should just choose the APA format as our ultimate goal and work toward that. >If you do want to output sourceref information in a report, I would >suggest the >following: > >object -- sourceref <-- source > >when listing object in a report, you add a link to source via inline [1] >notation. This links to a reference section containing only information as >found in the source object. >If the sourceref object is nonempty and containing information you want on the >report, use a footnote: in the text you add a link to the footnote via a >superscript number, in the footnote is represented information from the >sourceref obejct, and an inline reference like [1] is given to the source at >the end of the report. Using inline notation (instead of endnotes as we use now) is starting to look appealing. This would conform more closely to the APA format. >However, I would not print out to much of the sourceref object. Please, reread >my proposal on this: sourceref is replaced by subsource. This allows to only >print correct reference in the reports (publication info is known). For >detailed reports, the report can end with a detailed source section, listing >all used subsources and their information. >From this, might I deduce that I could also ignore the date field in the existing source ref? That would really make things easier as all that is left is the page field. Using only the page field would make inline notation even more appealing. >I fail to see what is complex in this proposal. Actually, this entire >discussion >plainly shows the present design not working. Fixing that is the way to go. Again, no opinion from me. Thanks again for all your comments. I sure wish someone could just come along and say "True genealogy requires that you use the XYZ formatting standard". But it doesn't look like that is going to happen. ~Brian |
From: Brian M. <br...@gr...> - 2007-05-21 04:32:00
|
Here is a report generated by Genbox: http://genbox.com/reports/pdf/descnarr1.pdf It uses endnotes for source references and a separate Bibliography section for the actual source information. Is this a desirable format for Gramps to adopt for displaying sources? ~Brian |
From: <sk...@ac...> - 2007-05-21 09:14:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Brian and all others, I'm pleased to see that a discussion on how sources should be printed in reports have arised. I agree with Brian that this needs some improvement, and I would like to remind you of an old feature request of mine: http://bugs.gramps-project.org/view.php?id=556. > It uses endnotes for source references and a separate Bibliography > section for the actual source information. > > Is this a desirable format for Gramps to adopt for displaying > sources? I really like it and it is much better than my feature request above. Source references has the purpose of pointing out where information and facts come from. Anyone should be able to track down the sources, which means that it is important to distinguish which bits and pieces of information that is being referenced, and where to find the sources of this information. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUWLWzv8VI4RnlpQRAjDjAKCY2TFiXHXR1vuEHm6boT7/SwBU1gCgjJCa jT4p+SjBZZwyplolAKdQl9E= =C9Uj -----END PGP SIGNATURE----- |
From: <sk...@ac...> - 2007-05-21 09:17:54
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I really like it and it is much better than my feature request above. Ah, well, at second thought, maybe we don't need footnotes everywhere, as in Brians example. For example, I think it's redundant to add footnotes to lists of children when they are mentioned as persons elsewhere in the document. However, a true advantage would be the possibility to add sources to text comments (like on page 3 of Brians example). Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUWO6zv8VI4RnlpQRAtm+AJ49v7wNy0naQHb/DYUgeUuVajfjrgCbBkUN FBXKunvYcr5hd7puzs7fBc4= =CgXA -----END PGP SIGNATURE----- |
From: <bm...@ca...> - 2007-05-21 13:24:59
|
Quoting Stefan Bj=F6rk <sk...@ac...>: >> I really like it and it is much better than my feature request above. > > Ah, well, at second thought, maybe we don't need footnotes everywhere, > as in Brians example. For example, I think it's redundant to add > footnotes to lists of children when they are mentioned as persons > elsewhere in the document. > > However, a true advantage would be the possibility to add sources to > text comments (like on page 3 of Brians example). > > Stefan I reread the report after this a bit more carefully, and it looks a bit overdone indeed: many doubles, some endnotes look like bibliography, some bibliograp= hy info looks more like repositories, ... Anyway, I did not see sources linked to text comments, I think they are all sources linked to events/attributes with eg notes. I think that is the corr= ect way of working, one can hardly start to add sources for every word one type= s. Remember, notes are just that: notes. They are not meant to be literature. Literature should be reserved for the text of sources. If you really make a long nice text based on some sources, I would suggest = you make a new source record, and add your text to that. This is called academically a tertiary source. Eg: Source: My notes. Then add a note to th= e source with the sources you consulted. You could do a feature request to ad= d a source tab to a source for this use, but don't expect a quick implementatio= n. If you want to copy a piece of a source to a note with eg a person, you sho= uld actually add the piece of text of the source to the source object, and link the person to this source, indicating in the sourceref where in the source the relevant part is, and not make a note linked to person with this text. Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <bm...@ca...> - 2007-05-21 13:08:00
|
Quoting Brian Matherly <br...@gr...>: > Here is a report generated by Genbox: > http://genbox.com/reports/pdf/descnarr1.pdf > > It uses endnotes for source references and a separate Bibliography > section for the actual source information. > > Is this a desirable format for Gramps to adopt for displaying sources? It is nice, but I would give the bibliography numbers too. Then the endnotes should state the bibliography entry they link too. Also empty sourceref must be handled, which can only be done by making the bibliograpy numbered. Actually, this proposal is like mine with footnotes, but instead of footnotes, the notes are collected in an endnotes section. This endnotes section is only useful in some detailed reports, for more general reports it should be dropped, only keeping bibliograpy in my opinion (with perhaps the option to also drop that for an even shorter report). Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Brian M. <br...@gr...> - 2007-05-21 11:38:27
|
>> Like I already explained, the publishing date of a source is not readily available > >That makes me think: >In Genealogy, what must we put in date field on SourceRef, the date of >publication (1875) or the date of discovered source (2007) !!! I've been wondering the same thing for a long time. If anyone has any insight, please share! ~Brian |
From: <bm...@ca...> - 2007-05-21 13:04:24
|
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. Furthermore, remember, sourceref is about how you use the source, so publication date/info of the source *does not belong there*. That should go in the source object, the same for text, eg: "Published by John Whiley and Co., 2005". Sourceref is about how to work with the source to find the info of the person you are looking at in this source. In present day design, one would not add page or date to eg the person object, one would link directly to the correct position within the source. The linked structure in GEDCOM however only links to source, so they needed to refine that with the sourceref included in person object. Benny Quoting Brian Matherly <br...@gr...>: >>> Like I already explained, the publishing date of a source is not >>> readily available >> >> That makes me think: >> In Genealogy, what must we put in date field on SourceRef, the date of >> publication (1875) or the date of discovered source (2007) !!! > > I've been wondering the same thing for a long time. If anyone has any > insight, please share! > > ~Brian > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <sk...@ac...> - 2007-05-21 20:14:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Matherly skrev: >>> Like I already explained, the publishing date of a source is not readily available >> >> That makes me think: >> In Genealogy, what must we put in date field on SourceRef, the date of >> publication (1875) or the date of discovered source (2007) !!! > > I've been wondering the same thing for a long time. If anyone has any insight, please share! The obvious answer (at least, it is obvious to me) is to use the date of publication. Source references serve the purpose of pointing out the source to anyone interested, and the date of publication helps finding the source. The date of discovery seem quite irrelevant from this point of view. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUf1/zv8VI4RnlpQRAt82AJ4wUqyZrIhUgAdfgKjkqooZajjJCACcDRR3 c6wxifTVvngHjQNgVAANtQM= =Pshz -----END PGP SIGNATURE----- |
From: <rom...@ya...> - 2007-05-21 21:05:16
|
> Source references serve the purpose of pointing out the source to anyone interested, and the date of publication helps finding the source. Then we should move the field from SourceReference to Source (with Title, Author, etc...) Date of publication will be the same for all related object !!! > The date of discovery seem quite irrelevant from this point of view I will add a date field on RepoRef (with Call number and media type) Also, a place field could be an other improvement. OK, too many fields may lose user. But you could have the same source on differents dates of search. Is it useful ? Sources exists with their title, author, date of publication and data. Repositories will change/move and call number are not eternal, we need to fix them in time. Publication place may be different as event place or repository place for search. Other exemple: birth/death date on certificate versus certificate date on repository. Dates are often close, but not always ... � a écrit : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Brian Matherly skrev: >>>> Like I already explained, the publishing date of a source is not readily available >>> >>> That makes me think: >>> In Genealogy, what must we put in date field on SourceRef, the date of >>> publication (1875) or the date of discovered source (2007) !!! >> I've been wondering the same thing for a long time. If anyone has any insight, please share! > > The obvious answer (at least, it is obvious to me) is to use the date of > publication. Source references serve the purpose of pointing out the > source to anyone interested, and the date of publication helps finding > the source. The date of discovery seem quite irrelevant from this point > of view. > > Stefan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGUf1/zv8VI4RnlpQRAt82AJ4wUqyZrIhUgAdfgKjkqooZajjJCACcDRR3 > c6wxifTVvngHjQNgVAANtQM= > =Pshz > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Jérôme Rapinat |
From: <bm...@ca...> - 2007-05-21 21:37:25
|
Quoting J=C3=A9r=C3=B4me <rom...@ya...>: > I will add a date field on RepoRef (with Call number and media type) > Also, a place field could be an other improvement. > OK, too many fields may lose user. But you could have the same source on > differents dates of search. Is it useful ? ??? repository is a place where sources are kept! In reporef there is no need o= f place or type or date. Am I missing something? Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <rom...@ya...> - 2007-05-21 22:32:05
|
>> I will add a date field on RepoRef (with Call number and media type) >> Also, a place field could be an other improvement. >> OK, too many fields may lose user. But you could have the same source on >> differents dates of search. Is it useful ? > > ??? > repository is a place where sources are kept! In reporef there is no need o > f > place or type or date. > > Am I missing something? > > Benny This will be a feature request... GRAMPS uses RepoRef with Sources Objects (his call number and type on repository). If you have a (quote ?) or book reference/number, this will be a storage on RepoRef as call number on repository. And if you search a source on a repository, we might add "search information" : date of search and place where source take place. Ex: 1. today (22/05/2007), I find a birth certificate (source) on a repository. 2. Source classified here since 1950. 3. The repository is county archive but the certificate was written somewhere else on a previous date (place: ploumnelherison - date: 1823) 4. I go to ploumnelherison and get a copy of certificate Source : birth certificate -1823 Repository : county archives, address, call number city of ploumnelherison, address, call number will be Repository : county archives, address, (22/05/2007), call number (1950->2007), source take place: ploumnelherison city of ploumnelherison, address, (22/05/2007), call number (1823->2007), source take place: ploumnelherison If in one century, somebody connects my data, then his research will be simplified :) And it is easier to begin again if there is an error ;) I agree, "source take place" should be the event place and GRAMPS is not an certificate editor but as genealogists we need all source informations !!! I always have informations which I could seize in GRAMPS (data key-value) but that I will not make ... That must make seven years that I make genealogy as an amateur and I don't remember my first sources, those which one raises partially because we are very glad to find something :( |
From: <bm...@ca...> - 2007-05-22 07:25:16
|
Jerome, I understand where you want to go to, but requesting new fields is a big st= ep. In my view new fields are only really useful if you will need to filter/sea= rch on them. What you want is very specialized, and there will be little reason to filter on it. So why not add that information as a note? With multiple notes in 2.3 y= ou can have a specific note-type for that. Furthermore, for the example you give, you should make two repositories, one for the repository where you found it originally, and one for ploumnelherison where you get the certificate. The source is then added in both repositories, and there is no need to add place (is in the repository address) or date (you c= an add that in a note). If you really, really want to know when you did some action, you can add that as events to yourself actually (event: look up source, go to work, mail gramps list ;-D ...) Benny Quoting J=E9r=F4me <rom...@ya...>: >>> I will add a date field on RepoRef (with Call number and media type) >>> Also, a place field could be an other improvement. >>> OK, too many fields may lose user. But you could have the same source o= n >>> differents dates of search. Is it useful ? >> >> ??? >> repository is a place where sources are kept! In reporef there is no nee= d o >> f >> place or type or date. >> >> Am I missing something? >> >> Benny > > This will be a feature request... > > GRAMPS uses RepoRef with Sources Objects (his call number and type on > repository). > > If you have a (quote ?) or book reference/number, this will be a storage > on RepoRef as call number on repository. > > And if you search a source on a repository, we might add "search > information" : date of search and place where source take place. > > Ex: > 1. today (22/05/2007), I find a birth certificate (source) on a repositor= y. > 2. Source classified here since 1950. > 3. The repository is county archive but the certificate was written > somewhere else on a previous date (place: ploumnelherison - date: 1823) > 4. I go to ploumnelherison and get a copy of certificate > > > Source : birth certificate -1823 > Repository : > county archives, address, call number > city of ploumnelherison, address, call number > > will be > > Repository : > county archives, address, (22/05/2007), call number (1950->2007), source > take place: ploumnelherison > city of ploumnelherison, address, (22/05/2007), call number > (1823->2007), source take place: ploumnelherison > > If in one century, somebody connects my data, then his research will be > simplified :) > And it is easier to begin again if there is an error ;) > > I agree, "source take place" should be the event place and GRAMPS is not > an certificate editor but as genealogists we need all source > informations !!! I always have informations which I could seize in > GRAMPS (data key-value) but that I will not make ... > > That must make seven years that I make genealogy as an amateur and I > don't remember my first sources, those which one raises partially > because we are very glad to find something :( > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: <rom...@ya...> - 2007-05-22 11:02:25
|
Benny, > In reporef there is no need of place or type or date. t0 = first time for source (when source appears) t1 = date of your search p0 = place where source take place cn = call number ref(t1)= reference for own classification In my view, most repositories uses : cn(t1) = (t0 + p0)* rf a physical source or a space-time reference mark ? |
From: <sk...@ac...> - 2007-05-22 07:45:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jerome, > Then we should move the field from SourceReference to Source (with > Title, Author, etc...) > Date of publication will be the same for all related object !!! In my database, this is simply part of the publication field, such as "Bonnier, Stockholm, 1923". Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUp+rzv8VI4RnlpQRAiVYAJ93eJE+F1Yk8NqHwljMdOZ35YyXwACggyRs iUzrVLSq5AvEPLTItfiHCH0= =2ET0 -----END PGP SIGNATURE----- |
From: <rom...@ya...> - 2007-05-22 10:01:32
|
Stefan, >> Date of publication will be the same for all related object !!! > In my database, this is simply part of the publication field, such as > "Bonnier, Stockholm, 1923". Then you don't use GRAMPS date field on SourceRef. +1 ;) Brian, > there is no need to add place (is in the repository address) Place will be the the place where the source was written before storage on repository. True, this could be sometimes, an other duplicated entry (=place event). > In my view new fields are only really useful if you will need to filter/search on them. Currently, there is some fields without filter ability (date on SourceRef, comments, volume/page, etc ...) To filter sources having the same place could be like to filter event places but for search !!! > So why not add that information as a note? With multiple notes in 2.3 you can have a specific note-type for that It is awaited :) > Furthermore, for the example you give, you should make two repositories, one for the repository where you found it originally, and one for ploumnelherison where you get the certificate. Sorry, I made a large spelling mistake ... Source : birth certificate -1823 Repository : county archives, address, call number city of ploumnelherison, address, call number <=> Source : birth certificate -1823 Repositor*ies* : county archives, address, call number city of ploumnelherison, address, call number > If you really, really want to know when you did some action, you can add that as events to yourself actually (event: look up source, go to work, mail gramps list ;-D ...) Yes, that's a solution ... I should add a source on my events ? S0001- today - Jerome's search on county archives OK, I start to implement a calendar/agenda into GRAMPS editor !!! ;) Seriously, this is a complicated subject : *Bibliography in reports (display of source information)* Maybe users need 'tooltips' on source fields. It could have a mixture if they did not keep same logic for all seizures :( |
From: <rom...@ya...> - 2007-05-22 10:08:58
|
Benny, Sorry, I confused you with brian!!! ------------------------------------------------------------ Stefan, >> Date of publication will be the same for all related object !!! > In my database, this is simply part of the publication field, such as > "Bonnier, Stockholm, 1923". Then you don't use GRAMPS date field on SourceRef. +1 ;) Benny, > there is no need to add place (is in the repository address) Place will be the the place where the source was written before storage on repository. True, this could be sometimes, an other duplicated entry (=place event). > In my view new fields are only really useful if you will need to filter/search on them. Currently, there is some fields without filter ability (date on SourceRef, comments, volume/page, etc ...) To filter sources having the same place could be like to filter event places but for search !!! > So why not add that information as a note? With multiple notes in 2.3 you can have a specific note-type for that It is awaited :) > Furthermore, for the example you give, you should make two repositories, one for the repository where you found it originally, and one for ploumnelherison where you get the certificate. Sorry, I made a large spelling mistake ... Source : birth certificate -1823 Repository : county archives, address, call number city of ploumnelherison, address, call number <=> Source : birth certificate -1823 Repositor*ies* : county archives, address, call number city of ploumnelherison, address, call number > If you really, really want to know when you did some action, you can add that as events to yourself actually (event: look up source, go to work, mail gramps list ;-D ...) Yes, that's a solution ... I should add a source on my events ? S0001- today - Jerome's search on county archives OK, I start to implement a calendar/agenda into GRAMPS editor !!! ;) Seriously, this is a complicated subject : *Bibliography in reports (display of source information)* Maybe users need 'tooltips' on source fields. It could have a mixture if they did not keep same logic for all seizures :( |
From: <sk...@ac...> - 2007-05-22 18:46:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Sorry, I confused you with brian!!! Velease Bvian! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUzpmzv8VI4RnlpQRAr6WAJ91nj2A9u7llo+QuCj6MNScio5MaQCgl8xj hqP2SnkYMyXMGdhSa4ChnTc= =RdTs -----END PGP SIGNATURE----- |
From: <rom...@ya...> - 2007-05-22 19:13:09
|
>> Sorry, I confused you with brian!!! > Velease Bvian! Forgive me, I post to mailing list :-[ A punishment for sending emails during job ... |
From: Brian M. <br...@gr...> - 2007-05-23 03:56:24
|
Benny, >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. > Wonderful insight. Thanks for sharing that. I learn something new every day. >Furthermore, remember, sourceref is about how you use the source, so >publication >date/info of the source *does not belong there*. That should go in the source >object, the same for text, eg: "Published by John Whiley and Co., 2005". >Sourceref is about how to work with the source to find the info of the person >you are looking at in this source. Another excellent point. I agree completely. ~Brian |
From: <bm...@ca...> - 2007-05-23 08:00:12
|
Quoting Brian Matherly <br...@gr...>: > Wonderful insight. Thanks for sharing that. I learn something new every day. > Glad to be of help. Actually, GEDCOM provides some fields that gramps has not implemented yet: A source can have an EVEN tag listing the events that are in a source. Eg marriage acts would have marriage as event connected to the source, same for census. This is again bad design on the part of GEDCOM, the reference tab in GRAMPS of the source nicely shows already in which events a source is used. GEDCOM also has a PLAC tag with source, to list the juristiction of a source, so eg Source Census of Wales, would be connected to Place 'Wales'. Civil marriages of Nashville, would be connected to Nashville. Like that one can find all sources about a juristiction you use in your research. The above clearly indicates that GEDCOM is geared towards the following types of sources: marriage/birth/death acts and census. As for books, ... these extra tags have no direct meaning. Last but not least, source has the GEDCOM attribute TEXT. I find it *very* annoyinhg that text has been a field in sourceref, while the text field in source has been left out of gramps. This has created all sorts of misunderstanding with users, making them use sourceref in the wrong way. Other tags are also present, see http://homepages.rootsweb.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_RECORD Well, another rant about the fact we really need to clean up sources in GRAMPS and use the GEDCOM standard better, while extending it at the same time :-) Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |