local gallery tab in source reference
Locked
local gallery tab in source reference
 
|
Hi,
I am still struggeling with images as sources. What I thought of was, if there was a gallery tab in the local source reference, just like the notes and comments, it would be really helpful. Because then you could have just the one image or two that are of interest for that source reference in the local reference and the pool of images that belong to that source in the global gallery tab. One other thing is the subsection of the images. This is somewhat useless for the global gallery tab, since you normally do not have subsections of images as source, inspite you just want to crop it so that the image looks cleaner. But if we had a local gallery tab in the source reference, it would be possible for example to mark the line in a census report by using the subsection feature of the media reference or marking a paragraph on a page of book or something like that. Just an idea;-). MfG Tobias ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Gramps-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-users |
Re: local gallery tab in source reference
|
A source reference is the reference of an object to a specific section of a source.
Hence all data of the source itself should be in the source object. That is notes, data, media. The reference should make it possible to refer to it and easily find it in the source, not contain the data itself. So date in sourceref refers to the log date in the source. For future 3.0, you will have multiple notes, if you write down a note per log date in the source, lookup of text would be easier Volume/page refers to the page in the source, so for those sources that are divided in pages/sections. Indeed, for images there should be a referral system too. However, we should avoid confusing the user, already too many people think the text should be kept in sourceref (probably due to the text tab on sourceref, which will be removed in 3.0 and will be part of the sourceref notes, text field is due to GEDCOM which gramps supports where it is present (but GEDCOM specifically says to use source for the text ...)). We should not go to the confusion of keeping media in the sourceref, although we could create a system in which we show a picture like is done on the person editor. You could hence do a feature request for a media referral section, eg a tab, where you give image section and then a picture is shown based on the first image in the mediagallery of the source. Not the best solution perhaps, but I was thinking in the future of a system where you can divide a source in subsections, and then link the sourceref immediately to the subsection, allowing the retrieval of text/image in the source to be more easy. Also just some ideas. Benny 2007/10/19, Tobias Gehrig <[hidden email]>: Hi, ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Gramps-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-users |
Re: local gallery tab in source reference
|
|
Hi,
Am Freitag, den 19.10.2007, 14:33 +0200 schrieb Benny Malengier: > A source reference is the reference of an object to a specific section > of a source. I agree that the source reference should be as the name says only a reference. > > Hence all data of the source itself should be in the source object. > That is notes, data, media. > The reference should make it possible to refer to it and easily find > it in the source, not contain the data itself. Agreed, but if a direct link into the data, meaning an explicit reference, would be available it would be much easier to find things in a big source;-). > > So date in sourceref refers to the log date in the source. This is something that always confused me. Does the date mean, when I read the specific part of the source and entered into gramps? Or does it mean when the source was created? Which would be somewhat redundant for a book and should probably go rather into the publication information in the source, but would make more sence for census records, which almost all have different dates. > For future 3.0, you will have multiple notes, if you write down a > note per log date in the source, lookup of text would be easier > Volume/page refers to the page in the source, so for those sources > that are divided in pages/sections. > Indeed, for images there should be a referral system too. Indeed;-). > However, we should avoid confusing the user, already too many people > think the text should be kept in sourceref Okay, I am probably one of those:-/. I transcribe images in their corresponding note tab, include those images in the source gallery and copy the referred text into the source reference text. Which leads to lots of redundancy:-(. So should the transcription of the source go into the global notes tab and only comments and so forth into the local one? Until now, I used the global notes tab only as description of what the source contains. > (probably due to the text tab on sourceref, which will be removed in > 3.0 and will be part of the sourceref notes, text field is due to > GEDCOM which gramps supports where it is present (but GEDCOM > specifically says to use source for the text ...)). We should not go > to the confusion of keeping media in the sourceref, although we could > create a system in which we show a picture like is done on the person > editor. > > You could hence do a feature request for a media referral section, eg > a tab, where you give image section and then a picture is shown based > on the first image in the mediagallery of the source. cases refer to the first image. Restricting the media reference to one image though should be okay. And it could also be restricted to just the media included in the global source gallery. This way it would be guaranteed that it is used in the intended way. Using a gallery instead of a single image would just make it more general, but if one wants to refer to two pages/images it could be made by creating two source references. But this could make it somewhat complicated when a referred text in an image spans over two pages, thus two images, because the information that is actually one block would be torn apart into two references:-/. > Not the best solution perhaps, but I was thinking in the future of a > system where you can divide a source in subsections, and then link the > sourceref immediately to the subsection, allowing the retrieval of > text/image in the source to be more easy. Also just some ideas. This is also something I am looking forward to;-), but I don't know if it would be a good idea to create a subsection for each page of an source:-/. I would probably use this in such a way, like you have a census collection for the year 1900 as the main source, this could then be split up in two the states and countries. The extreme would then be to split it up to the point where it is only one page. Will those subsections be recursive, meaning that each subsection can include multiple subsections? Or am I misunderstanding you here? I understand it as a source inside a source, thus it should be recursive;-). But afterall having subsections, however these would be defined, is probably not the same as having media subsection references in the source reference, depeding on how you choose the fine granularity. Something that would be cool, would be to melt media and text. So that transcriptions would be directly linked to the position in the images, but that would probably to be too complicated and would lead to something like transcription software does. MfG Tobias ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Gramps-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-users |
Re: local gallery tab in source reference
|
|
2007/10/19, Tobias Gehrig <[hidden email]>:
Hi, No, not the date you made the reference. Continental european sources (at least roman catholic) are often parish registries, which are logs of birth/marriage/death. So every birth, the priest makes a log entry. The original registries have no page numbering or sections. The only way of finding the correct entry is the log date, hence the date in source reference. It must be said that today you normally check this on microfilm, so you would put the microfilm number of the page in the publication info, but still, it's cool to go to an archive once with the real books. > For future 3.0, you will have multiple notes, if you write down a Ok, GEDCOM allows several ways of doing this in my impression, so GRAMPS too. One is the way you use it. If it works for you, that's ok. The text GEDCOM attribute is there on source reference, but also in Source, perhaps a backward compatibility thing, I don't know. In my opinion, you should record all data in the source object. In GRAMPS 3.0 you will have the possibility of multiple notes, so it will become easier to manage large sources. The sourceref notes are for your 'ternary source' information in my view. That is, you have a source, and from that you deduce information which might not actually be in the source literally. You could add an analysis to the source about that in a note, but it looks convenient to add the analysis (so how you deduce info from a source for use as data of a person (eg 'previous entry is 1/1/1800 next is 5/1/1800, so this person is born between 1/1/1800 and 5/1/1800') Note that 3.0 will allow shared notes (not my favourite) and that might be usefull to avoid double information that you still want available easily in the sourceref too. I would prefer a source subsection structure, but that will not be in 3.0, so sharing the note in source and sourceref might not be a bad option for now. Anyway, now you know a bit what 3.0 will bring, you can structure your data so that transition will be smooth. <snip> No, that would probably be not very useful, since you would in only rare > Not the best solution perhaps, but I was thinking in the future of a Well, subsections is drawing board only, we concentrate on the 3.0 features now (multiple, rich text, shared notes, new database management, ....). After that, who knows, I'm sure the user community will be asked for feedback if it comes to it. Something that would be cool, would be to melt media and text. So that If only I had the time .... Benny ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Gramps-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-users |
«
Return to GRAMPS - User
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |