Quantcast

nested sources - sourceref - one big source

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

nested sources - sourceref - one big source

bm-7
Hi,

I've been mailing with Gerald over how to use sources, and we have some
different views, which is only human.

However, there was a feature request I wanted to do, and now I'm not so certain
anymore.

The feature I would like was nested sources. Some programms allow that, eg in
phpgedview you can give a level: level 1, level 2, which then can organize
itself in a nice source report on printout.

Eg: a parish registry of the 18th century is a source spanning a couple of
years, eg 1781-1783. The priest writes down an entry for every birth.

With nested sources you would have:
repository: Brussels national library

source level 1: parish registry Parish Saint-Joseph, Antwerps.
source level 2: birth entry John Doe. (note: latin text, transcript of latin
text)
source level 2: birth entry Jane Doe.
...

On reports, this can then be nicely formatted. I don't find sourceref
sufficient, as one birth entry has 6 names on them: child, parents, godparents
and priest.

Do other people see use in such a structure, or do they find the sourceref
sufficient?

Personally, I now make a source for every entry in this case, as I find that one
entry just has two much information, and does not really fit on a source with
another entry in the same parish registry.

However, Gerald said in a mail to me:

> Where I live [snip], the government makes birth
> registrations available for those born more than 95 years ago (so
> we're currently working on 1902).  The source is "Ontario birth
> registrations".  The repository is "Ontario Archives".  Each birth
> event that I can find here refers to the source and includes a picture
> of the actual registration.  I don't make a source for each
> registration, but rather one for *all* registrations. The sourceref is
> the place to put the registration information (dates, numbers, etc).
>
> I do the same with marriage and death registrations.  It's easy,
> consistent and I can find stuff later without problems.

What do you guys think?

Also, the multiple notes in the upcoming version could be used for that: one
source for the parish registry, and then one note per entry, but I don't think
this is as usefull due to the fact that one entry can have several notes
(translation to begin with), and too many people refer to a source which
becomes overly large.

Benny

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: nested sources - sourceref - one big source

Alex Roitman
Benny,

I would personally agree with Gerald, and this is probably the
intended use of the sources and references: use one source for
the whole registry, and use sourceref fields (page, text, volume)
for each particular reference.

I don't see how this is not enough. If there's 6 people described
in a birth entru, each can have a reference to the registry,
citing same page (or whatever pages they are on) and so on.

Alex

On Tue, 2007-02-27 at 15:58 +0100, [hidden email] wrote:

> Hi,
>
> I've been mailing with Gerald over how to use sources, and we have some
> different views, which is only human.
>
> However, there was a feature request I wanted to do, and now I'm not so certain
> anymore.
>
> The feature I would like was nested sources. Some programms allow that, eg in
> phpgedview you can give a level: level 1, level 2, which then can organize
> itself in a nice source report on printout.
>
> Eg: a parish registry of the 18th century is a source spanning a couple of
> years, eg 1781-1783. The priest writes down an entry for every birth.
>
> With nested sources you would have:
> repository: Brussels national library
>
> source level 1: parish registry Parish Saint-Joseph, Antwerps.
> source level 2: birth entry John Doe. (note: latin text, transcript of latin
> text)
> source level 2: birth entry Jane Doe.
> ...
>
> On reports, this can then be nicely formatted. I don't find sourceref
> sufficient, as one birth entry has 6 names on them: child, parents, godparents
> and priest.
>
> Do other people see use in such a structure, or do they find the sourceref
> sufficient?
>
> Personally, I now make a source for every entry in this case, as I find that one
> entry just has two much information, and does not really fit on a source with
> another entry in the same parish registry.
>
> However, Gerald said in a mail to me:
>
> > Where I live [snip], the government makes birth
> > registrations available for those born more than 95 years ago (so
> > we're currently working on 1902).  The source is "Ontario birth
> > registrations".  The repository is "Ontario Archives".  Each birth
> > event that I can find here refers to the source and includes a picture
> > of the actual registration.  I don't make a source for each
> > registration, but rather one for *all* registrations. The sourceref is
> > the place to put the registration information (dates, numbers, etc).
> >
> > I do the same with marriage and death registrations.  It's easy,
> > consistent and I can find stuff later without problems.
>
> What do you guys think?
>
> Also, the multiple notes in the upcoming version could be used for that: one
> source for the parish registry, and then one note per entry, but I don't think
> this is as usefull due to the fact that one entry can have several notes
> (translation to begin with), and too many people refer to a source which
> becomes overly large.
--
Alexander Roitman   http://www.gramps-project.org


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: nested sources - sourceref - one big source

bm-7
Quoting Alex Roitman <[hidden email]>:

> Benny,
>
> I would personally agree with Gerald, and this is probably the
> intended use of the sources and references: use one source for
> the whole registry, and use sourceref fields (page, text, volume)
> for each particular reference.
>
> I don't see how this is not enough. If there's 6 people described
> in a birth entru, each can have a reference to the registry,
> citing same page (or whatever pages they are on) and so on.

Ok,

I have databases here of other people (from gedcom) and they do the same as I:
the entry is the source, not the parish registry. Hence, I'm not alone in
thinking this is an easier way of working with these type of sources.

The problem is that the text is in latin. So one has to translate anyway. Once
translated you want to keep the translation, or you have to redo it later if
you are unsure you translated correctly.

So every birth entry has a latin text, and a translated text, and a
scan of the
part (normally picture of microfilm), as well as an enhanced version of this
scan.

Now, your family lived in that place, so you have like 6-10 birth entries in
your database from this one source.
This makes one huge note and a large gallery in which you have to retrieve the
data if you need it later. This is just not easy to work with if you arrive on
this source following a link in an event.

Now, suppose you want to see data starting from a source. If you double
click on
the source, you see it is referenced, but you are not able to see the
sourceref
information: clicking on references opens up the person/event, and opening the
sourcefref from there is impossible because the source is already open.

Furthermore, if a person links to the source, you don't know immediately which
file of the gallery belongs to the part of the source your person is connected
too. You could solve this by adding the picture also to the birth reference,
but then you are doubling connections with the sole purpose of finding your
information more easily. Adding to the sourceref page 8 is no real option
(first, they did not number their pages, and second, this assumes you
as a user
give your notes/media a specific name so you retrieve it knowing the
page is 8)

It is my believe the data would be a lot more structured with nested sources
implemented in one way or another.
I do not want to talk about one way or another to implement this, but there is
certainly a need judging from the practices I see around me.

Benny

>
> Alex
>
> On Tue, 2007-02-27 at 15:58 +0100, [hidden email] wrote:
>> Hi,
>>
>> I've been mailing with Gerald over how to use sources, and we have some
>> different views, which is only human.
>>
>> However, there was a feature request I wanted to do, and now I'm not
>> so certain
>> anymore.
>>
>> The feature I would like was nested sources. Some programms allow
>> that, eg in
>> phpgedview you can give a level: level 1, level 2, which then can organize
>> itself in a nice source report on printout.
>>
>> Eg: a parish registry of the 18th century is a source spanning a couple of
>> years, eg 1781-1783. The priest writes down an entry for every birth.
>>
>> With nested sources you would have:
>> repository: Brussels national library
>>
>> source level 1: parish registry Parish Saint-Joseph, Antwerps.
>> source level 2: birth entry John Doe. (note: latin text, transcript of latin
>> text)
>> source level 2: birth entry Jane Doe.
>> ...
>>
>> On reports, this can then be nicely formatted. I don't find sourceref
>> sufficient, as one birth entry has 6 names on them: child, parents,
>> godparents
>> and priest.
>>
>> Do other people see use in such a structure, or do they find the sourceref
>> sufficient?
>>
>> Personally, I now make a source for every entry in this case, as I
>> find that one
>> entry just has two much information, and does not really fit on a
>> source with
>> another entry in the same parish registry.
>>
>> However, Gerald said in a mail to me:
>>
>> > Where I live [snip], the government makes birth
>> > registrations available for those born more than 95 years ago (so
>> > we're currently working on 1902).  The source is "Ontario birth
>> > registrations".  The repository is "Ontario Archives".  Each birth
>> > event that I can find here refers to the source and includes a picture
>> > of the actual registration.  I don't make a source for each
>> > registration, but rather one for *all* registrations. The sourceref is
>> > the place to put the registration information (dates, numbers, etc).
>> >
>> > I do the same with marriage and death registrations.  It's easy,
>> > consistent and I can find stuff later without problems.
>>
>> What do you guys think?
>>
>> Also, the multiple notes in the upcoming version could be used for that: one
>> source for the parish registry, and then one note per entry, but I
>> don't think
>> this is as usefull due to the fact that one entry can have several notes
>> (translation to begin with), and too many people refer to a source which
>> becomes overly large.
>
> --
> Alexander Roitman   http://www.gramps-project.org
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: nested sources - sourceref - one big source

Gerald Britton-2
I don't know Benny, but I think your approach adds complication
without functionality, with one exception:  It is true that if you
look in the references tab, you cannot see the data in the reference,
only the referring object.  I think you should file a feature request
to enable such an option since it sounds useful.

Here's how I would solve your sample problem:

1. For each birth event, specify the source being the parish registry
2. in the source ref, note the date/volume/page number and microfilm
number or whatever you have that makes it easy to find the page again.
 Here you can also add the latin text with translation for each entry
in the sourceref text tab.
3. link the source (the parish registry) to a repository (usually the
parish church or local or national archives)
4. back in the birth event, add the pictures to the gallery.  The
picture for the whole page will potentially be shared with everyone in
your tree that is on that page.  You can add a close-up of the entry
you are transcribing if you like.

Voila!  One source, many sourcerefs (each with a small note), many
events referring to the source (each with a small gallery)


I use a variation of this approach to record census information.  Say
a census of my ancestor's family was made in 1841 (one event, many
people).  I do the following:

1. create a census event with the date and description "Census of my
ancestor's family" or something like that.  I put the event at the
place described in the census (including address if available)
2. create a source for the entire 1841 census
3. create a repository for the 1841 census, which is where it is on
the Internet or in bricks and mortar.
4. Add specifics to the source ref, including Microfilm number,
Section number, page number, line numbers and household number, etc.
5. add a scan of the page to the gallery for the event
6. copy the event reference to all members of the family that were
polled at that location.

Now say another family is included in the same census.  I repeat steps
1, 4-6 but can skip 2 and 3 since they are done.

On 2/27/07, [hidden email] <[hidden email]> wrote:

> Quoting Alex Roitman <[hidden email]>:
>
> > Benny,
> >
> > I would personally agree with Gerald, and this is probably the
> > intended use of the sources and references: use one source for
> > the whole registry, and use sourceref fields (page, text, volume)
> > for each particular reference.
> >
> > I don't see how this is not enough. If there's 6 people described
> > in a birth entru, each can have a reference to the registry,
> > citing same page (or whatever pages they are on) and so on.
>
> Ok,
>
> I have databases here of other people (from gedcom) and they do the same as I:
> the entry is the source, not the parish registry. Hence, I'm not alone in
> thinking this is an easier way of working with these type of sources.
>
> The problem is that the text is in latin. So one has to translate anyway. Once
> translated you want to keep the translation, or you have to redo it later if
> you are unsure you translated correctly.
>
> So every birth entry has a latin text, and a translated text, and a
> scan of the
> part (normally picture of microfilm), as well as an enhanced version of this
> scan.
>
> Now, your family lived in that place, so you have like 6-10 birth entries in
> your database from this one source.
> This makes one huge note and a large gallery in which you have to retrieve the
> data if you need it later. This is just not easy to work with if you arrive on
> this source following a link in an event.
>
> Now, suppose you want to see data starting from a source. If you double
> click on
> the source, you see it is referenced, but you are not able to see the
> sourceref
> information: clicking on references opens up the person/event, and opening the
> sourcefref from there is impossible because the source is already open.
>
> Furthermore, if a person links to the source, you don't know immediately which
> file of the gallery belongs to the part of the source your person is connected
> too. You could solve this by adding the picture also to the birth reference,
> but then you are doubling connections with the sole purpose of finding your
> information more easily. Adding to the sourceref page 8 is no real option
> (first, they did not number their pages, and second, this assumes you
> as a user
> give your notes/media a specific name so you retrieve it knowing the
> page is 8)
>
> It is my believe the data would be a lot more structured with nested sources
> implemented in one way or another.
> I do not want to talk about one way or another to implement this, but there is
> certainly a need judging from the practices I see around me.
>
> Benny
>
> >
> > Alex
> >
> > On Tue, 2007-02-27 at 15:58 +0100, [hidden email] wrote:
> >> Hi,
> >>
> >> I've been mailing with Gerald over how to use sources, and we have some
> >> different views, which is only human.
> >>
> >> However, there was a feature request I wanted to do, and now I'm not
> >> so certain
> >> anymore.
> >>
> >> The feature I would like was nested sources. Some programms allow
> >> that, eg in
> >> phpgedview you can give a level: level 1, level 2, which then can organize
> >> itself in a nice source report on printout.
> >>
> >> Eg: a parish registry of the 18th century is a source spanning a couple of
> >> years, eg 1781-1783. The priest writes down an entry for every birth.
> >>
> >> With nested sources you would have:
> >> repository: Brussels national library
> >>
> >> source level 1: parish registry Parish Saint-Joseph, Antwerps.
> >> source level 2: birth entry John Doe. (note: latin text, transcript of latin
> >> text)
> >> source level 2: birth entry Jane Doe.
> >> ...
> >>
> >> On reports, this can then be nicely formatted. I don't find sourceref
> >> sufficient, as one birth entry has 6 names on them: child, parents,
> >> godparents
> >> and priest.
> >>
> >> Do other people see use in such a structure, or do they find the sourceref
> >> sufficient?
> >>
> >> Personally, I now make a source for every entry in this case, as I
> >> find that one
> >> entry just has two much information, and does not really fit on a
> >> source with
> >> another entry in the same parish registry.
> >>
> >> However, Gerald said in a mail to me:
> >>
> >> > Where I live [snip], the government makes birth
> >> > registrations available for those born more than 95 years ago (so
> >> > we're currently working on 1902).  The source is "Ontario birth
> >> > registrations".  The repository is "Ontario Archives".  Each birth
> >> > event that I can find here refers to the source and includes a picture
> >> > of the actual registration.  I don't make a source for each
> >> > registration, but rather one for *all* registrations. The sourceref is
> >> > the place to put the registration information (dates, numbers, etc).
> >> >
> >> > I do the same with marriage and death registrations.  It's easy,
> >> > consistent and I can find stuff later without problems.
> >>
> >> What do you guys think?
> >>
> >> Also, the multiple notes in the upcoming version could be used for that: one
> >> source for the parish registry, and then one note per entry, but I
> >> don't think
> >> this is as usefull due to the fact that one entry can have several notes
> >> (translation to begin with), and too many people refer to a source which
> >> becomes overly large.
> >
> > --
> > Alexander Roitman   http://www.gramps-project.org
> >
> >
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: nested sources - sourceref - one big source

bm-7
Gerald,

I like this approach. But two things are still missing in the mix to get a
complete view of the issue (with the eyes on the future now).

1/Nice print of the source. If I want a 'source report' with all information,
listing nicely the source, some support would be nice to retrieve nice output
automatically from my input. Working with nested sources would make this easy.
If the best practice is to add the text and translation to the birt event (I
suppose twins would share the event then), the source report must be able to
retrieve this information from the connected birth events. This is probably
doable, but from a technical point of view perhaps more complicated

2/distribution of the sources as a .gramps file. Suppose I take it on
myself to
go over a source (one parish registry) and make a .gramps file of this source
for distribution to fellow genealogists. In your approach, this would mean one
source, and many events, while other people (parents,godfather) are coupled to
the source (which page they are on) and to the event (I suppose so, to avoid
having to look up in the source to know the event you need).
In an approach with nested sources, one could distribute a source as a .gramps
without one single event. Only the text and it's translation is provided. A
user can then import the source and add the events as is needed.

This is futuristic perhaps, but it might be something to keep in the
back of the
head while doing this discussion.

Benny

Quoting Gerald Britton <[hidden email]>:

> I don't know Benny, but I think your approach adds complication
> without functionality, with one exception:  It is true that if you
> look in the references tab, you cannot see the data in the reference,
> only the referring object.  I think you should file a feature request
> to enable such an option since it sounds useful.
>
> Here's how I would solve your sample problem:
>
> 1. For each birth event, specify the source being the parish registry
> 2. in the source ref, note the date/volume/page number and microfilm
> number or whatever you have that makes it easy to find the page again.
> Here you can also add the latin text with translation for each entry
> in the sourceref text tab.
> 3. link the source (the parish registry) to a repository (usually the
> parish church or local or national archives)
> 4. back in the birth event, add the pictures to the gallery.  The
> picture for the whole page will potentially be shared with everyone in
> your tree that is on that page.  You can add a close-up of the entry
> you are transcribing if you like.
>
> Voila!  One source, many sourcerefs (each with a small note), many
> events referring to the source (each with a small gallery)
>
>
> I use a variation of this approach to record census information.  Say
> a census of my ancestor's family was made in 1841 (one event, many
> people).  I do the following:
>
> 1. create a census event with the date and description "Census of my
> ancestor's family" or something like that.  I put the event at the
> place described in the census (including address if available)
> 2. create a source for the entire 1841 census
> 3. create a repository for the 1841 census, which is where it is on
> the Internet or in bricks and mortar.
> 4. Add specifics to the source ref, including Microfilm number,
> Section number, page number, line numbers and household number, etc.
> 5. add a scan of the page to the gallery for the event
> 6. copy the event reference to all members of the family that were
> polled at that location.
>
> Now say another family is included in the same census.  I repeat steps
> 1, 4-6 but can skip 2 and 3 since they are done.
>
> On 2/27/07, [hidden email] <[hidden email]> wrote:
>> Quoting Alex Roitman <[hidden email]>:
>>
>> > Benny,
>> >
>> > I would personally agree with Gerald, and this is probably the
>> > intended use of the sources and references: use one source for
>> > the whole registry, and use sourceref fields (page, text, volume)
>> > for each particular reference.
>> >
>> > I don't see how this is not enough. If there's 6 people described
>> > in a birth entru, each can have a reference to the registry,
>> > citing same page (or whatever pages they are on) and so on.
>>
>> Ok,
>>
>> I have databases here of other people (from gedcom) and they do the
>> same as I:
>> the entry is the source, not the parish registry. Hence, I'm not alone in
>> thinking this is an easier way of working with these type of sources.
>>
>> The problem is that the text is in latin. So one has to translate
>> anyway. Once
>> translated you want to keep the translation, or you have to redo it later if
>> you are unsure you translated correctly.
>>
>> So every birth entry has a latin text, and a translated text, and a
>> scan of the
>> part (normally picture of microfilm), as well as an enhanced version of this
>> scan.
>>
>> Now, your family lived in that place, so you have like 6-10 birth entries in
>> your database from this one source.
>> This makes one huge note and a large gallery in which you have to
>> retrieve the
>> data if you need it later. This is just not easy to work with if you
>> arrive on
>> this source following a link in an event.
>>
>> Now, suppose you want to see data starting from a source. If you double
>> click on
>> the source, you see it is referenced, but you are not able to see the
>> sourceref
>> information: clicking on references opens up the person/event, and
>> opening the
>> sourcefref from there is impossible because the source is already open.
>>
>> Furthermore, if a person links to the source, you don't know
>> immediately which
>> file of the gallery belongs to the part of the source your person is
>> connected
>> too. You could solve this by adding the picture also to the birth reference,
>> but then you are doubling connections with the sole purpose of finding your
>> information more easily. Adding to the sourceref page 8 is no real option
>> (first, they did not number their pages, and second, this assumes you
>> as a user
>> give your notes/media a specific name so you retrieve it knowing the
>> page is 8)
>>
>> It is my believe the data would be a lot more structured with nested sources
>> implemented in one way or another.
>> I do not want to talk about one way or another to implement this,
>> but there is
>> certainly a need judging from the practices I see around me.
>>
>> Benny
>>
>> >
>> > Alex
>> >
>> > On Tue, 2007-02-27 at 15:58 +0100, [hidden email] wrote:
>> >> Hi,
>> >>
>> >> I've been mailing with Gerald over how to use sources, and we have some
>> >> different views, which is only human.
>> >>
>> >> However, there was a feature request I wanted to do, and now I'm not
>> >> so certain
>> >> anymore.
>> >>
>> >> The feature I would like was nested sources. Some programms allow
>> >> that, eg in
>> >> phpgedview you can give a level: level 1, level 2, which then can
>> organize
>> >> itself in a nice source report on printout.
>> >>
>> >> Eg: a parish registry of the 18th century is a source spanning a
>> couple of
>> >> years, eg 1781-1783. The priest writes down an entry for every birth.
>> >>
>> >> With nested sources you would have:
>> >> repository: Brussels national library
>> >>
>> >> source level 1: parish registry Parish Saint-Joseph, Antwerps.
>> >> source level 2: birth entry John Doe. (note: latin text,
>> transcript of latin
>> >> text)
>> >> source level 2: birth entry Jane Doe.
>> >> ...
>> >>
>> >> On reports, this can then be nicely formatted. I don't find sourceref
>> >> sufficient, as one birth entry has 6 names on them: child, parents,
>> >> godparents
>> >> and priest.
>> >>
>> >> Do other people see use in such a structure, or do they find the
>> sourceref
>> >> sufficient?
>> >>
>> >> Personally, I now make a source for every entry in this case, as I
>> >> find that one
>> >> entry just has two much information, and does not really fit on a
>> >> source with
>> >> another entry in the same parish registry.
>> >>
>> >> However, Gerald said in a mail to me:
>> >>
>> >> > Where I live [snip], the government makes birth
>> >> > registrations available for those born more than 95 years ago (so
>> >> > we're currently working on 1902).  The source is "Ontario birth
>> >> > registrations".  The repository is "Ontario Archives".  Each birth
>> >> > event that I can find here refers to the source and includes a picture
>> >> > of the actual registration.  I don't make a source for each
>> >> > registration, but rather one for *all* registrations. The sourceref is
>> >> > the place to put the registration information (dates, numbers, etc).
>> >> >
>> >> > I do the same with marriage and death registrations.  It's easy,
>> >> > consistent and I can find stuff later without problems.
>> >>
>> >> What do you guys think?
>> >>
>> >> Also, the multiple notes in the upcoming version could be used
>> for that: one
>> >> source for the parish registry, and then one note per entry, but I
>> >> don't think
>> >> this is as usefull due to the fact that one entry can have several notes
>> >> (translation to begin with), and too many people refer to a source which
>> >> becomes overly large.
>> >
>> > --
>> > Alexander Roitman   http://www.gramps-project.org
>> >
>> >
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: nested sources - sourceref - one big source

bm-7
About this,

I looked at the archive of the abbey in my village (they are digitalizing it).
This is an archive 11th-18th century, with many names, a treasure trove to add
stories to a genealogical tree.

See eg http://www.kuleuven-kortrijk.be/doza/php/image.php?id=1197 or
http://www.kuleuven-kortrijk.be/doza/php/image.php?id=2700

The researcher are making entries of single papers they call articles (eg one
legal sentence, one letter), so they split up ledgers to make retrieval and
research more easy.

One entry (the site is flash, I cannot give a link, not even copy
paste! Only a
transcript, you can eg go to http://www.kuleuven-kortrijk.be/doza/ give in
search box 'Male', and click on one of the resulting articles) then contains:
* scans of the document
* storage place (code, city, archive, fund, inventerynumber)
* storage status
* source type and source type description (eg extract of payments of abt to
duke)
* Abstract: short abstract of the text, according to the researcher, and also
the original abstract in original language
* Date
* remarks
* material of document (paper/parchment, written/printed, katerns/single
papers/bound, condition, stamp present or not)
* all names appearing in the document
* all functions, places, institutions appearing in the document
* language of doc
* Incipit (beginning lines of the document. )
* text : transcript of the text, and translation of transcript
* relations: relation to other documents

So, the professionals here are following a structure of self contained sources
to content type. One source of legal sentences, will be split in the separate
sentences. Relations to other documents are given to reconstruct the entire
source.

It is clear to me that all these data indeed belong to the source object and
should be contained there. Once the source is fully accessible, you can then
create events and links to people.

Benny

Quoting Gerald Britton <[hidden email]>:

> Good input Benny. I never considered exporting sources alone but I can
> see the value in it from your application with parish registers.
>
> On 2/27/07, [hidden email] <[hidden email]> wrote:
>> Gerald,
>>
>> I like this approach. But two things are still missing in the mix to get a
>> complete view of the issue (with the eyes on the future now).
>>
>> 1/Nice print of the source. If I want a 'source report' with all
>> information,
>> listing nicely the source, some support would be nice to retrieve nice
>> output
>> automatically from my input. Working with nested sources would make this
>> easy.
>> If the best practice is to add the text and translation to the birt event (I
>> suppose twins would share the event then), the source report must be able to
>> retrieve this information from the connected birth events. This is probably
>> doable, but from a technical point of view perhaps more complicated
>>
>> 2/distribution of the sources as a .gramps file. Suppose I take it on
>> myself to
>> go over a source (one parish registry) and make a .gramps file of this
>> source
>> for distribution to fellow genealogists. In your approach, this would mean
>> one
>> source, and many events, while other people (parents,godfather) are coupled
>> to
>> the source (which page they are on) and to the event (I suppose so, to avoid
>> having to look up in the source to know the event you need).
>> In an approach with nested sources, one could distribute a source as a
>> .gramps
>> without one single event. Only the text and it's translation is provided. A
>> user can then import the source and add the events as is needed.
>>
>> This is futuristic perhaps, but it might be something to keep in the
>> back of the
>> head while doing this discussion.
>>
>> Benny
>>
>> Quoting Gerald Britton <[hidden email]>:
>>
>> > I don't know Benny, but I think your approach adds complication
>> > without functionality, with one exception:  It is true that if you
>> > look in the references tab, you cannot see the data in the reference,
>> > only the referring object.  I think you should file a feature request
>> > to enable such an option since it sounds useful.
>> >
>> > Here's how I would solve your sample problem:
>> >
>> > 1. For each birth event, specify the source being the parish registry
>> > 2. in the source ref, note the date/volume/page number and microfilm
>> > number or whatever you have that makes it easy to find the page again.
>> > Here you can also add the latin text with translation for each entry
>> > in the sourceref text tab.
>> > 3. link the source (the parish registry) to a repository (usually the
>> > parish church or local or national archives)
>> > 4. back in the birth event, add the pictures to the gallery.  The
>> > picture for the whole page will potentially be shared with everyone in
>> > your tree that is on that page.  You can add a close-up of the entry
>> > you are transcribing if you like.
>> >
>> > Voila!  One source, many sourcerefs (each with a small note), many
>> > events referring to the source (each with a small gallery)
>> >
>> >
>> > I use a variation of this approach to record census information.  Say
>> > a census of my ancestor's family was made in 1841 (one event, many
>> > people).  I do the following:
>> >
>> > 1. create a census event with the date and description "Census of my
>> > ancestor's family" or something like that.  I put the event at the
>> > place described in the census (including address if available)
>> > 2. create a source for the entire 1841 census
>> > 3. create a repository for the 1841 census, which is where it is on
>> > the Internet or in bricks and mortar.
>> > 4. Add specifics to the source ref, including Microfilm number,
>> > Section number, page number, line numbers and household number, etc.
>> > 5. add a scan of the page to the gallery for the event
>> > 6. copy the event reference to all members of the family that were
>> > polled at that location.
>> >
>> > Now say another family is included in the same census.  I repeat steps
>> > 1, 4-6 but can skip 2 and 3 since they are done.
>> >
>> > On 2/27/07, [hidden email] <[hidden email]> wrote:
>> >> Quoting Alex Roitman <[hidden email]>:
>> >>
>> >> > Benny,
>> >> >
>> >> > I would personally agree with Gerald, and this is probably the
>> >> > intended use of the sources and references: use one source for
>> >> > the whole registry, and use sourceref fields (page, text, volume)
>> >> > for each particular reference.
>> >> >
>> >> > I don't see how this is not enough. If there's 6 people described
>> >> > in a birth entru, each can have a reference to the registry,
>> >> > citing same page (or whatever pages they are on) and so on.
>> >>
>> >> Ok,
>> >>
>> >> I have databases here of other people (from gedcom) and they do the
>> >> same as I:
>> >> the entry is the source, not the parish registry. Hence, I'm not alone in
>> >> thinking this is an easier way of working with these type of sources.
>> >>
>> >> The problem is that the text is in latin. So one has to translate
>> >> anyway. Once
>> >> translated you want to keep the translation, or you have to redo it later
>> if
>> >> you are unsure you translated correctly.
>> >>
>> >> So every birth entry has a latin text, and a translated text, and a
>> >> scan of the
>> >> part (normally picture of microfilm), as well as an enhanced version of
>> this
>> >> scan.
>> >>
>> >> Now, your family lived in that place, so you have like 6-10 birth entries
>> in
>> >> your database from this one source.
>> >> This makes one huge note and a large gallery in which you have to
>> >> retrieve the
>> >> data if you need it later. This is just not easy to work with if you
>> >> arrive on
>> >> this source following a link in an event.
>> >>
>> >> Now, suppose you want to see data starting from a source. If you double
>> >> click on
>> >> the source, you see it is referenced, but you are not able to see the
>> >> sourceref
>> >> information: clicking on references opens up the person/event, and
>> >> opening the
>> >> sourcefref from there is impossible because the source is already open.
>> >>
>> >> Furthermore, if a person links to the source, you don't know
>> >> immediately which
>> >> file of the gallery belongs to the part of the source your person is
>> >> connected
>> >> too. You could solve this by adding the picture also to the birth
>> reference,
>> >> but then you are doubling connections with the sole purpose of finding
>> your
>> >> information more easily. Adding to the sourceref page 8 is no real option
>> >> (first, they did not number their pages, and second, this assumes you
>> >> as a user
>> >> give your notes/media a specific name so you retrieve it knowing the
>> >> page is 8)
>> >>
>> >> It is my believe the data would be a lot more structured with nested
>> sources
>> >> implemented in one way or another.
>> >> I do not want to talk about one way or another to implement this,
>> >> but there is
>> >> certainly a need judging from the practices I see around me.
>> >>
>> >> Benny
>> >>
>> >> >
>> >> > Alex
>> >> >
>> >> > On Tue, 2007-02-27 at 15:58 +0100, [hidden email] wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I've been mailing with Gerald over how to use sources, and we have
>> some
>> >> >> different views, which is only human.
>> >> >>
>> >> >> However, there was a feature request I wanted to do, and now I'm not
>> >> >> so certain
>> >> >> anymore.
>> >> >>
>> >> >> The feature I would like was nested sources. Some programms allow
>> >> >> that, eg in
>> >> >> phpgedview you can give a level: level 1, level 2, which then can
>> >> organize
>> >> >> itself in a nice source report on printout.
>> >> >>
>> >> >> Eg: a parish registry of the 18th century is a source spanning a
>> >> couple of
>> >> >> years, eg 1781-1783. The priest writes down an entry for every birth.
>> >> >>
>> >> >> With nested sources you would have:
>> >> >> repository: Brussels national library
>> >> >>
>> >> >> source level 1: parish registry Parish Saint-Joseph, Antwerps.
>> >> >> source level 2: birth entry John Doe. (note: latin text,
>> >> transcript of latin
>> >> >> text)
>> >> >> source level 2: birth entry Jane Doe.
>> >> >> ...
>> >> >>
>> >> >> On reports, this can then be nicely formatted. I don't find sourceref
>> >> >> sufficient, as one birth entry has 6 names on them: child, parents,
>> >> >> godparents
>> >> >> and priest.
>> >> >>
>> >> >> Do other people see use in such a structure, or do they find the
>> >> sourceref
>> >> >> sufficient?
>> >> >>
>> >> >> Personally, I now make a source for every entry in this case, as I
>> >> >> find that one
>> >> >> entry just has two much information, and does not really fit on a
>> >> >> source with
>> >> >> another entry in the same parish registry.
>> >> >>
>> >> >> However, Gerald said in a mail to me:
>> >> >>
>> >> >> > Where I live [snip], the government makes birth
>> >> >> > registrations available for those born more than 95 years ago (so
>> >> >> > we're currently working on 1902).  The source is "Ontario birth
>> >> >> > registrations".  The repository is "Ontario Archives".  Each birth
>> >> >> > event that I can find here refers to the source and includes a
>> picture
>> >> >> > of the actual registration.  I don't make a source for each
>> >> >> > registration, but rather one for *all* registrations. The sourceref
>> is
>> >> >> > the place to put the registration information (dates, numbers, etc).
>> >> >> >
>> >> >> > I do the same with marriage and death registrations.  It's easy,
>> >> >> > consistent and I can find stuff later without problems.
>> >> >>
>> >> >> What do you guys think?
>> >> >>
>> >> >> Also, the multiple notes in the upcoming version could be used
>> >> for that: one
>> >> >> source for the parish registry, and then one note per entry, but I
>> >> >> don't think
>> >> >> this is as usefull due to the fact that one entry can have several
>> notes
>> >> >> (translation to begin with), and too many people refer to a source
>> which
>> >> >> becomes overly large.
>> >> >
>> >> > --
>> >> > Alexander Roitman   http://www.gramps-project.org
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> ----------------------------------------------------------------
>> >> This message was sent using IMP, the Internet Messaging Program.
>> >>
>> >> -------------------------------------------------------------------------
>> >> Take Surveys. Earn Cash. Influence the Future of IT
>> >> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> >> opinions on IT & business topics through brief surveys-and earn cash
>> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> >> _______________________________________________
>> >> Gramps-users mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/gramps-users
>> >>
>> >
>> > -------------------------------------------------------------------------
>> > Take Surveys. Earn Cash. Influence the Future of IT
>> > Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> > opinions on IT & business topics through brief surveys-and earn cash
>> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> > _______________________________________________
>> > Gramps-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/gramps-users
>> >
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Gramps-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-users
>>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Loading...