Sources, media and galleries: how to tie it all up "as intended"

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Martin Steer-2
I apologise to the list if this post has already appeared. I'm having
some problems with my mail.

"Frederico Muñoz" <[hidden email]> writes:

>
> My biggest complain about the way it works right now is merely that it
> seems impossible to go from the event to having the scanned image in
> front of the eyes in a way that seems logical. If the Source has 20
> pages it would required careful naming of the Media Objects to work,
> which means that there would be no real link between the sourceref and
> the media object that represents it. This is important to me (it maybe
> secondary to others, of course).
>

Not impossible. Instead of source --> media, what about media -->
source. You could attach a media object (scanned page) to an event, and
provide a source (Archive X, vol. 3, p. 9) for the media. At least then
the media has an immediate relationship to both the event and some
subsection of the source. (Probably someone has already suggested this.)

Or, media as event...

--
Martin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Frederico Munoz
Hello,

On Sun, Sep 21, 2008 at 12:59 AM, Martin Steer <[hidden email]> wrote:
(...)
> Not impossible.

Bad choice of word, apologies. Given the flexibility of GRAMPS there
is always a way.

> Instead of source --> media, what about media -->
> source. You could attach a media object (scanned page) to an event, and
> provide a source (Archive X, vol. 3, p. 9) for the media. At least then
> the media has an immediate relationship to both the event and some
> subsection of the source. (Probably someone has already suggested this.)

That seems to be the best workaround - or not even a workaround but
the proper way. I will probably start using that, many thanks. If I
understood correctly:

* Add the scanned page to the Event gallery
* Related the Media Object  to the source via a sourceref (the UK
Census example uses this).
* Optionally add the Media Object to the Source gallery as well. It
sort of duplicates the linking but could be useful (allows viewing the
Source as a "book" with all the known pages displayed).

Some possible drawbacks:

* Perhaps adding the image to the Person (or Family, if appropriate)
Gallery would be better since some documents contain information
related to several events and it can be overkill to add, say, a birth
certificate to a Death event. OTOH a Birth certificate seems to
logically belong to the Birth event.
* It sort of bypasses the Source relationship (since it goes to the
Gallery tab) but this is intended since it is the only way to provide
the immediate relationship.

All in all they seem rather minor.

Jérôme had hinted at an arragement like that and I had saw something
similar in the UK Census example in the wiki. I was trying to have an
arrangement that completely depended on an idealised view of the
Source->sourcerefs mechanism.

Taking the data I use for my examples:

Name: Raphael Hythloday
Birth date: 20 February 1480
Place of Birth: Santa Maria de Belém, Lisbon, Portugal
Source: Baptism record present in page 66 of the year 1480 book of the
Baptism Records of the Parish of Belém in Lisbon, Portugal

The way I use sourcerefs this ends up as:

Repository: Parish of Belém Archives
Source: Parish of Belém Baptism Records
Event source reference: In the "Vol/Page" field input "Year 1480, page 66"
Media Object: scanned page of the said record.

And to use what you propose:

1) Add the birth event, and add the correspondent sourceref (i.e. Year
1280, page 66) pointing to the Source
2) Copy said reference to the clipboard
3) Add the image as a Media Object
4) Paste the sourceref above in the Media Object Sources tab
5) Optional: add the Media Object to the Source Gallery tab
6) In the Birth Event windows add the Media Object to the Gallery

This way one can see:

* See all events that refer a certain Media Object
* Easily access the birth/baptism/death certificate images
* Optionally browse the Source Gallery, seeing every page that belongs to it

If this seems reasonable I will make a wiki article describing it,
maybe it can help others. I would like to know if the above doesn't
"break" any convention - saying this because I'm aware that many tabs
and fields have a specific meaning in GEDCOM that could advise against
certain usages.

Regards,

Frederico

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Martin Steer-2
"Frederico Muñoz" <[hidden email]> writes:

[snip]

> Some possible drawbacks:
>
> * Perhaps adding the image to the Person (or Family, if appropriate)
> Gallery would be better since some documents contain information
> related to several events and it can be overkill to add, say, a birth
> certificate to a Death event.

I agree.

> * It sort of bypasses the Source relationship (since it goes to the
> Gallery tab) but this is intended since it is the only way to provide
> the immediate relationship.

I don't have a problem with this. A reference to a source and an image
of a source are different kinds of things, with different functions.

I would run some reports, to see how they represent your data.

[snip]

> If this seems reasonable I will make a wiki article describing it,
> maybe it can help others. I would like to know if the above doesn't
> "break" any convention - saying this because I'm aware that many tabs
> and fields have a specific meaning in GEDCOM that could advise against
> certain usages.

I don't know much about gedcom. It apparently has some limitations that
gramps' format doesn't.

