Sources and sourceref - part 2
Locked
 
|
I had a discussion with Don on ICQ and had his head spinning. So here
goes an attempt in a nicely readable mail. It is aimed at the developers, to decide future direction of development. This is request for a larger change in GRAMPS workflow, so read carefully, as to have a clear understanding of the why and how. Sources are a very important part of the research, so changes should be well argued and thought through. As I explained in an earlier post, I think the system of storing sources is confusing and does not give the researcher sufficient freedom. Many users also think it too complicated with every object having a source tab, Don told me. I will do my explaining for the 2.3 version, so multiple notes is supposed to be implemented. What is the problem with the present sourceref storage? Let's take Richards census example: http://www.gramps-project.org/wiki/index.php?title=Recording_UK_Census_data and consider a *very* thorough researcher: he takes pictures of every page of the census he uses (from microfilm, http://www.gramps-project.org/wiki/index.php?title=Image:Census_image_1.png), perhaps even a foto of only the section he is interested in. He also makes a transcript of the source which essentially is an ascii file. However, using an ascii file for the transcript is bothersome, as that means an extra step in handling the source info (+ data outside of gramps database), so the researcher wants to add the transcript in a note. The problem is the following. As is clear from the census page, the sourceref is made once, and then copied to the scratchpad. From there it is copied to every item added due this this sourceref, via drag and drop in the source information. Eg, the census says John Martin, blind, so you add an attribute (key=blind, value=yes) and drop the sourceref in the source tab of the attribute. 4 years later, you or a fellow researcher go over the person John Martin, and see he is blind, while you have in your hands a painting of him! You want to know why you said he was blind: --> open attribute --> open sourceref of attribute --> read the text of the census in the note, and perhaps open the media object to see if you not misread the text. Suppose the text says 'blond', you made a translation error! The problem with the above workflow is that if you have recorded 40 families of that census, retrieving the information might be difficult. If you added the text of the census to the sourceref, it is present in all of the 30 sourceref you dragged and dropped from the original sourceref, and you will find the information easily. However, if you now have to change blind--> blond, you have a long and annoying work ahead of you of finding the sourceref and changing them all! If you added the text of the census to the source instead of the sourceref, you have the problem of finding this text. Having 40 census entries in the notes makes it complicated finding the one which is the transcript of this specific source. Moreover, the source might have an orignal text, a translation and other notes concerning this specific sourceref, making finding the information bothersome. Another complication is that having all data in the source instead of in a sourceref, makes it difficult to produce a report with all relevant information of a person. If you print the detailed information of a person John Martin, having the transcript of the census record of his family is interesting. You don't want the information of all 40 families you have in your database connected to this census source. I hope the problem in the workflow is somewhat clear with the above example. My two propositions to improve this situation in GRAMPS: 1. Minimal change to the code ----------------------------- In this proposition the datamodel remains the same, so: source 1 ------> n sourceref 1 ----- 1 object (person, attribute, event, ...) The workflow is: --> the source is the document: census 1881, ... It contains all media objects, and every piece you take a transcript from is a separate note. So we have a source with many media objects (every page), and then many multiple notes, at least one for every family. The following is offered to better retrieve the data in the source: * In sourceref, the tab Text is deprecated, as it does not fit with above workflow. Only Notes section remains in the reference information * However, sourceref contains a connection to the source note id which is relevant for this object. So eg, the source census 1881 has in the notes section 40 transcripts of recorded families. In the sourceref, a new field is offered: relevant sourcenote, and the user can select note N441, which is the note with transcript of family of John Martin. This comes in the place of the Text tab in 2.2 Perhaps even multiple notes can be selected. * User himself has to couple media objects a second time to the sourceref. An alternative would be to do the same for media objects: select the media objects of the source which are relevant for the sourceref. Disadvantage: although gramps chooses for a workflow, which is good, and would help making clear tutorials, fixed direction of development, the problem in essense remains: the selected notes/media are kept double in all sourceref to the same part of the source, so doing a change is very problematic (eg, add a better picture of that microfilm page, how to add that info to all relevant sourceref?). 2. shared sourceref ------------------- In this proposition, sourceref is made a primary object that an object can share, but is unique to a source source 1 -----> n sourceref n <----> n object (person, attribute, event, ...) The meaning of sourceref is: ' part of the source wich is self-contained' So a sourceref is for example: * an birth-act * one census recorded family * one result of a search on a webpage * one paragraph of a diary which is of interest The sourceref contains a link to the source (the bottom part of present sourceref) and the attributes of the sourceref are: General Tab: * position in the source: This is the present Volume/Page field, but is added with: Number (for acts), microfilm, paragraph, ... * Date: some sources are logs, with every entry a date. So date is part of the position in the source, but has extra meaning, meriting it's own attribute. I think it is best called 'Log Date' * Description: optional, for an act, writing eg marriage of A and B, makes retrieval more easy. * Confidence * Public/Private Text/Transcript tab: * language: the language of the text * one note: the transcript of the sourceref Translation tab: * one note : a translation to the local language of the researcher Notes: * multiple notes: these notes can be made deductions from the text, remarks on the conditions of the sourceref, .... The shared sourceref information allows for better retrieval of data on the lowest source level. Some extra possibilities: -> the source editor can have a tab 'Parts' listing all sourceref meaningfully (so sorted on the given position data of the sourceref in the source). I would leave the references part, but this should in fact no longer be the objects linked to source (which it is now as sourceref is a secondary object), but instead, all objects linked to source via a sourceref. -> selection of a source from another attribute: A list of sources is given, with child nodes all existing sourceref oredered on position in the source. Technically, every source would have an empty sourceref, which is used to link the source to an object. As soon a the user types some information, this becomes a real sourceref I think everybody will agree that in a lot of cases the sourceref info is empty now. Note that conversion of present day database to this would not be overly difficult: all sourceref are collected, and the equal ones merged in one new sourceref object. More problematic is the fact that many people have databases in which the sources are actually sourceref due to the fact that is easier working in GRAMPS. So some tool to merge sources is needed, in which one source is the main source, and the other source is used to create a new sourceref. The existing merge dialog for persons the user is used to could be used for that. So, hopefully this text makes that gray matter work a bit. It is clear my preference goes to the second proposed 'solution'. I'd love to program parts of this, but of course, I can't do it alone, and I will only start if you guys think this is a valid improvement over the workflow of today (and even then, I have no idea how the database level of gramps works :-( ... ). However, I think if we start 2.3 with multiple notes, the confusion on sources and sourceref will become even larger. I personally don't want to make a tutorial on how to enter some common Belgian sources because frankly, I don't think the way I enter my information now is a good way. Deciding to do this for 2.3 would allow some rationalization in the reports on handling multiple notes, which is still a big work ahead of us. Good night, Benny ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Sources and sourceref - part 2
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Benny and all others, > As I explained in an earlier post, I think the system of storing sources > is confusing and does not give the researcher sufficient freedom. Many > users also think it too complicated with every object having a source > tab, Don told me. This is an interesting issue to me, since I have had to create my own database to overcome the limitations of GRAMPS source handling. I don't know if the suggested changes will solve all my issues, but let me explain how I work with sources and see if this somehow can be implemented in GRAMPS. In Sweden, the church has made records of the population since late 17th century (this became mandatory in law 1682). Those church records include lists of births, deaths and, later, households (to record communion and knowledge in christianity). Those last "catechetical meetings records" include, among other information, the persons name, birth (where and when), when the person moved to the current location and from where, and when the person left the current location and where he or she went. This way, the catechetical meetings records can be used to track a person from birth to death, following his or hers moves throughout life. This usually spans over several pages and source volumes. To record this information in GRAMPS, I use "residence" events and attach all sources relevant to this event (which can be several, if the person lived at the same place for decades). If possible, I use shared events for all family members. However, when adding this information into GRAMPS, I would like to work the other way round, that is, add all relevant information from a source page without having to add sources and events to every single person. This is why I have created a table like: Src Name Born Moved in Moved out A p.10 Anders Andersson 1822 1860 1863 Kristina Johansson (wife) 1829 1860 1863 Per Andersson (son) 1852 1860 1863 B p.22 Anders Andersson 1822 1863 - Kristina Johansson (wife) 1829 1863 - Per Andersson (son) 1852 1863 - (The table is extremely simplified, but illustrates how information is organized; the family of Anders Andersson, mentioned on page 10 in source A, moved to another location in 1863 mentioned on page 22 in source B.) This table can then be sorted on name and 'moved in' date, and - voilá - i can immediately see how a person has moved throughout his life. This type of source tracking is impossible with GRAMPS. It is also impossible to add sources in an effective way. If i understand Benny right, the above table would constitute two unique sourcerefs, linked to source A and B, respectively, and linked to the three persons Anders, Kristina and Per. This could solve my source problem, if GRAMPS also allowed me to use the following workflow: 1. Adding several sources and sourcerefs with transcriptions of the information (like the table above). 2. Searching through the sourcerefs for a particular name (using regular expressions to catch different spellings and include birth dates). 3. Drag and drop the found (filtered) sourcerefs to the relevant person (or events of the relevant person; a real whish-list, by the way, would be an individual time-line for a person with all events from birth to death marked, wich possibility to drop sources on the graphically represented events). My thoughts on sources for today... Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLxlLzv8VI4RnlpQRAodxAJ962vc+g/tae+DMfWBwJTWwkEZljwCgiPw7 RaXksXn6Z6nTSUpqp/sp3Bk= =UNVw -----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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Sources and sourceref - part 2
|
In reply to this post by bm-7
Benny,
I think I like your second proposal more. I wonder, however how it would behave with a source I use that is a 8 volume treatise on the families of a certain geographical area, all in all, over 2000 pages. The family treee I am build overlaps currently an estimated 20% of that source and I think that when I am done the coverage may be easily in the 40 to 50% range. I wonder what the interface could be for finding the correct source reference to use during data entry. Currently there is no problem because source references are not shared at all. Were they to be shared, they would have to be found first. Handling hundred of source is not easy currently either. What I do when doing intensive work with a source is rename it by prefixing it with something like "AAAAA" that makes it come first. This way I don't have to find it during entry. Then I have to remember to rename it back. I guess a good improvement would be to default source selection to the source used last instead of the first one in alphabetical order. Maybe this would help with source references too, but I don't quite picture the use cases yet. Regards, Julio 2007/4/24, bm <[hidden email]>: > I had a discussion with Don on ICQ and had his head spinning. So here > goes an attempt in a nicely readable mail. It is aimed at the > developers, to decide future direction of development. > > This is request for a larger change in GRAMPS workflow, so read > carefully, as to have a clear understanding of the why and how. Sources > are a very important part of the research, so changes should be well > argued and thought through. > > As I explained in an earlier post, I think the system of storing sources > is confusing and does not give the researcher sufficient freedom. Many > users also think it too complicated with every object having a source > tab, Don told me. > > I will do my explaining for the 2.3 version, so multiple notes is > supposed to be implemented. > > What is the problem with the present sourceref storage? > > Let's take Richards census example: > http://www.gramps-project.org/wiki/index.php?title=Recording_UK_Census_data > and consider a *very* thorough researcher: he takes pictures of every > page of the census he uses (from microfilm, > http://www.gramps-project.org/wiki/index.php?title=Image:Census_image_1.png), > perhaps even a foto of only the section he is interested in. > He also makes a transcript of the source which essentially is an ascii > file. However, using an > ascii file for the transcript is bothersome, as that means an extra step > in handling the source info (+ data outside of gramps database), so the > researcher wants to add the transcript in a note. > > The problem is the following. As is clear from the census page, the > sourceref is made once, and then copied to the scratchpad. From there it > is copied to every item added due this this sourceref, via drag and drop > in the source information. > > Eg, the census says John Martin, blind, so you add an attribute > (key=blind, value=yes) and drop the sourceref in the source tab of the > attribute. > > 4 years later, you or a fellow researcher go over the person John > Martin, and see he is blind, while you have in your hands a painting of > him! You want to know why you said he was blind: > --> open attribute > --> open sourceref of attribute > --> read the text of the census in the note, and perhaps open the > media object > to see if you not misread the text. > Suppose the text says 'blond', you made a translation error! > > The problem with the above workflow is that if you have recorded 40 > families of that census, retrieving the information might be difficult. > If you added the text of the census to the sourceref, it is present in > all of the 30 sourceref you dragged and dropped from the original > sourceref, and you will find the information easily. > However, if you now have to change blind--> blond, you have a long and > annoying work ahead of you of finding the sourceref and changing them all! > > If you added the text of the census to the source instead of the > sourceref, you have the problem of finding this text. Having 40 census > entries in the notes makes it complicated > finding the one which is the transcript of this specific source. > Moreover, the source might have an orignal text, a translation and other > notes concerning this specific sourceref, making finding the information > bothersome. > > Another complication is that having all data in the source instead of in > a sourceref, makes it difficult to produce a report with all relevant > information of a person. If you print the > detailed information of a person John Martin, having the transcript of > the census record of his family is interesting. You don't want the > information of all 40 families you have in your database connected to > this census source. > > > I hope the problem in the workflow is somewhat clear with the above example. > > My two propositions to improve this situation in GRAMPS: > > 1. Minimal change to the code > ----------------------------- > In this proposition the datamodel remains the same, so: > > source 1 ------> n sourceref 1 ----- 1 object (person, attribute, > event, ...) > > The workflow is: > --> the source is the document: census 1881, ... It contains all media > objects, and every piece you take a transcript from is a separate note. > So we have a source with many media objects (every page), and then many > multiple notes, at least one for every family. > > The following is offered to better retrieve the data in the source: > * In sourceref, the tab Text is deprecated, as it does not fit with > above workflow. Only Notes section remains in the reference information > * However, sourceref contains a connection to the source note id which > is relevant for this object. > So eg, the source census 1881 has in the notes section 40 transcripts of > recorded families. In the sourceref, a new field is offered: relevant > sourcenote, and the user can select note N441, which is the note with > transcript of family of John Martin. > This comes in the place of the Text tab in 2.2 Perhaps even multiple > notes can be selected. > * User himself has to couple media objects a second time to the > sourceref. An alternative would be to do the same for media objects: > select the media objects of the source which are relevant for the sourceref. > > Disadvantage: although gramps chooses for a workflow, which is good, and > would > help making clear tutorials, fixed direction of development, the problem > in essense remains: the selected notes/media are kept double in all > sourceref to the same part of the source, so doing a change is very > problematic (eg, add a better picture of that microfilm page, how to add > that info to all relevant sourceref?). > > > 2. shared sourceref > ------------------- > In this proposition, sourceref is made a primary object that an object can > share, but is unique to a source > source 1 -----> n sourceref n <----> n object (person, attribute, > event, ...) > > The meaning of sourceref is: ' part of the source wich is self-contained' > So a sourceref is for example: > * an birth-act > * one census recorded family > * one result of a search on a webpage > * one paragraph of a diary which is of interest > > The sourceref contains a link to the source (the bottom part of present > sourceref) and the attributes of the sourceref are: > > General Tab: > * position in the source: This is the present Volume/Page field, but > is added with: Number (for acts), microfilm, paragraph, ... > * Date: some sources are logs, with every entry a date. So date is > part of the position in the source, but has extra meaning, meriting it's > own attribute. I think it is best called 'Log Date' > * Description: optional, for an act, writing eg marriage of A and B, > makes retrieval more easy. > * Confidence > * Public/Private > > Text/Transcript tab: > * language: the language of the text > * one note: the transcript of the sourceref > > Translation tab: > * one note : a translation to the local language of the researcher > > Notes: > * multiple notes: these notes can be made deductions from the text, > remarks on the conditions of the sourceref, .... > > The shared sourceref information allows for better retrieval of data on > the lowest source level. Some extra possibilities: > -> the source editor can have a tab 'Parts' listing all sourceref > meaningfully (so sorted on the given position data of the sourceref in > the source). I would leave the references part, but this should in fact > no longer be the objects linked to source (which it is now as sourceref > is a secondary object), but instead, all objects linked to source via a > sourceref. > > -> selection of a source from another attribute: A list of sources is > given, with child nodes all existing sourceref oredered on position in > the source. > Technically, every source would have an empty sourceref, which is used > to link the source to an object. As soon a the user types some > information, this becomes a real sourceref I think everybody will agree > that in a lot of cases the sourceref info is empty now. > > Note that conversion of present day database to this would not be overly > difficult: all sourceref are collected, and the equal ones merged in one > new sourceref object. More problematic is the fact that many people have > databases in which the sources are actually sourceref due to the fact > that is easier working in GRAMPS. So some tool to merge sources is > needed, in which one source is the main source, and the other source is > used to create a new sourceref. The existing merge dialog for persons > the user is used to could be used for that. > > So, hopefully this text makes that gray matter work a bit. It is clear > my preference goes to the second proposed 'solution'. I'd love to > program parts of this, but of course, I can't do it alone, and I will > only start if you guys think this is a valid improvement over the > workflow of today (and even then, I have no idea how the database level > of gramps works :-( ... ). > However, I think if we start 2.3 with multiple notes, the confusion on > sources and sourceref will become even larger. I personally don't want > to make a tutorial on how to enter some common Belgian sources because > frankly, I don't think the way I enter my information now is a good way. > Deciding to do this for 2.3 would allow some rationalization in the > reports on handling multiple notes, which is still a big work ahead of us. > > Good night, > Benny > > ------------------------------------------------------------------------- > 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 > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
Hi Julio,
From a library part of view, your 8 volumes are 8 sources. So you have like 40% that is 800 pages, so 100 pages you use per volume. In my proposition, from a UI point of view not too much changes, only sourceref is not kept double anymore, so dragging and dropping a sourceref would NOT make a new sourceref, but would use the existing sourceref. I suppose in a treatise, a sourceref would be a section or a paragraph. For selection of sources: now you select the volume you use. In my proposition, you would select the volume, or one of the existing sourceref (just as toda y, the scratchpad is the most usefull tool for this, instead of renaming). So you would have per volume some 100 sourceref, linking to perhaps 500 people/events. Every sourceref could be meaningfull, empty sourceref is not shown. I would set in the source on what sourceref should be ordered. Eg, the sour ce could say: order on date (for acts, diaries), order on page (reference work s), order on number (civil state entries), order on section (books), ... Then on selecting a sourceref, you get a list of sources, with childnodes y ou can expand, with the childnodes sorted in the requested order. It is true that if sourceref is shared, you need to select the correct one, but this is only true for non-empty sourceref. For a non-empty sourceref, where you wrote a text of your treatise in the text tab, would you not prefer to have that sourceref shared, instead of making a new one, hunting down a previous use so you have the same data you can enter again? The advantage of the proposition is also in the inverse way of using the source: open the source, go to the new sourceref tab, order on page, and you see all the sections of the volume you have referenced. Another advantage is you can make a sourceref without linking it to anything. So you make a transcript of a source in a sourceref, go to bed, continue the d ay after, copy to scratchpad, and start entering the people/events as they are deduced from the sourceref, using the scratchpad to quickly link to this source without the need to do lookup. About your idea to put last used source at the top of the selection. It is better to use the scratchpad, and use an existing sourceref now. If you wri te in the sourceref: page 102, using the scratchpad will at least make sure pa ge 102 is everywhere you use the sourceref, whereas using last used selected source will give you an empty sourceref always. Benny Quoting Julio Sánchez <[hidden email]>: > Benny, > > I think I like your second proposal more. I wonder, however how it > would behave with a source I use that is a 8 volume treatise on the > families of a certain geographical area, all in all, over 2000 pages. > The family treee I am build overlaps currently an estimated 20% of > that source and I think that when I am done the coverage may be easily > in the 40 to 50% range. I wonder what the interface could be for > finding the correct source reference to use during data entry. > Currently there is no problem because source references are not shared > at all. Were they to be shared, they would have to be found first. > > Handling hundred of source is not easy currently either. What I do > when doing intensive work with a source is rename it by prefixing it > with something like "AAAAA" that makes it come first. This way I > don't have to find it during entry. Then I have to remember to rename > it back. I guess a good improvement would be to default source > selection to the source used last instead of the first one in > alphabetical order. Maybe this would help with source references too, > but I don't quite picture the use cases yet. > > Regards, > > Julio > > 2007/4/24, bm <[hidden email]>: >> I had a discussion with Don on ICQ and had his head spinning. So here >> goes an attempt in a nicely readable mail. It is aimed at the >> developers, to decide future direction of development. >> >> This is request for a larger change in GRAMPS workflow, so read >> carefully, as to have a clear understanding of the why and how. Sources >> are a very important part of the research, so changes should be well >> argued and thought through. >> >> As I explained in an earlier post, I think the system of storing sources >> is confusing and does not give the researcher sufficient freedom. Many >> users also think it too complicated with every object having a source >> tab, Don told me. >> >> I will do my explaining for the 2.3 version, so multiple notes is >> supposed to be implemented. >> >> What is the problem with the present sourceref storage? >> >> Let's take Richards census example: >> http://www.gramps-project.org/wiki/index.php?title=Recording_UK_Census >> and consider a *very* thorough researcher: he takes pictures of every >> page of the census he uses (from microfilm, >> http://www.gramps-project.org/wiki/index.php?title=Image:Census_image_ 1.png), >> perhaps even a foto of only the section he is interested in. >> He also makes a transcript of the source which essentially is an ascii >> file. However, using an >> ascii file for the transcript is bothersome, as that means an extra step >> in handling the source info (+ data outside of gramps database), so the >> researcher wants to add the transcript in a note. >> >> The problem is the following. As is clear from the census page, the >> sourceref is made once, and then copied to the scratchpad. From there it >> is copied to every item added due this this sourceref, via drag and drop >> in the source information. >> >> Eg, the census says John Martin, blind, so you add an attribute >> (key=blind, value=yes) and drop the sourceref in the source tab of t >> attribute. >> >> 4 years later, you or a fellow researcher go over the person John >> Martin, and see he is blind, while you have in your hands a painting of >> him! You want to know why you said he was blind: >> --> open attribute >> --> open sourceref of attribute >> --> read the text of the census in the note, and perhaps open the >> media object >> to see if you not misread the text. >> Suppose the text says 'blond', you made a translation error! >> >> The problem with the above workflow is that if you have recorded 40 >> families of that census, retrieving the information might be difficult. >> If you added the text of the census to the sourceref, it is present in >> all of the 30 sourceref you dragged and dropped from the original >> sourceref, and you will find the information easily. >> However, if you now have to change blind--> blond, you have a long and >> annoying work ahead of you of finding the sourceref and changing them al >> >> If you added the text of the census to the source instead of the >> sourceref, you have the problem of finding this text. Having 40 census >> entries in the notes makes it complicated >> finding the one which is the transcript of this specific source. >> Moreover, the source might have an orignal text, a translation and other >> notes concerning this specific sourceref, making finding the information >> bothersome. >> >> Another complication is that having all data in the source instead of in >> a sourceref, makes it difficult to produce a report with all relevant >> information of a person. If you print the >> detailed information of a person John Martin, having the transcript of >> the census record of his family is interesting. You don't want the >> information of all 40 families you have in your database connected to >> this census source. >> >> >> I hope the problem in the workflow is somewhat clear with the above exam >> >> My two propositions to improve this situation in GRAMPS: >> >> 1. Minimal change to the code >> ----------------------------- >> In this proposition the datamodel remains the same, so: >> >> source 1 ------> n sourceref 1 ----- 1 object (person, attribute, >> event, ...) >> >> The workflow is: >> --> the source is the document: census 1881, ... It contains all media >> objects, and every piece you take a transcript from is a separate note. >> So we have a source with many media objects (every page), and then many >> multiple notes, at least one for every family. >> >> The following is offered to better retrieve the data in the source: >> * In sourceref, the tab Text is deprecated, as it does not fit with >> above workflow. Only Notes section remains in the reference information >> * However, sourceref contains a connection to the source note id which >> is relevant for this object. >> So eg, the source census 1881 has in the notes section 40 transcripts of >> recorded families. In the sourceref, a new field is offered: relevant >> sourcenote, and the user can select note N441, which is the note with >> transcript of family of John Martin. >> This comes in the place of the Text tab in 2.2 Perhaps even multiple >> notes can be selected. >> * User himself has to couple media objects a second time to the >> sourceref. An alternative would be to do the same for media objects: >> select the media objects of the source which are relevant for the source >> >> Disadvantage: although gramps chooses for a workflow, which is good, and >> would >> help making clear tutorials, fixed direction of development, the problem >> in essense remains: the selected notes/media are kept double in all >> sourceref to the same part of the source, so doing a change is very >> problematic (eg, add a better picture of that microfilm page, how to add >> that info to all relevant sourceref?). >> >> >> 2. shared sourceref >> ------------------- >> In this proposition, sourceref is made a primary object that an object c >> share, but is unique to a source >> source 1 -----> n sourceref n <----> n object (person, attribute, >> event, ...) >> >> The meaning of sourceref is: ' part of the source wich is self-contained ' >> So a sourceref is for example: >> * an birth-act >> * one census recorded family >> * one result of a search on a webpage >> * one paragraph of a diary which is of interest >> >> The sourceref contains a link to the source (the bottom part of present >> sourceref) and the attributes of the sourceref are: >> >> General Tab: >> * position in the source: This is the present Volume/Page field, but >> is added with: Number (for acts), microfilm, paragraph, ... >> * Date: some sources are logs, with every entry a date. So date is >> part of the position in the source, but has extra meaning, meriting it's >> own attribute. I think it is best called 'Log Date' >> * Description: optional, for an act, writing eg marriage of A and B, >> makes retrieval more easy. >> * Confidence >> * Public/Private >> >> Text/Transcript tab: >> * language: the language of the text >> * one note: the transcript of the sourceref >> >> Translation tab: >> * one note : a translation to the local language of the researcher >> >> Notes: >> * multiple notes: these notes can be made deductions from the text, >> remarks on the conditions of the sourceref, .... >> >> The shared sourceref information allows for better retrieval of data on >> the lowest source level. Some extra possibilities: >> -> the source editor can have a tab 'Parts' listing all sourceref >> meaningfully (so sorted on the given position data of the sourceref in >> the source). I would leave the references part, but this should in fact >> no longer be the objects linked to source (which it is now as sourceref >> is a secondary object), but instead, all objects linked to source via a >> sourceref. >> >> -> selection of a source from another attribute: A list of sources is >> given, with child nodes all existing sourceref oredered on position in >> the source. >> Technically, every source would have an empty sourceref, which is used >> to link the source to an object. As soon a the user types some >> information, this becomes a real sourceref I think everybody will agree >> that in a lot of cases the sourceref info is empty now. >> >> Note that conversion of present day database to this would not be overly >> difficult: all sourceref are collected, and the equal ones merged in one >> new sourceref object. More problematic is the fact that many people have >> databases in which the sources are actually sourceref due to the fact >> that is easier working in GRAMPS. So some tool to merge sources is >> needed, in which one source is the main source, and the other source is >> used to create a new sourceref. The existing merge dialog for persons >> the user is used to could be used for that. >> >> So, hopefully this text makes that gray matter work a bit. It is clear >> my preference goes to the second proposed 'solution'. I'd love to >> program parts of this, but of course, I can't do it alone, and I will >> only start if you guys think this is a valid improvement over the >> workflow of today (and even then, I have no idea how the database level >> of gramps works :-( ... ). >> However, I think if we start 2.3 with multiple notes, the confusion on >> sources and sourceref will become even larger. I personally don't want >> to make a tutorial on how to enter some common Belgian sources because >> frankly, I don't think the way I enter my information now is a good way. >> Deciding to do this for 2.3 would allow some rationalization in the >> reports on handling multiple notes, which is still a big work ahead of u >> >> Good night, >> Benny >> >> ------------------------------------------------------------------------ - >> 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 >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
In reply to this post by Stefan Björk
Quoting Stefan Björk <[hidden email]>:
> This is an interesting issue to me, since I have had to create my own > database to overcome the limitations of GRAMPS source handling. I don't > know if the suggested changes will solve all my issues, but let me > explain how I work with sources and see if this somehow can be > implemented in GRAMPS. > > In Sweden, the church has made records of the population since late 17th > century (this became mandatory in law 1682). Those church records > include lists of births, deaths and, later, households (to record > communion and knowledge in christianity). Those last "catechetical > meetings records" include, among other information, the persons name, > birth (where and when), when the person moved to the current location > and from where, and when the person left the current location and where > he or she went. > > This way, the catechetical meetings records can be used to track a > person from birth to death, following his or hers moves throughout life. > This usually spans over several pages and source volumes. > > To record this information in GRAMPS, I use "residence" events and > attach all sources relevant to this event (which can be several, if the > person lived at the same place for decades). If possible, I use shared > events for all family members. > > However, when adding this information into GRAMPS, I would like to work > the other way round, that is, add all relevant information from a source > page without having to add sources and events to every single person. > This is why I have created a table like: > > Src Name Born Moved in Moved out > A p.10 Anders Andersson 1822 1860 1863 > Kristina Johansson (wife) 1829 1860 1863 > Per Andersson (son) 1852 1860 1863 > > B p.22 Anders Andersson 1822 1863 - > Kristina Johansson (wife) 1829 1863 - > Per Andersson (son) 1852 1863 - > > (The table is extremely simplified, but illustrates how information is > organized; the family of Anders Andersson, mentioned on page 10 in > source A, moved to another location in 1863 mentioned on page 22 in > source B.) > > This table can then be sorted on name and 'moved in' date, and - voilá > i can immediately see how a person has moved throughout his life. This > type of source tracking is impossible with GRAMPS. It is also impossible > to add sources in an effective way. > > If i understand Benny right, the above table would constitute two unique > sourcerefs, linked to source A and B, respectively, and linked to the > three persons Anders, Kristina and Per. Indeed, you could order it differently but that seems reasonable. You could make the sourceref before you create the persons or the events. > This could solve my source > problem, if GRAMPS also allowed me to use the following workflow: > > 1. Adding several sources and sourcerefs with transcriptions of the > information (like the table above). This would be possible, (and actually is already possible in sourceref now, see text tab). Having the sourceref shared would mean one place to keep transcript. Furthermore, there will be multiple notes, so you could make a custom type note "catechetical meeting", and then filter on that for reports. Of course, gramps stores text notes, not spreadsheets, so the functionality of a spreadsheet would not be available, but you could add a spreadsheet with al l recordings to the source off course. Personally, for overviewing a person, I would also use the residence event, and link the residence event to this source/sourceref. > > 2. Searching through the sourcerefs for a particular name (using regular > expressions to catch different spellings and include birth dates). This is might be possible today with filters. Having sourceref as primary object and shared would simplify filtering and using the data however. > > 3. Drag and drop the found (filtered) sourcerefs to the relevant person > (or events of the relevant person; a real whish-list, by the way, would > be an individual time-line for a person with all events from birth to > death marked, wich possibility to drop sources on the graphically > represented events). The drag and drop on a list of events, and opening the event editor adding the source to the sourcelist and opening a sourceref editor, would be a feature request. I'm afraid aunt martha would be mighty surprised if this happens b y accident :-) If sourceref is primary object, I would suggest to have them visible in the source view as child nodes to the source, so you can filter on it with the filter siderbar, and then use drag and drop as you can do today too. Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
In reply to this post by bm-7
People notify me they would like a real short version of what I mean, so here
goes: 1/sourceref are shared between objects, instead of being unique to an object 2/sourceref are ordered within sources based on position, which can be date (log, diary, act), number (civil status), section/paragraph (book), page (reference work) 3/Sourceref would have a specific meaning. It's definition: 'A part of the source wich is self-contained' Examples: a birth-act, one census recorded family, one result of a search on a webpage, one paragraph of a diary which is of interest, ... Today sourceref has two meaning: a part of a source (as illustrated by the text tab), and the reference to the source (as illustrated by it's nonshared status). In the proposal it would only be a part of a source, and the act of adding the part to an object means you reference that part. In a figure: source 1 -----> n sourceref n <----> n object (person, attribute, event, ...) I think this would simplify things for users, especially if sourceref are shown in the same view as sources giving visual meaning to the fact they are self-contained part. Technically, it is a big challenge of course. Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Sources and sourceref - part 2
|
|
In reply to this post by bm-5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 > Indeed, you could order it differently but that seems reasonable. You > could make > the sourceref before you create the persons or the events. This is often what I want to do. I usually want to work from the source or sourceref view and adding persons/events to the sourceref - not the other way round, as it currently is in GRAMPS (that is, adding sources to persons/events). >> 1. Adding several sources and sourcerefs with transcriptions of the >> information (like the table above). > > This would be possible, (and actually is already possible in sourceref > now, see > text tab). Having the sourceref shared would mean one place to keep > transcript. That is true, and I use the sourceref this way today. However, this is ineffective and tedious. I would make things easier if the sourceref was a self-containing object, as you propose. This way, I won't have to add this text/transcript to every single sourceref. Or going over them to fix errors... Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMKi+zv8VI4RnlpQRAhaqAKCii1/AmCKHoYqmoVScQes8RB8VzACfZkWE 10SqwXPo+xEh9jtHzcbomps= =M/9Y -----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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: SHORT VERSION Sources and sourceref - part 2
|
In reply to this post by bm-5
On Thursday 26 April 2007 09:41, [hidden email] wrote:
> People notify me they would like a real short version of what I mean, so > here goes: > > 1/sourceref are shared between objects, instead of being unique to an > object > > 2/sourceref are ordered within sources based on position, which can be date > (log, diary, act), number (civil status), section/paragraph (book), page > (reference work) > > 3/Sourceref would have a specific meaning. It's definition: 'A part of the > source wich is self-contained' Examples: a birth-act, one census recorded > family, one result of a search on a webpage, one paragraph of a diary which > is of interest, ... Today sourceref has two meaning: a part of a source (as > illustrated by the text tab), and the reference to the source (as > illustrated by it's nonshared status). In the proposal it would only be a > part of a source, > and the act of adding the part to an object means you reference that part. > > > In a figure: > source 1 -----> n sourceref n <----> n object (person, attribute, event, > ...) > > I think this would simplify things for users, especially if sourceref > are shown > in the same view as sources giving visual meaning to the fact they are > self-contained part. Technically, it is a big challenge of course. > > Benny This makes sense to me. I can see how it would improve some of my workflow too and it would make the Census example easier to explain to Aunt Martha. I guess we need an implementation plan now. Richard ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Quoting Richard Taylor <[hidden email]>:
> On Thursday 26 April 2007 09:41, [hidden email] wrote: >> People notify me they would like a real short version of what I mean, so >> here goes: >> >> 1/sourceref are shared between objects, instead of being unique to an >> object >> >> 2/sourceref are ordered within sources based on position, which can be date >> (log, diary, act), number (civil status), section/paragraph (book), page >> (reference work) >> >> 3/Sourceref would have a specific meaning. It's definition: 'A part of the >> source wich is self-contained' Examples: a birth-act, one census recorded >> family, one result of a search on a webpage, one paragraph of a diary which >> is of interest, ... Today sourceref has two meaning: a part of a source (as >> illustrated by the text tab), and the reference to the source (as >> illustrated by it's nonshared status). In the proposal it would only be a >> part of a source, >> and the act of adding the part to an object means you reference that part. >> >> >> In a figure: >> source 1 -----> n sourceref n <----> n object (person, attribute, event, >> ...) >> >> I think this would simplify things for users, especially if sourceref >> are shown >> in the same view as sources giving visual meaning to the fact they are >> self-contained part. Technically, it is a big challenge of course. >> >> Benny > > This makes sense to me. I can see how it would improve some of my > workflow too > and it would make the Census example easier to explain to Aunt Martha. > > I guess we need an implementation plan now. > > Richard > I have some ideas. I'll talk them through with Don on IRC if I can catch him this weekend. I suppose much depends on the timeframe Don has in his head for 2.3/2.4 If that has to be before summer, I don't think this can be included. On the other hand, developers are often more excited to code on features than to bugfixes. Benny ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------- 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 [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
«
Return to GRAMPS - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |