Quantcast

Sources and sourceref - part 2

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Sources and sourceref - part 2

bm-7
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Sources and sourceref - part 2

Stefan Björk
-----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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Sources and sourceref - part 2

Julio Sánchez-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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Sources and sourceref - part 2

bm-5
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
_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 t
he

>> 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
l!

>>
>> 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
ple.

>>
>> 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
ref.

>>
>> 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
an
>> 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
s.
>>
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Sources and sourceref - part 2

bm-5
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SHORT VERSION Sources and sourceref - part 2

bm-5
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Sources and sourceref - part 2

Stefan Björk
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SHORT VERSION Sources and sourceref - part 2

Richard Taylor-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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SHORT VERSION Sources and sourceref - part 2

bm-5
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
Loading...