--
Martin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Tim Lyons
Administrator
In reply to this post by Frederico Munoz
Frederico,

I had many of the same questions.

I agree that it is usually best to try to make any tool work “as intended”. However, in this case as there seem to be many ways to use the tool, I thought I should try to do the basic data analysis for my data, and see the ‘best’ way to represent this, and then see whether this was nicely supported.

Like you, I am starting from a particular set of data, in my case the UK census records. I think that the ‘multiple pages per source’ is the best representation of the data. (Actually, each sourceref is the record for one household, rather than strictly one page, but the principle is the same and it is clearer to carry on talking about ‘multiple pages per source’).

As I understand it, sourcerefs can be shared, so in the case of:

> finding multiple instances. Say you have many refs to "Achive X vol.3,
> p.9". You want to change these to "Archive Y, vol.2". How do you find
> the references as a group?

If there is only one sourceref to that particular page and the sourceref is shared, then you only need to find one to change the details.

I use drag and drop to copy sourcerefs from one place to another, and this seems to work well.

It seems to me that the features of gramps support ‘multiple pages per source’ very nicely, except for two particular problems:

(1) sourceref is not a first class object, so it does not have a tab on the main window from which you can find all the sourcerefs, and thence details of each

(2) a sourceref cannot point to a particular media.  (I agree that if the sourceref could point to the particular part of the image in the source that applied to this sourceref (as Benny suggests), then it would not be necessary to have the media as a property of the sourceref).

I think that it would be very nice if Gramps could be enhanced to do both these things. I am trying to construct an example to show the data analysis that I have done and how this is supported at present in Gramps, and when I have done so, I will follow it up with a feature request in the bugs database! (I did raise this before:
http://www.nabble.com/Media-and-attributes-in-data-model-for-Gramps-3.0-td13868204.html#a13868783
and Benny’s view was that it might cause problems to have information in the sourceref, hence why I am trying to produce a better analysis and example before asking again.)

I agree that a sourceref in the image seems to be doing things the wrong way round. (The sourceref points from the information I know to the source for that information. The image is not actually the information I know from the source – it actually IS the source! If the image were a family tree, then I might add a sourceref to point to the source I used when I drew that tree, but this is not the situation we are talking about.)

Regards,
Tim.
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Gerald Britton-2
For problem 2 (sourceref can't point to specific media object), for
census records, I simply record the date, page, and line numbers to
provide location.  So for the 1880 US cenus, e.g. I have one source
(the whole census), many images, which I have been attaching to the
census event, though I can see the argument to attach them to the
source), and I fill the date and vol/pg info in the unshared part of
the sourceref to be able to find the specific bits that go with
whatever the sourceref is there for (usually a census event).

On Sun, Sep 21, 2008 at 5:27 PM, guylinton <[hidden email]> wrote:

>
> Frederico,
>
> I had many of the same questions.
>
> I agree that it is usually best to try to make any tool work "as intended".
> However, in this case as there seem to be many ways to use the tool, I
> thought I should try to do the basic data analysis for my data, and see the
> 'best' way to represent this, and then see whether this was nicely
> supported.
>
> Like you, I am starting from a particular set of data, in my case the UK
> census records. I think that the 'multiple pages per source' is the best
> representation of the data. (Actually, each sourceref is the record for one
> household, rather than strictly one page, but the principle is the same and
> it is clearer to carry on talking about 'multiple pages per source').
>
> As I understand it, sourcerefs can be shared, so in the case of:
>
>> finding multiple instances. Say you have many refs to "Achive X vol.3,
>> p.9". You want to change these to "Archive Y, vol.2". How do you find
>> the references as a group?
>
> If there is only one sourceref to that particular page and the sourceref is
> shared, then you only need to find one to change the details.
>
> I use drag and drop to copy sourcerefs from one place to another, and this
> seems to work well.
>
> It seems to me that the features of gramps support 'multiple pages per
> source' very nicely, except for two particular problems:
>
> (1) sourceref is not a first class object, so it does not have a tab on the
> main window from which you can find all the sourcerefs, and thence details
> of each
>
> (2) a sourceref cannot point to a particular media.  (I agree that if the
> sourceref could point to the particular part of the image in the source that
> applied to this sourceref (as Benny suggests), then it would not be
> necessary to have the media as a property of the sourceref).
>
> I think that it would be very nice if Gramps could be enhanced to do both
> these things. I am trying to construct an example to show the data analysis
> that I have done and how this is supported at present in Gramps, and when I
> have done so, I will follow it up with a feature request in the bugs
> database! (I did raise this before:
> http://www.nabble.com/Media-and-attributes-in-data-model-for-Gramps-3.0-td13868204.html#a13868783
> and Benny's view was that it might cause problems to have information in the
> sourceref, hence why I am trying to produce a better analysis and example
> before asking again.)
>
> I agree that a sourceref in the image seems to be doing things the wrong way
> round. (The sourceref points from the information I know to the source for
> that information. The image is not actually the information I know from the
> source – it actually IS the source! If the image were a family tree, then I
> might add a sourceref to point to the source I used when I drew that tree,
> but this is not the situation we are talking about.)
>
> Regards,
> Tim.
>
> --
> View this message in context: http://www.nabble.com/Sources%2C-media-and-galleries%3A-how-to-tie-it-all-up-%22as-intended%22-tp19437699p19598653.html
> Sent from the GRAMPS - User mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Benny Malengier
In reply to this post by Tim Lyons


2008/9/21 guylinton <[hidden email]>
.

As I understand it, sourcerefs can be shared, so in the case of:

No, this is not true. It would be very impractical from a data storage view to be able to share and the source, and the source reference. Then one would need a source reference reference :-)

The source reference is the connection between a source and one specific object, holding the information unique to this relation.

There have been ideas to divide sources in levels, so you can group sources and then link to the correct level with a source reference, doing away with the need in many cases to still hold things as date or page on the level of the reference (as the source would be only that date/page). Perhaps before 2013 somebody will have the time to implement this (it would mean a link between sources in a tree like way). Obviously, it would mean further divergence of GEDCOM which should not be done lightly....



> finding multiple instances. Say you have many refs to "Achive X vol.3,
> p.9". You want to change these to "Archive Y, vol.2". How do you find
> the references as a group?

If there is only one sourceref to that particular page and the sourceref is
shared, then you only need to find one to change the details.

so nope

I use drag and drop to copy sourcerefs from one place to another, and this
seems to work well.

it creates identical copies, it does not share the reference. All references are unique, using drag and drop duplicates them. Drag and drop on objects created references to those objects.

Benny


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
Reply | Threaded
Open this post in threaded view
|

Re: Sources, media and galleries: how to tie it all up "as intended"

Tim Lyons
Administrator
Benny Malengier wrote
2008/9/21 guylinton <guy.linton@gmail.com>
>
> As I understand it, sourcerefs can be shared, so in the case of:
No, this is not true.
> > finding multiple instances. Say you have many refs to "Achive X vol.3,
> > p.9". You want to change these to "Archive Y, vol.2". How do you find
> > the references as a group?
>
> If there is only one sourceref to that particular page and the sourceref is
> shared, then you only need to find one to change the details.
so nope
> I use drag and drop to copy sourcerefs from one place to another, and this
> seems to work well.
it creates identical copies, it does not share the reference. All references
are unique, using drag and drop duplicates them.
Oh! I see, I had not appreciated that, so of course that makes a big difference to my suggestions.

It would be very impractical from a data storage view
to be able to share and the source, and the source reference. Then one would
need a source reference reference :-)
So, my enhancement suggestion would need to be changed.

I would suggest that the source-ref-ref be hidden from the user, and have no attributes. Then this should permit sharing of the source-ref without greatly impacting the appearance of the rest of the functionality. (Of course the programming might not be so simple!)

The source reference is the connection between a source and one specific
object, holding the information unique to this relation.
Agreed. Is is also the case that the source-ref appears in the GEDCOM standard (as SOURCE_CITATION). The standard seems to suggest that as well as the page number you might include "actual text...for example...an applicable sentence from a letter". There seems to be a precedent for making a substructure in GEDCOM into a fully-fledged object (potentially shared) (e.g. Event and place?)

There have been ideas to divide sources in levels, so you can group sources
and then link to the correct level with a source reference, doing away with
the need in many cases to still hold things as date or page on the level of
the reference (as the source would be only that date/page). Perhaps before
2013 somebody will have the time to implement this (it would mean a link
between sources in a tree like way). Obviously, it would mean further
divergence of GEDCOM which should not be done lightly....
I agree that dividing sources into levels would mean further divergence from GEDOM (which I think would be undesirable).

However, introduction of a source-ref-ref to link an object to a shared citation/source-ref would not seem to diverge particularly further from GEDCOM. On export to GEDCOM, it would duplicate the source-ref in the various places where it occurred. On import, one could try to determine whether two citations were identical (and then place two references to the source-ref), but perhaps it would not really be worth the effort.

Given the fact that the question over the use of source-refs in different ways has occurred several times in the past, I wonder whether it could be worth reconsdering an enhancement.

I imagine it would be quite a big change, impacting many modules (there seem to be about 400 lines with source_reference in them) unless something clever could be done to hide the intermediate object except where it is specifically needed to point to an existing shared source-ref (i.e. when you drag and drop and create a new ref-ref to an existing source-ref). If this were done, this could form the basis for allowing searches on source-ref and also media (or media part references) in the source-ref.
Benny
regards,
Tim Lyons
12