Quantcast

New SrcAttribute and Evidence Style

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

New SrcAttribute and Evidence Style

Benny Malengier
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.

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Nick Hall-6
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
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Benny Malengier



2013/5/27 Nick Hall <[hidden email]>
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

John Ralls-2
In reply to this post by Nick Hall-6

On May 27, 2013, at 4:38 AM, Nick Hall <[hidden email]> 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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

enno
In reply to this post by Benny Malengier
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Nick Hall-6
In reply to this post by Benny Malengier
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Nick Hall-6
In reply to this post by enno
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Benny Malengier
In reply to this post by enno



2013/5/27 Enno Borgsteede <[hidden email]>
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Nick Hall-6
In reply to this post by John Ralls-2
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 <[hidden email]> 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
>
>
>
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

John Ralls-2
In reply to this post by enno

On May 27, 2013, at 8:33 AM, Enno Borgsteede <[hidden email]> 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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Benny Malengier
In reply to this post by John Ralls-2



2013/5/27 John Ralls <[hidden email]>

On May 27, 2013, at 4:38 AM, Nick Hall <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Benny Malengier
In reply to this post by Benny Malengier



2013/5/27 Benny Malengier <[hidden email]>
>
>
>
>
> 2013/5/27 Enno Borgsteede <[hidden email]>
>>
>> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

John Ralls-2
In reply to this post by Benny Malengier

On May 27, 2013, at 1:24 PM, Benny Malengier <[hidden email]> wrote:

>
>
>
> 2013/5/27 John Ralls <[hidden email]>
>
> On May 27, 2013, at 4:38 AM, Nick Hall <[hidden email]> 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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

John Ralls-2
In reply to this post by Benny Malengier

On May 27, 2013, at 1:38 PM, Benny Malengier <[hidden email]> wrote:

>
>
>
> 2013/5/27 Benny Malengier <[hidden email]>
> >
> >
> >
> >
> > 2013/5/27 Enno Borgsteede <[hidden email]>
> >>
> >> 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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

enno
In reply to this post by Benny Malengier
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

enno
In reply to this post by Nick Hall-6
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Nick Hall-6
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

John Ralls-2
In reply to this post by enno

On May 27, 2013, at 2:41 PM, Enno Borgsteede <[hidden email]> 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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

Benny Malengier
In reply to this post by John Ralls-2



2013/5/27 John Ralls <[hidden email]>


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




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: New SrcAttribute and Evidence Style

enno
In reply to this post by John Ralls-2
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
1234
Loading...