From: Benny M. <ben...@gm...> - 2013-05-26 20:23:37
|
All, WIth the new SrcAttribute, I went ahead and parsed all fields needed for Evidence Style and stored them as SrcAttributeType. This can always be undone later if we don't go ahead with this. I intend to change the GUI next to allow for SrcAttributeType SRCTYPE to have values as in Evidence Style, and then guide user is giving the other SrcAttribute needed for a good reference. The GEPS 018 is inadequate however in how best to proceed, see http://www.gramps-project.org/wiki/index.php?title=GEPS_018:_Evidence_style_sources#Proposed_changes I've put all in a Old data of GEP section, as there are no conclusions there on how to proceed. My idea, and where input is needed: 1/ After Pub. Info field, add a Generate button. On clicking a wizard starts to have user input a full correct citation. So user sets source type to one of those values defined in 'Evidence Style', and the GUI indicates which fields must be given, showing as he types the resulting F, S and L reference (whatever F, S, and L stand for ) . All code to make this possible is in srcattrtype.py. 2/ Above is all nice, and guarantees that user actually inputs all fields, but what do we store then as result in Pub. Info, Author or title? Do we store F, S or L somewhere, or do we let the user choose via a checkbox which fields go where? It would be nice if somebody is willing to extend the csv in trunk http://sourceforge.net/p/gramps/code/HEAD/tree/trunk/data/evidencestyle/evidence_style.csv with an author column, a title column and a pubinfo column, so as to indicate which field map to the gedcom fields http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_ORIGINATOR http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_DESCRIPTIVE_TITLE http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_PUBLICATION_FACTS If we had such a column we could map onto those 3 fields information given as Evidence Style Fields (parsing on reading Gedcom is not an possible though). 3/ Part of the correct reference is part of citation and not source. So, there, the F, S and L reference are shown as indication. If they have set the correct Source Type in the Source, we know what fields are still missing, and these should be given in the citation. Problem is that Date and Volume/Page are already present in the General Tab, but those only map to some of the fields in Evidence Style. My suggestion would be to show the F, S and L reference, and show there an Update button. Clicking that shows the same Wizard as in 1/, but prefills fields with the data of the source and only stores in Citation what is different from source. Again, if we add columns to the csv for Page/Volume and Date, we can use that in the wizard and automatically fill those fields. Well, I'll do a try with the GUI what works, but if anybody has specific idea, let it be known. If somebody is super enthusiastic and willing to add those 5 columns to the csv in Excell of openoffice, then let me know, and I'll explain better :-) Whatever we do, note: 1/ Old way is needed to keep working as that are the GEDCOM fields 2/ We don't want Aunt Martha to have problems with Evidence Style if she only wants to make a simple family tree. So what we do in GUI should be non-intrusive, like the buttons suggested above 3/ We could provide an option in the Preferences for experts: 'Only use Evidence Style fields for Source/Citation.' In which case we make Date, Volume/Page, Title, Author, Pub.Info and Abbreviation less prominent or something likewise Benny |
From: Nick H. <nic...@ho...> - 2013-05-27 11:38:38
|
On 26/05/13 21:23, Benny Malengier wrote: > 1/ After Pub. Info field, add a Generate button. On clicking a wizard > starts to have user input a full correct citation. So user sets source > type to one of those values defined in 'Evidence Style', and the GUI > indicates which fields must be given, showing as he types the > resulting F, S and L reference (whatever F, S, and L stand for ) . All > code to make this possible is in srcattrtype.py. I don't like the idea of a generate button and a wizard. We should display the fields necessary in the editors, and only fields that are needed for the source type. If "Author", "Abbreviation" or "Pub Info" are not needed, we shouldn't display them. Likewise for "Date" and "Volume/Page" for citations. Existing fields can be stored in the database in the same way as they are now. New fields can be stored as attributes. For Aunt Martha, we should provide a default source type which displays the fields as they are now. I think you are correct that F, S and L stand for Full, Short and Long. These refer to templates stored in the source type table. The templates are made up of the fields also defined in the same table. Displaying F, S, and L as the user enters data is a nice touch, but not necessary. The source type table should store the fields for each source type, along with a data type for validation. String, Integer and Date are probably all that are required. > > 2/ Above is all nice, and guarantees that user actually inputs all > fields, but what do we store then as result in Pub. Info, Author or > title? Do we store F, S or L somewhere, or do we let the user choose > via a checkbox which fields go where? > It would be nice if somebody is willing to extend the csv in trunk > http://sourceforge.net/p/gramps/code/HEAD/tree/trunk/data/evidencestyle/evidence_style.csv > with an author column, a title column and a pubinfo column, so as to > indicate which field map to the gedcom fields > http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_ORIGINATOR > <http://homepages.rootsweb.ancestry.com/%7Epmcbride/gedcom/55gcch2.htm#SOURCE_ORIGINATOR> > http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_DESCRIPTIVE_TITLE > <http://homepages.rootsweb.ancestry.com/%7Epmcbride/gedcom/55gcch2.htm#SOURCE_DESCRIPTIVE_TITLE> > http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#SOURCE_PUBLICATION_FACTS > <http://homepages.rootsweb.ancestry.com/%7Epmcbride/gedcom/55gcch2.htm#SOURCE_PUBLICATION_FACTS> > If we had such a column we could map onto those 3 fields information > given as Evidence Style Fields (parsing on reading Gedcom is not an > possible though). The option for F, S and L should be presented to the user when they generate a report. For Gedcom export, we should map the available Gramps fields onto the Gedcom fields as best we can. We will only be able to import into a default source type. > > 3/ Part of the correct reference is part of citation and not source. > So, there, the F, S and L reference are shown as indication. If they > have set the correct Source Type in the Source, we know what fields > are still missing, and these should be given in the citation. Yes. A source type will define fields used in both the source and citation editor. Only the appropriate fields for the source type should be displayed. The default source type will result in the same fields displayed at present. > Problem is that Date and Volume/Page are already present in the > General Tab, but those only map to some of the fields in Evidence Style. We should only use these fields if the are present in the source type definition. > My suggestion would be to show the F, S and L reference, and show > there an Update button. Clicking that shows the same Wizard as in 1/, > but prefills fields with the data of the source and only stores in > Citation what is different from source. > Again, if we add columns to the csv for Page/Volume and Date, we can > use that in the wizard and automatically fill those fields. > Again , I don't like the idea of a wizard here. It unnecessarily complicates the user interface. Nick. |
From: Benny M. <ben...@gm...> - 2013-05-27 12:37:17
|
2013/5/27 Nick Hall <nic...@ho...> > On 26/05/13 21:23, Benny Malengier wrote: > > 1/ After Pub. Info field, add a Generate button. On clicking a wizard > starts to have user input a full correct citation. So user sets source type > to one of those values defined in 'Evidence Style', and the GUI indicates > which fields must be given, showing as he types the resulting F, S and L > reference (whatever F, S, and L stand for ) . All code to make this > possible is in srcattrtype.py. > > > I don't like the idea of a generate button and a wizard. > > We should display the fields necessary in the editors, and only fields > that are needed for the source type. If "Author", "Abbreviation" or "Pub > Info" are not needed, we shouldn't display them. Likewise for "Date" and > "Volume/Page" for citations. > I agree, but when things become complicated, we need or a bigger editor windows to show all, or some sort of guided data entry. My current thinking is: 1/ Instead of the tab 'General' for source and citation, we show the tab 'Overview', which would have only few fields editable that make sense, and then show concise the important things. 2/ For a new citation/source, user starts on a new 'Definition' (??) tab. Here he can give source type. Setting a source type, generates the fields needed as per the template definition. Note that some people have asked already for some other editors such a setup, with overview on not new objects with a nicer layout. 3/I would like to enable some copy paste function though on the Definition tab. So, I would like to offer some mechanism to quickly copy paste or select existing parts of title/pub info (for users fixing imported gedcom or old gramps sources), and to import a bibtex and select fields from that. Perhaps a bottom part with buttons, or drag and drop to a top part with the actual fields? Need to try some GUI ideas for how to do this. 4/ In the definition tab, if entry is in a table, column for author, pubinfo can be added with checkbox to indicate what to use. Idea here is that we don't need our old Title, Author and Pub Info, but we do need to make clear to users what would be exported to Gedcom, as that is important. In Overview this could shown in a Gedcom section. Note: Abbreviation is for your local indexing system, so this is an editable field on Overview, just like privacy. As to Title, Pub Info and Author, perhaps best to make those just Attributes and deprecate them. Same for Page/Volume in citation. Date is special, as allowing the use of the date editor is not something we want to loose... Benny |
From: Nick H. <nic...@ho...> - 2013-05-27 16:13:25
|
On 27/05/13 13:37, Benny Malengier wrote: > 3/I would like to enable some copy paste function though on the > Definition tab. So, I would like to offer some mechanism to quickly > copy paste or select existing parts of title/pub info (for users > fixing imported gedcom or old gramps sources), and to import a bibtex > and select fields from that. Perhaps a bottom part with buttons, or > drag and drop to a top part with the actual fields? Need to try some > GUI ideas for how to do this. Yes, copy and paste would be useful for splitting up the "Volume/Page" field in citations as well. > > 4/ In the definition tab, if entry is in a table, column for author, > pubinfo can be added with checkbox to indicate what to use. Idea here > is that we don't need our old Title, Author and Pub Info, but we do > need to make clear to users what would be exported to Gedcom, as that > is important. In Overview this could shown in a Gedcom section. You could have a "Preview" tab to show a preview of the Gedcom output as well as the F, S and L formats. > > Note: Abbreviation is for your local indexing system, so this is an > editable field on Overview, just like privacy. Thanks, I was never clear what to use the abbreviation field for. > > As to Title, Pub Info and Author, perhaps best to make those just > Attributes and deprecate them. Same for Page/Volume in citation. Date > is special, as allowing the use of the date editor is not something we > want to loose... > I am happy to deprecate these fields. Do we need to define a data type with the source and citation attributes? If the attribute is a date, we could allow the usual Gramps validation and editing functionality. Nick. |
From: John R. <jr...@ce...> - 2013-05-27 15:26:25
|
On May 27, 2013, at 4:38 AM, Nick Hall <nic...@ho...> wrote: > > I think you are correct that F, S and L stand for Full, Short and Long. These refer to templates stored in the source type table. The templates are made up of the fields also defined in the same table. Displaying F, S, and L as the user enters data is a nice touch, but not necessary. > No, Full, Short (or subsequent), and List -- List as in Bibliography. For data entry we're only interested in Full, which contains all of the information needed for the other two. Reports will use Full, may use Short, and the Book Report could make a bibliography at the end using List format. Short is used for later citations of a single source, after the first citation is given in Full format. Regards, John Ralls |
From: Nick H. <nic...@ho...> - 2013-05-27 16:29:40
|
John, Thanks for clarifying this. So what I said earlier about selecting either F,S or L when generating a report is wrong. A bibliography report for use in books would be worth writing. Nick. On 27/05/13 16:26, John Ralls wrote: > On May 27, 2013, at 4:38 AM, Nick Hall <nic...@ho...> wrote: > >> I think you are correct that F, S and L stand for Full, Short and Long. These refer to templates stored in the source type table. The templates are made up of the fields also defined in the same table. Displaying F, S, and L as the user enters data is a nice touch, but not necessary. >> > No, Full, Short (or subsequent), and List -- List as in Bibliography. > For data entry we're only interested in Full, which contains all of the information needed for the other two. Reports > will use Full, may use Short, and the Book Report could make a bibliography at the end using List format. > > Short is used for later citations of a single source, after the first citation is given in Full format. > > Regards, > John Ralls > > > > |
From: Enno B. <enn...@gm...> - 2013-05-27 15:33:31
|
Gents, > > We should display the fields necessary in the editors, and only > fields that are needed for the source type. If "Author", > "Abbreviation" or "Pub Info" are not needed, we shouldn't display > them. Likewise for "Date" and "Volume/Page" for citations. > I have a problem with this. That's because in my experience the idea that source type can define needed fields is not supported by reality. Proof is that results of the same type, say some civil birth/marriage or death record found on our national Wie Was Wie site, do not only depend on the type B/M/D, but also on the data provider, that is the software used by the local (mostly provincial) archive that supplies the data to the national site. Moreover, the fields available on the archives own site, may be different from the aggregated ones available on mentioned national site. Adapting EE types to the above, and this is just for The Netherlands, is a hell of a job, I think, and if that leads to say a 1000 types for the whole world, which is very likely, when you want to cover sites all over the world, is just crazy. I have RootsMagic here, which I acquired to connect to the FS tree, but when I try to add a source in that, the choice of templates simply scares me away. > I agree, but when things become complicated, we need or a bigger > editor windows to show all, or some sort of guided data entry. > > My current thinking is: > > 1/ Instead of the tab 'General' for source and citation, we show the > tab 'Overview', which would have only few fields editable that make > sense, and then show concise the important things. I like the idea of an overview, but because of the above, I have no idea how to select fields that make sense. > 3/I would like to enable some copy paste function though on the > Definition tab. So, I would like to offer some mechanism to quickly > copy paste or select existing parts of title/pub info (for users > fixing imported gedcom or old gramps sources), and to import a bibtex > and select fields from that. Perhaps a bottom part with buttons, or > drag and drop to a top part with the actual fields? Need to try some > GUI ideas for how to do this. Having a lot of sources that need fixing, this is something that I really like. > As to Title, Pub Info and Author, perhaps best to make those just > Attributes and deprecate them. Same for Page/Volume in citation. Date > is special, as allowing the use of the date editor is not something we > want to loose... I would really like the author to become more important, and on the long term implemented as the agent in the GedcomX draft. Author/Agent then refers to say a local government or church that issued a document, or a relative (person in Gramps) that provided info by email. Title comes next in my view, i.e. I like to organize sources by author, so that I can distinguish church books which have very generic titles by themselves by their author. Depending on citation style, the combo may be displayed in any order, specified by template or user. Page/Volume are also things I like to keep, and Record number too. Currently I have no idea where to put that. Pub Info is a field I never understood. Was that meant for ISBN or so? No idea? Sometimes I put a URL in there, but I don't think it was meant for that. Which brings me to that URL. I definitely want that on the standard screen. On FamilySearch, every item in my Source Box has 4 fields: Title, URL, Citation, Notes. That's all. Adding Author, Volume/Page, Record Number, Date, and Source Text, would result in 9 fields that cover about everything I can think of right now. Guess that's my generic template then. And in this context, Citation is the scientific term, that string that can be F, L, or S, not what we have in Gramps, or know from Ancestry, PAF, and so forth. regards, Enno |
From: Nick H. <nic...@ho...> - 2013-05-27 16:21:18
|
On 27/05/13 16:33, Enno Borgsteede wrote: > Page/Volume are also things I like to keep, and Record number too. > Currently I have no idea where to put that. "Page", "Volume", "Record Number" and "Entry Number" could all be attributes. Some source types could use all of them, others only where applicable. > > Pub Info is a field I never understood. Was that meant for ISBN or so? > No idea? Sometimes I put a URL in there, but I don't think it was > meant for that. > "Pub Info" and "ISBN" are useful for books. We don't want to display them for all source types. > Which brings me to that URL. I definitely want that on the standard > screen. Where a source type refers to an internet source, we will certainly want "URL" as an attribute. > > On FamilySearch, every item in my Source Box has 4 fields: Title, URL, > Citation, Notes. That's all. Adding Author, Volume/Page, Record > Number, Date, and Source Text, would result in 9 fields that cover > about everything I can think of right now. Guess that's my generic > template then. Yes. You should be able to create source types specific to FamilySearch. Nick. |
From: John R. <jr...@ce...> - 2013-05-27 16:45:20
|
On May 27, 2013, at 8:33 AM, Enno Borgsteede <enn...@gm...> wrote: > Gents, >> >> We should display the fields necessary in the editors, and only fields that are needed for the source type. If "Author", "Abbreviation" or "Pub Info" are not needed, we shouldn't display them. Likewise for "Date" and "Volume/Page" for citations. > I have a problem with this. That's because in my experience the idea that source type can define needed fields is not supported by reality. Proof is that results of the same type, say some civil birth/marriage or death record found on our national Wie Was Wie site, do not only depend on the type B/M/D, but also on the data provider, that is the software used by the local (mostly provincial) archive that supplies the data to the national site. Moreover, the fields available on the archives own site, may be different from the aggregated ones available on mentioned national site. > > Adapting EE types to the above, and this is just for The Netherlands, is a hell of a job, I think, and if that leads to say a 1000 types for the whole world, which is very likely, when you want to cover sites all over the world, is just crazy. > > I have RootsMagic here, which I acquired to connect to the FS tree, but when I try to add a source in that, the choice of templates simply scares me away. EE's templates are very much directed at the US-based researcher. While the necessary *content* of all citations is the same (title, creator, date, publisher or repository information, provenance if not an official record, etc.), formats will differ by locale: I'd be surprised indeed to learn that Dutch genealogy journals use EE -- or even Chicago Manual of Style -- formatted citations. Electronic archives are another matter, because they are very uneven in providing the actual source information needed to properly evaluate the source. Just using the EE template without having the explanatory material that goes along with it can be a bit confusing. This is compounded by the fact that templates in programs like Roots Magic are based on the examples that Mills provides as front-matter to each section and republishes in her "Quick Sheets". They're *examples*, intended to be modified as necessary by someone who's read and understands the book. The "Quick Sheets" are intended for you to bring with you to the library or repository so that you can make sure that you get a good citation as you take your research notes. Basing a data-entry template on them without allowing for some flexibility promotes neither usability nor collecting good citations. Regards, John Ralls |
From: Tim L. <guy...@gm...> - 2013-05-28 17:38:31
|
enno wrote > Title comes next in my view, i.e. I like to organize sources by author, > so that I can distinguish church books which have very generic titles by > themselves by their author. Depending on citation style, the combo may > be displayed in any order, specified by template or user. > > Page/Volume are also things I like to keep, and Record number too. > Currently I have no idea where to put that. > > Pub Info is a field I never understood. Was that meant for ISBN or so? > No idea? Sometimes I put a URL in there, but I don't think it was meant > for that. Most of the fields are derived from GEDCOM, which has descriptions of what to put in them. For example: SOURCE_PUBLICATION_FACTS: = {Size=248} When and where the record was created. For published works, this includes information such as the city of publication, name of the publisher, and year of publication. For an unpublished work, it includes the date the record was created and the place where it was created. For example, the county and state of residence of a person making a declaration for a pension or the city and state of residence of the writer of a letter. SOURCE_DESCRIPTIVE_TITLE: = {Size=1:248} The title of the work, record, or item and, when appropriate, the title of the larger work or series of which it is a part. For a published work, a book for example, might have a title plus the title of the series of which the book is a part. A magazine article would have a title plus the title of the magazine that published the article. For An unpublished work, such as: * A letter might include the date, the sender, and the receiver. * A transaction between a buyer and seller might have their names and the transaction date. * A family Bible containing genealogical information might have past and present owners and a physical description of the book. * A personal interview would cite the informant and interviewer. Regards, Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/New-SrcAttribute-and-Evidence-Style-tp4660442p4660490.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Benny M. <ben...@gm...> - 2013-05-27 16:25:29
|
2013/5/27 Enno Borgsteede <enn...@gm...> > Gents, > > > We should display the fields necessary in the editors, and only fields >> that are needed for the source type. If "Author", "Abbreviation" or "Pub >> Info" are not needed, we shouldn't display them. Likewise for "Date" and >> "Volume/Page" for citations. >> > I have a problem with this. That's because in my experience the idea > that source type can define needed fields is not supported by reality. > Proof is that results of the same type, say some civil birth/marriage or > death record found on our national Wie Was Wie site, do not only depend on > the type B/M/D, but also on the data provider, that is the software used by > the local (mostly provincial) archive that supplies the data to the > national site. Moreover, the fields available on the archives own site, may > be different from the aggregated ones available on mentioned national site. > Some things here. There is the original manuscript, which is a source. This was transferred to microfilm, which is another source. This was transferred to a database by some people, which is third source This was sold/given to people, who put it on websites, which are extra sources. In every step errors might have been made, and for a professional genealogist, it will be important to distinguish these on the source level. For a normal user, he might consider all of the above a single source, and put the link to the true form via repository (media type there has microfilm, ...). Gramps does not force a way of working normally. So, we have two ways of working here. 1/ normal user see birth record church, and does not distinguish between the site it is found on. He might add repositories. This user will have problems using templates for source, as his source of information, typically a website, might not have all, or the correct data for the original source. One could argue this user doesn't care too much either way, and will be happy with a generic entry like pub.info, ... 2/a professional user will distinguish between sources, so she is able to indicate what information comes from what place. > Adapting EE types to the above, and this is just for The Netherlands, is a > hell of a job, I think, and if that leads to say a 1000 types for the whole > world, which is very likely, when you want to cover sites all over the > world, is just crazy. > Is this really true? Is it USA/UK oriented? I did not try to check yet where a site like Wie is wie would fall under. I would hope there is a generic entry for this already present. > > I have RootsMagic here, which I acquired to connect to the FS tree, but > when I try to add a source in that, the choice of templates simply scares > me away. > > I agree, but when things become complicated, we need or a bigger editor > windows to show all, or some sort of guided data entry. > > My current thinking is: > > 1/ Instead of the tab 'General' for source and citation, we show the tab > 'Overview', which would have only few fields editable that make sense, and > then show concise the important things. > > I like the idea of an overview, but because of the above, I have no idea > how to select fields that make sense. > The fields are in templates. The question is if they suffice. As you indicate below, if you think of extra needed generic templates, then now is the time to raise it. A genealogy forum to flesh things out might be more suited though. > > 3/I would like to enable some copy paste function though on the > Definition tab. So, I would like to offer some mechanism to quickly copy > paste or select existing parts of title/pub info (for users fixing imported > gedcom or old gramps sources), and to import a bibtex and select fields > from that. Perhaps a bottom part with buttons, or drag and drop to a top > part with the actual fields? Need to try some GUI ideas for how to do this. > > Having a lot of sources that need fixing, this is something that I really > like. > This is true for all software changes, eg citaitons, .... Things don't break with this change. Doing nothing is always an option > > As to Title, Pub Info and Author, perhaps best to make those just > Attributes and deprecate them. Same for Page/Volume in citation. Date is > special, as allowing the use of the date editor is not something we want to > loose... > > I would really like the author to become more important, and on the long > term implemented as the agent in the GedcomX draft. Author/Agent then > refers to say a local government or church that issued a document, or a > relative (person in Gramps) that provided info by email. > > Title comes next in my view, i.e. I like to organize sources by author, so > that I can distinguish church books which have very generic titles by > themselves by their author. Depending on citation style, the combo may be > displayed in any order, specified by template or user. > > Page/Volume are also things I like to keep, and Record number too. > Currently I have no idea where to put that. > If those are present or not depends on the template used. As with all attributes in Gramps, more can be be added though. Benny > > Pub Info is a field I never understood. Was that meant for ISBN or so? No > idea? Sometimes I put a URL in there, but I don't think it was meant for > that. > > Which brings me to that URL. I definitely want that on the standard screen. > > On FamilySearch, every item in my Source Box has 4 fields: Title, URL, > Citation, Notes. That's all. Adding Author, Volume/Page, Record Number, > Date, and Source Text, would result in 9 fields that cover about everything > I can think of right now. Guess that's my generic template then. > > And in this context, Citation is the scientific term, that string that can > be F, L, or S, not what we have in Gramps, or know from Ancestry, PAF, and > so forth. > > regards, > > Enno > > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: Benny M. <ben...@gm...> - 2013-05-27 20:24:57
|
2013/5/27 John Ralls <jr...@ce...> > > On May 27, 2013, at 4:38 AM, Nick Hall <nic...@ho...> wrote: > > > > > I think you are correct that F, S and L stand for Full, Short and Long. > These refer to templates stored in the source type table. The > templates are made up of the fields also defined in the same table. > Displaying F, S, and L as the user enters data is a nice touch, but not > necessary. > > > > No, Full, Short (or subsequent), and List -- List as in Bibliography. > For data entry we're only interested in Full, which contains all of the > information needed for the other two. Reports > Looking in the csv, I see for Artifact, Portrait, that there is in L a field REPOSITORY1 and in F REPOSITORY2. Is this an error in the csv then? Another explantation? Benny > will use Full, may use Short, and the Book Report could make a > bibliography at the end using List format. > > Short is used for later citations of a single source, after the first > citation is given in Full format. > > Regards, > John Ralls > > > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: John R. <jr...@ce...> - 2013-05-27 21:27:02
|
On May 27, 2013, at 1:24 PM, Benny Malengier <ben...@gm...> wrote: > > > > 2013/5/27 John Ralls <jr...@ce...> > > On May 27, 2013, at 4:38 AM, Nick Hall <nic...@ho...> wrote: > > > > > I think you are correct that F, S and L stand for Full, Short and Long. These refer to templates stored in the source type table. The templates are made up of the fields also defined in the same table. Displaying F, S, and L as the user enters data is a nice touch, but not necessary. > > > > No, Full, Short (or subsequent), and List -- List as in Bibliography. > For data entry we're only interested in Full, which contains all of the information needed for the other two. Reports > > Looking in the csv, I see for Artifact, Portrait, that there is in L a field REPOSITORY1 and in F REPOSITORY2. > > Is this an error in the csv then? Another explantation? > I'd say it's an error: The book has the same names (Repository) and values (Cammie G. Henry Research Center, Northwestern State University) for both the "First (Full) Reference Note" and "Source List Entry". That error is repeated in 50:Census Records:federal census and 114:National Government Records:Manuscripts:National Archives, except in the latter "REPOSITORY1" appears in both "L" and "F" while "REPOSITORY2" is in "S". In both cases the book titles each entry "Repository". I guess I should note that I'm using EE Second Edition and that Yates used the first edition, so the errors might have been Mills's (but it seems unlikely -- why would she have stuck a number on a field name?). Do you want to tell Yates or shall I? Regards, John Ralls |
From: Benny M. <ben...@gm...> - 2013-05-27 20:38:48
|
2013/5/27 Benny Malengier <ben...@gm...> > > > > > 2013/5/27 Enno Borgsteede <enn...@gm...> >> >> Gents, >> >> >>> We should display the fields necessary in the editors, and only fields that are needed for the source type. If "Author", "Abbreviation" or "Pub Info" are not needed, we shouldn't display them. Likewise for "Date" and "Volume/Page" for citations. >> >> I have a problem with this. That's because in my experience the idea that source type can define needed fields is not supported by reality. Proof is that results of the same type, say some civil birth/marriage or death record found on our national Wie Was Wie site, do not only depend on the type B/M/D, but also on the data provider, that is the software used by the local (mostly provincial) archive that supplies the data to the national site. Moreover, the fields available on the archives own site, may be different from the aggregated ones available on mentioned national site. > > > Some things here. > There is the original manuscript, which is a source. > This was transferred to microfilm, which is another source. > This was transferred to a database by some people, which is third source > This was sold/given to people, who put it on websites, which are extra sources. > > In every step errors might have been made, and for a professional genealogist, it will be important to distinguish these on the source level. > > For a normal user, he might consider all of the above a single source, and put the link to the true form via repository (media type there has microfilm, ...). > > Gramps does not force a way of working normally. > > So, we have two ways of working here. > 1/ normal user see birth record church, and does not distinguish between the site it is found on. He might add repositories. This user will have problems using templates for source, as his source of information, typically a website, might not have all, or the correct data for the original source. > One could argue this user doesn't care too much either way, and will be happy with a generic entry like pub.info, ... > 2/a professional user will distinguish between sources, so she is able to indicate what information comes from what place. > >> >> Adapting EE types to the above, and this is just for The Netherlands, is a hell of a job, I think, and if that leads to say a 1000 types for the whole world, which is very likely, when you want to cover sites all over the world, is just crazy. > > > Is this really true? Is it USA/UK oriented? I did not try to check yet where a site like Wie is wie would fall under. I would hope there is a generic entry for this already present. Looking into this. If you open the csv at trunk/data/evidencestyle, then entry 70 is Church Records. Drilling down this can be Church Books (original), Image Copies and Derivatives. So, for a typical Birth Record on Wie Was Wie site, I assume you would use "Church Records, Image Copies, Digitized online. " Gramps would then indicate that for a full reference, following fields can be used: [CHURCH (AUTHOR)] [LOCATION] [RECORD SERIES] [ITEM TYPE OR FORMAT] [WEBSITE TITLE] [URL (DIGITAL LOCATION)] [YEAR(S)] [RECORD BOOK ID (GENERIC LABEL)] [PAGE(S)] [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] [ITEM TYPE OR FORMAT] [WEBSITE TITLE] [ACCESS DATE] This seems ok to me. In current Gramps, you would give log date or item of interest, and if all goes good you might have added other things. Problem for us here is that [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] is one entry. To give a nice date entry, we would need to split those up in two fields. Benny |
From: John R. <jr...@ce...> - 2013-05-27 21:32:28
|
On May 27, 2013, at 1:38 PM, Benny Malengier <ben...@gm...> wrote: > > > > 2013/5/27 Benny Malengier <ben...@gm...> > > > > > > > > > > 2013/5/27 Enno Borgsteede <enn...@gm...> > >> > >> Gents, > >> > >> > >>> We should display the fields necessary in the editors, and only fields that are needed for the source type. If "Author", "Abbreviation" or "Pub Info" are not needed, we shouldn't display them. Likewise for "Date" and "Volume/Page" for citations. > >> > >> I have a problem with this. That's because in my experience the idea that source type can define needed fields is not supported by reality. Proof is that results of the same type, say some civil birth/marriage or death record found on our national Wie Was Wie site, do not only depend on the type B/M/D, but also on the data provider, that is the software used by the local (mostly provincial) archive that supplies the data to the national site. Moreover, the fields available on the archives own site, may be different from the aggregated ones available on mentioned national site. > > > > > > Some things here. > > There is the original manuscript, which is a source. > > This was transferred to microfilm, which is another source. > > This was transferred to a database by some people, which is third source > > This was sold/given to people, who put it on websites, which are extra sources. > > > > In every step errors might have been made, and for a professional genealogist, it will be important to distinguish these on the source level. > > > > For a normal user, he might consider all of the above a single source, and put the link to the true form via repository (media type there has microfilm, ...). > > > > Gramps does not force a way of working normally. > > > > So, we have two ways of working here. > > 1/ normal user see birth record church, and does not distinguish between the site it is found on. He might add repositories. This user will have problems using templates for source, as his source of information, typically a website, might not have all, or the correct data for the original source. > > One could argue this user doesn't care too much either way, and will be happy with a generic entry like pub.info, ... > > 2/a professional user will distinguish between sources, so she is able to indicate what information comes from what place. > > > >> > >> Adapting EE types to the above, and this is just for The Netherlands, is a hell of a job, I think, and if that leads to say a 1000 types for the whole world, which is very likely, when you want to cover sites all over the world, is just crazy. > > > > > > Is this really true? Is it USA/UK oriented? I did not try to check yet where a site like Wie is wie would fall under. I would hope there is a generic entry for this already present. > > > Looking into this. If you open the csv at trunk/data/evidencestyle, then entry 70 is Church Records. > Drilling down this can be Church Books (original), Image Copies and Derivatives. > So, for a typical Birth Record on Wie Was Wie site, I assume you would use > "Church Records, Image Copies, Digitized online. " > Gramps would then indicate that for a full reference, following fields can be used: > > [CHURCH (AUTHOR)] > [LOCATION] > [RECORD SERIES] > [ITEM TYPE OR FORMAT] > [WEBSITE TITLE] > [URL (DIGITAL LOCATION)] > [YEAR(S)] > [RECORD BOOK ID (GENERIC LABEL)] > [PAGE(S)] > [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] > [ITEM TYPE OR FORMAT] > [WEBSITE TITLE] > [ACCESS DATE] > > > This seems ok to me. In current Gramps, you would give log date or item of interest, and if all goes good you might have added other things. > > Problem for us here is that > [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] > is one entry. To give a nice date entry, we would need to split those up in two fields. > So split the fields. If you want, tell Yates that you're doing so. Have you even told him that you're using his templates in Gramps? Regards, John Ralls |
From: Benny M. <ben...@gm...> - 2013-05-28 06:38:30
|
2013/5/27 John Ralls <jr...@ce...> > > > So split the fields. If you want, tell Yates that you're doing so. Have you > even told him that you're using his templates in Gramps? > On his website it's written " an open and freely available parametrization of Evidence Style to the community as of this release in February 2010" So I did not write him to ask permission or so. I'll write him to let him know and ask if he himself did any extra corrections. Benny > > Regards, > John Ralls > > > |
From: Enno B. <enn...@gm...> - 2013-05-27 21:41:34
|
Benny, > Looking into this. If you open the csv at trunk/data/evidencestyle, > then entry 70 is Church Records. > Drilling down this can be Church Books (original), Image Copies and > Derivatives. > So, for a typical Birth Record on Wie Was Wie site, I assume you would use > "Church Records, Image Copies, Digitized online. " > Gramps would then indicate that for a full reference, following fields > can be used: > > [CHURCH (AUTHOR)] > [LOCATION] > [RECORD SERIES] > [ITEM TYPE OR FORMAT] > [WEBSITE TITLE] > [URL (DIGITAL LOCATION)] > [YEAR(S)] > [RECORD BOOK ID (GENERIC LABEL)] > [PAGE(S)] > [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] > [ITEM TYPE OR FORMAT] > [WEBSITE TITLE] > [ACCESS DATE] H'm, I guess that I will never use any template at all, but concentrate on the fields instead. And here, I see a couple of weird things, which may be partly caused by copy paste from that CSV. It looks like you're referring to entry 73 here, and there I see less entries in the CSV than quoted here. Anyway, no matter the copy paste, I see that field are not normalized, as there is a web site title and a URL, which IMO should be part of a web site object. That's my IT hat speaking. Same for first and last names from authors, location of a church, etc. So for me, EE is crap, focused on presentation, not on the recording of the origin of evidence, which is what I need. I don't really care about citation style at all, but what I do care about is to record where I got the information, which is why I do need proper fields, no 170 stinking templates from the USA, none of which really fit my needs. > Problem for us here is that > [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] > is one entry. To give a nice date entry, we would need to split those > up in two fields. > I agree. Item is a vague term, which I assume is something like a record number, or ID, which is some short string, while dates can and should be checked. regards, Enno |
From: Enno B. <enn...@gm...> - 2013-05-27 21:55:11
|
Nick, > For Aunt Martha, we should provide a default source type which > displays the fields as they are now. Really? I think that the default fields as they are defined in GEDCOM are not very easy to understand. Why not use some more generic fields that are more human understandable? Maybe use GedcomX source description and reference fields as a source of inspiration. Reading the issues there, it looks like there is more understanding of the difference between recording source information and the writing of citations than there is in EE. regards, Enno |
From: Tim L. <guy...@gm...> - 2013-05-28 17:07:06
|
enno wrote > Nick, >> For Aunt Martha, we should provide a default source type which >> displays the fields as they are now. > Really? I think that the default fields as they are defined in GEDCOM > are not very easy to understand. Why not use some more generic fields > that are more human understandable? Maybe use GedcomX source description > and reference fields as a source of inspiration. There are plenty of guidelines on how to use the various default fields. If you are going to use sources and citations, the it is a good idea to consider guidelines, so that you don't have to reinvent the world, and so that it is easier to transfer information between users. I use [1] which provides guidance on how information should be distributed between the Source record and the Citation record, and also the sort of thing that should be placed in Title, Author etc. It is designed for use with PAF, but PAF seems to use essentially the same fields as Gramps, so there is no problem in mapping to Gramps. It provides general guidelines, and also specific guidelines for specific document types such as census, certificate etc. There is also [2], but this is for FTW, which uses a 'Master Source' although this just seems to be the place where the 'Title' is stored. [1] http://svpafug.org/pages/docgdlns.html [2] http://west-penwith.org.uk/misc/ftmsour.htm Regards, Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/New-SrcAttribute-and-Evidence-Style-tp4660442p4660488.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |
From: Nick H. <nic...@ho...> - 2013-05-27 22:26:12
|
On 27/05/13 22:55, Enno Borgsteede wrote: >> For Aunt Martha, we should provide a default source type which >> displays the fields as they are now. > Really? I think that the default fields as they are defined in GEDCOM > are not very easy to understand. Why not use some more generic fields > that are more human understandable? Maybe use GedcomX source > description and reference fields as a source of inspiration. The Gramps fields are quite easy to understand if your source is a book. For the source you can enter a title, author and publisher; and for the citation you can enter a page number. For other types of source you have to invent your own conventions. For example, when I cite a census I enter something like "Class: RG11; Piece: 1234; Folio: 56; Page: 78" into the "Volume/Page" field. I would have no problem renaming the "Volume/Page" field to "Reference" to make it more generic. > > Reading the issues there, it looks like there is more understanding of > the difference between recording source information and the writing of > citations than there is in EE. I agree with you that the EE templates are very much American biased. I assume that we will be able to write our own templates and store them in the database. Nick. |
From: John R. <jr...@ce...> - 2013-05-27 23:24:12
|
On May 27, 2013, at 2:41 PM, Enno Borgsteede <enn...@gm...> wrote: > Benny, >> Looking into this. If you open the csv at trunk/data/evidencestyle, >> then entry 70 is Church Records. >> Drilling down this can be Church Books (original), Image Copies and >> Derivatives. >> So, for a typical Birth Record on Wie Was Wie site, I assume you would use >> "Church Records, Image Copies, Digitized online. " >> Gramps would then indicate that for a full reference, following fields >> can be used: >> >> [CHURCH (AUTHOR)] >> [LOCATION] >> [RECORD SERIES] >> [ITEM TYPE OR FORMAT] >> [WEBSITE TITLE] >> [URL (DIGITAL LOCATION)] >> [YEAR(S)] >> [RECORD BOOK ID (GENERIC LABEL)] >> [PAGE(S)] >> [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] >> [ITEM TYPE OR FORMAT] >> [WEBSITE TITLE] >> [ACCESS DATE] > H'm, I guess that I will never use any template at all, but concentrate > on the fields instead. And here, I see a couple of weird things, which > may be partly caused by copy paste from that CSV. It looks like you're > referring to entry 73 here, and there I see less entries in the CSV than > quoted here. Yes, Benny combined the L and F entries. He's correct, and it's an example of how having the book is helpful (even though he doesn't), because the example text helps to explain what the fields mean: Listing: [CHURCH (AUTHOR)] [LOCATION] [RECORD SERIES] St. Lawrence Church (Oxhill, Warwickshire, England), Parish Registers, 1568-1840, [ITEM TYPE...] [WEBSITE TITLE] Digital Images, <i>St. Lawrence Church, Oxhill</i>, [URL (DIGITAL LOCATION)] [YEAR(S)] http://www.oxhill.org.uk/ChurchRegisters/Registers.htm : 2006 Full: [CHURCH (AUTHOR)] [LOCATION] 1. St. Lawrence Church, (Oxhill, Warwickshire, England), [RECORD BOOK ID (GENERIC...)] [PAGES] Banns of Marriage, 1754-1794, unnumbered p. 1, [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] [ITEM TYPE...] "Mr." Thomas Ward and Martha Rowley, 19 October 1574[sic], digital images, [WEBSITE TITLE] <i>St. Lawrence Church, Oxhill</i> [URL (DIGITAL LOCATION)] [ACCESS DATE] (http://www.oxhill.org.uk/ChurchRegisters/Registers.htm : accessed 20 September 2006) In the source listing she's giving as the record series the overall name of everything that's in that URL, while in the actual citation she's naming the actual section of the website that the record (doesn't actually) come from. > > Anyway, no matter the copy paste, I see that field are not normalized, > as there is a web site title and a URL, which IMO should be part of a > web site object. That's my IT hat speaking. Same for first and last > names from authors, location of a church, etc. So for me, EE is crap, > focused on presentation, not on the recording of the origin of evidence, > which is what I need. I don't really care about citation style at all, > but what I do care about is to record where I got the information, which > is why I do need proper fields, no 170 stinking templates from the USA, > none of which really fit my needs. That's your SQL hat speaking. Time to put it back in the closet and think NoSQLy. ;-) If these data are normalized they'd just have to be joined every time you wanted to use them. Yes, it would save a little space, but only at the cost of more complex queries and slower response. >> Problem for us here is that >> [ITEM OF INTEREST & DATE FOR UNPAGINATED ENTRY] >> is one entry. To give a nice date entry, we would need to split those >> up in two fields. >> > I agree. Item is a vague term, which I assume is something like a record > number, or ID, which is some short string, while dates can and should be > checked. > Maybe. Consider a thick record book with 50 or so entries per page and no page numbers, but each entry is dated (or the first entry for a date or on a page is dated and the rest have " or do. where the date would be). It might be tabular, with the next column being the groom's name in a marriage register, or if it's a clerk's record book it might say "Marriage return of Rev. So and so, joined groom, son of..." and you could use "date: groom" or "Rev. So and so on date" as your indicator. No, the date doesn't need to be checked, at least not for this field. It's just to help someone checking your source (maybe even you!) to find the exact record you're citing. Regards, John Ralls |
From: Enno B. <enn...@gm...> - 2013-05-28 11:37:38
|
John, > That's your SQL hat speaking. Time to put it back in the closet and > think NoSQLy. ;-) If these data are normalized they'd just have to be > joined every time you wanted to use them. Yes, it would save a little > space, but only at the cost of more complex queries and slower response. Ok, ok, forget SQL. When I wrote normalized I was thinking about the design where you put fields in the right tables. We have that in Gramps, even though Gramps is noSQL. Person names are in the person table, dates in the events, and so forth. I call that normalized, even though it's not in a pure relational way. That's OK. Likewise, we put author and title in the source table, page/volume and date in the citation table, which is where I also paste the contents from a record that I find on FamilySearch or Wie Was Wie. So far, so good. Now, with the evidence style prototype, which I just tried in trunk, it appears as if everything goes to the citation table now. In one way, I think that's very simple and straightforward, but it also looks like a diversion from the way we went from sources to citations in Gramps 3.4. For clarity this may be a good decision. With evidence style citations, not sources as it is called in GEPS 018 now, users put every field they need for proper citation in the citation window, and then Gramps generates the proper citation string in reports, depending on the template and the F, L, S stuff. That's a plus. At the moment, it does not really work that way though, because Gramps as it is in trunk now does not accept an empty source record, which is what I think we will get when users put everything evidence or whatever style in the citations right away. This may also be more like GedcomX does things. cheers, Enno |
From: Enno B. <enn...@gm...> - 2013-05-28 12:47:31
|
Nick, > The Gramps fields are quite easy to understand if your source is a > book. For the source you can enter a title, author and publisher; and > for the citation you can enter a page number. > > For other types of source you have to invent your own conventions. For > example, when I cite a census I enter something like "Class: RG11; > Piece: 1234; Folio: 56; Page: 78" into the "Volume/Page" field. Ah, yes, and that's where I run into trouble. My database is a mixture of all sorts of citation styles. My father's, which he created when he had to work with the 3 source lines available in Brother's Keeper, where there were no fields like title, author, and so forth, and the mess that I created myself in PAF and Gramps. Templates can be a perfect way to avoid having to invent your own conventions and maintaining them, which is a big problem for an undisciplined person like me. And I think most of the items you mention are quite generic, aren't they? > I agree with you that the EE templates are very much American biased. > I assume that we will be able to write our own templates and store > them in the database. Yes, reading Benny's latest message, it looks like that. But for me, deleting the EE templates is more important now. Maybe not so much because they are American, but just because they are so much. Personally, I may be able to handle a few, like the magic number of 7 items/digits that can people can memorize in one go. So I would toss the EE ones, and create my own, or get some from the NGV (Dutch genealogical society), if they are prepared for that. I would then use templates for say FamilySearch, Wie Was Wie, real artefacts in libraries, and in my own 'repository', and maybe separate ones for civil and church registries. That's a handful, and it's all I need, I think. What I don't know yet is how this will affect data exchange. What will happen when a US relative sends a Gramps XML made with EE? What if I send my minimalist Borgia style citations to that relative in the US? No idea! regards, Enno |
From: Benny M. <ben...@gm...> - 2013-06-04 13:07:24
|
2013/6/4 Enno Borgsteede <enn...@gm...> > John, > > I can't read Benny's mind, so I don't think I'd say that it's too soon to implement EE templates. Several other similar > programs already have. I *have* said, so often that I'm getting tired of it, that EE is US-centric and that others need > to point us to their national standards if such exist. Nobody has, which is leading me to think that those standards > exist only in the US. > > I spent a couple of days on the web, visiting FHISO and GedcomX, and > Cyndi's List, and came to the conclusion that there is no standard. Some > might think that EE is a standard, but if it were, I would think that it > would be on the FHISO or GedcomX short list, and I know it's not. > > Treat EE's templates as examples. Understand what are the principles underlying those examples (which are explained > in the first two chapters) and work out similar examples for the record types that you use. If your country has no > genealogy journals, look at history journals and find out what citation style they use. Modify your examples to meet and > extend those citation styles just as Mills extended CMS. Write it up on a website or blog and get your local genealogy > society to review it. Adjust as necessary to satisfy their criticism, then get them to adopt the result. Write templates > and add them to Gramps. > > Thanks to a link on Cyndi's List, I found a better way. It's called > Simple Citations, has just a few templates, and contrary to EE it is > consistent w.r.t. the use of attributes. I'm trying to get in touch with > the author Jeff La Marca. His templates are free, but I'd like to get in > touch anyway. > > http://www.simplecitation and s.com/ <http://www.simplecitations.com/> > > When I find a need to expand these to support local sources, I will do > that later. Most important for me now is to give myself and fellow Gramps > users an alternative that I think is both easy to use and consistent. The > latter is important to me, because a small set of attributes, used in a > consistent way, is a key factor in data exchange. > > > A template system will be helpful for them so long as it's based on sound genealogical research > principles. For the cases where EE applies, we can be confident that we're supplying sound advice. I think that > for any other cases that we support we need to be just as sure that the advice is also sound. > > I think the above is sound, unlike EE, which violates all principles of > what I call sound. First is the enormous lack of consistency, second the > fact that like Tamura Jones says, you need a wizard to find the right > template: > > http://www.tamurajones.net/GenealogyCitationStandard.xhtml > > As far as I'm concerned the idea of templates is good, but EE is not the > right basis, not even for experts like my fellow countryman Tamura Jones, > nor for Randy Seaver for that matter. > > As a consequence, I think that the current implementation of EE based > attributes must be made completely optional in such a way that I will be > able to run Gramps 4.1 without seeing any of ESM messy attributes ever. I'm > already looking at the code to figure out how alternative templates can be > added. > > Simple Citations are my first choice for that. > Ok, about the code in the GEP 18, some things. 1/I intend to merge the given and surname author fields to a single author in bibtex style. That means, the code will assume different authors are joined with ' & ' in the attribute and in style: surname, given I would use & to join authors to make it international instead of the bibtex 'and'. The GUI might still show surname and given fields though for simplicity to the users, the storage would be in a single attribute though. 2/I will split in the csv the field column in two columns: field attribute and field description. This will allow to merge many of the attributes now in the EE csv. Eg, all different author forms, and all different title forms will be one, but allow for a different description in the GUI when entering data. 3/in light of above, the EE styles will already be much clearer when seen as attributes in Gramps. Reusing attributes will also allow to easily change template, and not needing to retype fields. Other styles are welcome though. If you make other styles, keep in mind that editing the csv is dangerous if above changes are not yet done/committed by me. Adding the new styles you might want via the template editor later and copying it over from the template editor to the code before release, might also be easier than editing the csv directly. 4/note also that for repository and repo location, I intend to use the actual first repository connected to the source, not an attribute stored. Lastly, It would be nice if from now on if you refrain from commenting on EE, and focus on the code and the good parts of having templates and citation styles :-). Benny |
From: Tim L. <guy...@gm...> - 2013-06-04 15:02:37
|
Benny Malengier wrote > Ok, about the code in the GEP 18, some things. > > 1/I intend to merge the given and surname author fields to a single author > in bibtex style. > That means, the code will assume different authors are joined with ' & ' > in > the attribute and in style: surname, given > I would use & to join authors to make it international instead of the > bibtex 'and'. > The GUI might still show surname and given fields though for simplicity to > the users, the storage would be in a single attribute though. > > 2/I will split in the csv the field column in two columns: field attribute > and field description. > > This will allow to merge many of the attributes now in the EE csv. Eg, all > different author forms, and all different title forms will be one, but > allow for a different description in the GUI when entering data. > > 3/in light of above, the EE styles will already be much clearer when seen > as attributes in Gramps. Reusing attributes will also allow to easily > change template, and not needing to retype fields. > Other styles are welcome though. If you make other styles, keep in mind > that editing the csv is dangerous if above changes are not yet > done/committed by me. > Adding the new styles you might want via the template editor later and > copying it over from the template editor to the code before release, might > also be easier than editing the csv directly. Sorry, can't resist commenting though I know it will be of little use. I have tried out the GEP-016 UI. I am not sure why editing the existing templates, or merging fields is necessary or desirable. If we want to claim EE, then we should use it. Anyway, if we have a template editor, then the built-in templates become less important. Surely it is just a matter of how the UI is arranged which should ensure that the EE styles and attributes can be clearly seen. Clearly, the existing arrangement where the Attribute editing pane brings up a huge list of possible attribute names, is not workable (in my system, the list only shows the top screenful of double column attributes and I can't seem to scroll to get anything else). However, I don't imagine that users would want to select the EE attributes directly. Hence, perhaps the Attribute editor should only display 'normal' and custom attributes directly (e.g. they could be attributes with numbers below 100). If the user wanted to select EE attributes, then a different dialogue could be presented - very inconvenient, but very rare. I haven't seen EE, so I don't know, but I imagine that some of the attributes that apparently are being considered for merge actually have different descriptions. I note that in the simple citations website (and in many other form filling applications) there is a feint description of what goes in the field that (usually) disappears when you click on that field to edit. Is that facility available for use by Gramps? I imagine that apparently duplicate fields might have different entries in such a prompt, and hence the reason to retain such duplicates. So, rather than trying to adapt the EE templates, and in line with your request to refrain from further comment on the templates, could I suggest carrying on with the UI - for example perhaps the citation editing or template editing and add-on. TL;DR at this stage, the UI rather than work on changing EE templates. Regards, Tim. -- View this message in context: http://gramps.1791082.n4.nabble.com/New-SrcAttribute-and-Evidence-Style-tp4660442p4660627.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |