Quantcast

GEP 018

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

GEP 018

Benny Malengier
Another thread for the GEP 018 work, and including it in 4.1 or not.

I did only reviewed the initial part of Tim's changes after I stopped working on it myself. So I'm not current with the final work and if it's nearly "done".

As Nick changed the source/citation editor just a month ago, I would assume merging in the changes in the GEPS branch back into master would be a big work.

Also error prone. So if we want to take that into 4.1, somebody should start with merging trunk into the GEP branch, and fixing all merge errors. If it goes into trunk it will need sufficient testing time before we can release.

I do know that I fixed several GUI problems in that branch that I should have fixed in master too. But expecting a quick merge, I neglected to do that. Most annoying now. If nobody does a merge for 4.1, I might have to cherry pick some commits for 4.1.

Benny

------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Nick Hall-6
Benny,

I am against including GEP 018 in the v4.1 release.

The last time I ran it, the user interface was confusing and looked a
mess.  I'm not even convinced we have the design right yet.

The last commit was back in September.  I would have liked to follow the
development.

This needs more discussion.   There hasn't been a posting since August.

Nick.


On 05/04/14 21:23, Benny Malengier wrote:

> Another thread for the GEP 018 work, and including it in 4.1 or not.
>
> I did only reviewed the initial part of Tim's changes after I stopped
> working on it myself. So I'm not current with the final work and if
> it's nearly "done".
>
> As Nick changed the source/citation editor just a month ago, I would
> assume merging in the changes in the GEPS branch back into master
> would be a big work.
>
> Also error prone. So if we want to take that into 4.1, somebody should
> start with merging trunk into the GEP branch, and fixing all merge
> errors. If it goes into trunk it will need sufficient testing time
> before we can release.
>
> I do know that I fixed several GUI problems in that branch that I
> should have fixed in master too. But expecting a quick merge, I
> neglected to do that. Most annoying now. If nobody does a merge for
> 4.1, I might have to cherry pick some commits for 4.1.
>


------------------------------------------------------------------------------
_______________________________________________
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: GEP 018

Benny Malengier

2014-04-05 22:48 GMT+02:00 Nick Hall <[hidden email]>:
Benny,

I am against including GEP 018 in the v4.1 release.

I am also not for because I think the release you plan is too close.
I just stated what would be needed. If Tim would be able to do the push to get the branch back into shape,  I don't rule the possibility of it being included out either.

The last time I ran it, the user interface was confusing and looked a
mess.  I'm not even convinced we have the design right yet.

The last commit was back in September.  I would have liked to follow the
development.

This needs more discussion.   There hasn't been a posting since August.

It certainly needs discussion. The source styling is nice, but how to integrate it is the problematic thing. The discussion on what default styles to have also did not lead to a resolution. More a wait and see resolution it seemed to me. Wait and see what the developers present, and then post remarks.
The aid to users to create good sources is a plus also, but again, the GUI integration is a point of debate. With the source editor separate from citations, this could be more nicely done now I think.

Whatever is done, starting point is merging master into the branch. As Tim indicates database change collisions, it will not be easy to merge. It need also not be a 100% story. One could make sure the foundations are present in 4.1, without the user visible stuff. It depends on Tim though. He changed so much of my original push it's more his code than mine, so I feel he should do the merge. With the changes in master, it might be even be simpler to just start a new branch, and cherry pick the changes from the old branch as needed, rewriting the GUI parts from scratch.

Benny

 

Nick.


On 05/04/14 21:23, Benny Malengier wrote:
> Another thread for the GEP 018 work, and including it in 4.1 or not.
>
> I did only reviewed the initial part of Tim's changes after I stopped
> working on it myself. So I'm not current with the final work and if
> it's nearly "done".
>
> As Nick changed the source/citation editor just a month ago, I would
> assume merging in the changes in the GEPS branch back into master
> would be a big work.
>
> Also error prone. So if we want to take that into 4.1, somebody should
> start with merging trunk into the GEP branch, and fixing all merge
> errors. If it goes into trunk it will need sufficient testing time
> before we can release.
>
> I do know that I fixed several GUI problems in that branch that I
> should have fixed in master too. But expecting a quick merge, I
> neglected to do that. Most annoying now. If nobody does a merge for
> 4.1, I might have to cherry pick some commits for 4.1.
>


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Benny Malengier
As to the technical approach by Tim. Last I checked it the approach was now:

1. SrcTemplate is now a database table. So we can have the evidence styles of EE in an .gramps family tree, and if a user wants to use that, he can import it. Others can provide their own templates. A bit like Jerome has a communes.gramps with french place names

2. SrcTemplates are primary objects with listview/treeview. So user can set up the type there as he wants. If I'm not mistaken, creation of a family tree would prepopulate it with default templates

3. On creation of a source, the user indicates the Template it will follow. I have not checked out yet how Tim implemented this.

Benny


2014-04-06 1:02 GMT+02:00 Benny Malengier <[hidden email]>:

2014-04-05 22:48 GMT+02:00 Nick Hall <[hidden email]>:

Benny,

I am against including GEP 018 in the v4.1 release.

I am also not for because I think the release you plan is too close.
I just stated what would be needed. If Tim would be able to do the push to get the branch back into shape,  I don't rule the possibility of it being included out either.

The last time I ran it, the user interface was confusing and looked a
mess.  I'm not even convinced we have the design right yet.

The last commit was back in September.  I would have liked to follow the
development.

This needs more discussion.   There hasn't been a posting since August.

It certainly needs discussion. The source styling is nice, but how to integrate it is the problematic thing. The discussion on what default styles to have also did not lead to a resolution. More a wait and see resolution it seemed to me. Wait and see what the developers present, and then post remarks.
The aid to users to create good sources is a plus also, but again, the GUI integration is a point of debate. With the source editor separate from citations, this could be more nicely done now I think.

Whatever is done, starting point is merging master into the branch. As Tim indicates database change collisions, it will not be easy to merge. It need also not be a 100% story. One could make sure the foundations are present in 4.1, without the user visible stuff. It depends on Tim though. He changed so much of my original push it's more his code than mine, so I feel he should do the merge. With the changes in master, it might be even be simpler to just start a new branch, and cherry pick the changes from the old branch as needed, rewriting the GUI parts from scratch.

Benny

 

Nick.


On 05/04/14 21:23, Benny Malengier wrote:
> Another thread for the GEP 018 work, and including it in 4.1 or not.
>
> I did only reviewed the initial part of Tim's changes after I stopped
> working on it myself. So I'm not current with the final work and if
> it's nearly "done".
>
> As Nick changed the source/citation editor just a month ago, I would
> assume merging in the changes in the GEPS branch back into master
> would be a big work.
>
> Also error prone. So if we want to take that into 4.1, somebody should
> start with merging trunk into the GEP branch, and fixing all merge
> errors. If it goes into trunk it will need sufficient testing time
> before we can release.
>
> I do know that I fixed several GUI problems in that branch that I
> should have fixed in master too. But expecting a quick merge, I
> neglected to do that. Most annoying now. If nobody does a merge for
> 4.1, I might have to cherry pick some commits for 4.1.
>


------------------------------------------------------------------------------
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel



------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Nick Hall-6
Benny,

Have you considered a design consisting of a hierarchy of citations with inherited attributes?

Sources, citations and templates become a single entity using this approach.  It seems like a very neat design.

A citation could be just a single level for small sources, which would work better than our two level source-citation model.

Nick.


On 06/04/14 00:10, Benny Malengier wrote:
As to the technical approach by Tim. Last I checked it the approach was now:

1. SrcTemplate is now a database table. So we can have the evidence styles of EE in an .gramps family tree, and if a user wants to use that, he can import it. Others can provide their own templates. A bit like Jerome has a communes.gramps with french place names

2. SrcTemplates are primary objects with listview/treeview. So user can set up the type there as he wants. If I'm not mistaken, creation of a family tree would prepopulate it with default templates

3. On creation of a source, the user indicates the Template it will follow. I have not checked out yet how Tim implemented this.

Benny


2014-04-06 1:02 GMT+02:00 Benny Malengier <[hidden email]>:

2014-04-05 22:48 GMT+02:00 Nick Hall <[hidden email]>:

Benny,

I am against including GEP 018 in the v4.1 release.

I am also not for because I think the release you plan is too close.
I just stated what would be needed. If Tim would be able to do the push to get the branch back into shape,  I don't rule the possibility of it being included out either.

The last time I ran it, the user interface was confusing and looked a
mess.  I'm not even convinced we have the design right yet.

The last commit was back in September.  I would have liked to follow the
development.

This needs more discussion.   There hasn't been a posting since August.

It certainly needs discussion. The source styling is nice, but how to integrate it is the problematic thing. The discussion on what default styles to have also did not lead to a resolution. More a wait and see resolution it seemed to me. Wait and see what the developers present, and then post remarks.
The aid to users to create good sources is a plus also, but again, the GUI integration is a point of debate. With the source editor separate from citations, this could be more nicely done now I think.

Whatever is done, starting point is merging master into the branch. As Tim indicates database change collisions, it will not be easy to merge. It need also not be a 100% story. One could make sure the foundations are present in 4.1, without the user visible stuff. It depends on Tim though. He changed so much of my original push it's more his code than mine, so I feel he should do the merge. With the changes in master, it might be even be simpler to just start a new branch, and cherry pick the changes from the old branch as needed, rewriting the GUI parts from scratch.

Benny

 

Nick.


On 05/04/14 21:23, Benny Malengier wrote:
> Another thread for the GEP 018 work, and including it in 4.1 or not.
>
> I did only reviewed the initial part of Tim's changes after I stopped
> working on it myself. So I'm not current with the final work and if
> it's nearly "done".
>
> As Nick changed the source/citation editor just a month ago, I would
> assume merging in the changes in the GEPS branch back into master
> would be a big work.
>
> Also error prone. So if we want to take that into 4.1, somebody should
> start with merging trunk into the GEP branch, and fixing all merge
> errors. If it goes into trunk it will need sufficient testing time
> before we can release.
>
> I do know that I fixed several GUI problems in that branch that I
> should have fixed in master too. But expecting a quick merge, I
> neglected to do that. Most annoying now. If nobody does a merge for
> 4.1, I might have to cherry pick some commits for 4.1.
>


------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Benny Malengier

2014-04-06 1:27 GMT+02:00 Nick Hall <[hidden email]>:
Benny,

Have you considered a design consisting of a hierarchy of citations with inherited attributes?

Sources, citations and templates become a single entity using this approach.  It seems like a very neat design.

A citation could be just a single level for small sources, which would work better than our two level source-citation model.

Never considered that myself. I'm typically very strict datamodel following oriented. Which fits nice with Gramps of course, as every table seems to be an editor.
Doing what you say seems more a GUI thing for simplicity. Having different possible datamodels does not seem like a good idea though, so I would limit it to GUI simplifications based on settings..
Eg, we could have a checkbox: single citation source, and then create the citation on creation of the source, and make it non-editable. Or offer a default citation selector in the source, to allow creation of a citation when in the source editor. Both approaches require a small database change to store this, but could then in the GUI lead to simplification.

Although above can be nice additions, I don't really believe small sources are common, or would be a best practice approach. It's mostly people who want to enter relationships fast and not care about sources who would like the approach. I don't mind catering to that audience though.

Ok, reading your post again, real hierarchy of citations is of course also possible. There was a user some time ago who wrote his own program that had that. The same approach for places is possible. Complicated data structure though. And people using the software need to be very much aware of it, or they change a leaf somewhere without understanding the consequences on the inherited data. For places I tried on paper once what it would give, so with a place object having a handle to a parent place of which it inherits the data. Problem there was historical data. Things that in Poland today, but in Germany 100 years ago. Source-citation would not have problems with that.
Nevertheless, hierarchy for citations seems like much work for a limited amount of benefit. And the risk of users finding it far too complicated.

Benny


Nick.



On 06/04/14 00:10, Benny Malengier wrote:
As to the technical approach by Tim. Last I checked it the approach was now:

1. SrcTemplate is now a database table. So we can have the evidence styles of EE in an .gramps family tree, and if a user wants to use that, he can import it. Others can provide their own templates. A bit like Jerome has a communes.gramps with french place names

2. SrcTemplates are primary objects with listview/treeview. So user can set up the type there as he wants. If I'm not mistaken, creation of a family tree would prepopulate it with default templates

3. On creation of a source, the user indicates the Template it will follow. I have not checked out yet how Tim implemented this.

Benny


2014-04-06 1:02 GMT+02:00 Benny Malengier <[hidden email]>:

2014-04-05 22:48 GMT+02:00 Nick Hall <[hidden email]>:

Benny,

I am against including GEP 018 in the v4.1 release.

I am also not for because I think the release you plan is too close.
I just stated what would be needed. If Tim would be able to do the push to get the branch back into shape,  I don't rule the possibility of it being included out either.

The last time I ran it, the user interface was confusing and looked a
mess.  I'm not even convinced we have the design right yet.

The last commit was back in September.  I would have liked to follow the
development.

This needs more discussion.   There hasn't been a posting since August.

It certainly needs discussion. The source styling is nice, but how to integrate it is the problematic thing. The discussion on what default styles to have also did not lead to a resolution. More a wait and see resolution it seemed to me. Wait and see what the developers present, and then post remarks.
The aid to users to create good sources is a plus also, but again, the GUI integration is a point of debate. With the source editor separate from citations, this could be more nicely done now I think.

Whatever is done, starting point is merging master into the branch. As Tim indicates database change collisions, it will not be easy to merge. It need also not be a 100% story. One could make sure the foundations are present in 4.1, without the user visible stuff. It depends on Tim though. He changed so much of my original push it's more his code than mine, so I feel he should do the merge. With the changes in master, it might be even be simpler to just start a new branch, and cherry pick the changes from the old branch as needed, rewriting the GUI parts from scratch.

Benny

 

Nick.


On 05/04/14 21:23, Benny Malengier wrote:
> Another thread for the GEP 018 work, and including it in 4.1 or not.
>
> I did only reviewed the initial part of Tim's changes after I stopped
> working on it myself. So I'm not current with the final work and if
> it's nearly "done".
>
> As Nick changed the source/citation editor just a month ago, I would
> assume merging in the changes in the GEPS branch back into master
> would be a big work.
>
> Also error prone. So if we want to take that into 4.1, somebody should
> start with merging trunk into the GEP branch, and fixing all merge
> errors. If it goes into trunk it will need sufficient testing time
> before we can release.
>
> I do know that I fixed several GUI problems in that branch that I
> should have fixed in master too. But expecting a quick merge, I
> neglected to do that. Most annoying now. If nobody does a merge for
> 4.1, I might have to cherry pick some commits for 4.1.
>



------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Nick Hall-6
On 06/04/14 07:27, Benny Malengier wrote:
2014-04-06 1:27 GMT+02:00 Nick Hall <[hidden email]>:
Benny,

Have you considered a design consisting of a hierarchy of citations with inherited attributes?

Sources, citations and templates become a single entity using this approach.  It seems like a very neat design.

A citation could be just a single level for small sources, which would work better than our two level source-citation model.

Never considered that myself. I'm typically very strict datamodel following oriented. Which fits nice with Gramps of course, as every table seems to be an editor.
Doing what you say seems more a GUI thing for simplicity. Having different possible datamodels does not seem like a good idea though, so I would limit it to GUI simplifications based on settings..
Eg, we could have a checkbox: single citation source, and then create the citation on creation of the source, and make it non-editable. Or offer a default citation selector in the source, to allow creation of a citation when in the source editor. Both approaches require a small database change to store this, but could then in the GUI lead to simplification.

No, I haven't thought much about the GUI design yet.  This was a suggestion for the data model design.  Models such as GedcomX and STEMMA seem to be heading in this direction.



Although above can be nice additions, I don't really believe small sources are common, or would be a best practice approach. It's mostly people who want to enter relationships fast and not care about sources who would like the approach. I don't mind catering to that audience though.

Small sources are quite common.  It is not unusual for a document to consist of a single sheet of paper.  Birth, marriage and death certificates are a good example.



Ok, reading your post again, real hierarchy of citations is of course also possible. There was a user some time ago who wrote his own program that had that. The same approach for places is possible. Complicated data structure though.

The place structure in v4.1 is a hierarchy.  It is also a simple structure.


And people using the software need to be very much aware of it, or they change a leaf somewhere without understanding the consequences on the inherited data. For places I tried on paper once what it would give, so with a place object having a handle to a parent place of which it inherits the data. Problem there was historical data. Things that in Poland today, but in Germany 100 years ago. Source-citation would not have problems with that.

The new place structure allows multiple parents each with a date in the link.

 
Nevertheless, hierarchy for citations seems like much work for a limited amount of benefit. And the risk of users finding it far too complicated.

I think I code code a citation hierarchy quite quickly.

The complexity presented to the user depends on the user interface, not the model.


Nick.


------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Benny Malengier



2014-04-06 12:33 GMT+02:00 Nick Hall <[hidden email]>:
On 06/04/14 07:27, Benny Malengier wrote:
2014-04-06 1:27 GMT+02:00 Nick Hall <[hidden email]>:
Benny,

Have you considered a design consisting of a hierarchy of citations with inherited attributes?

Sources, citations and templates become a single entity using this approach.  It seems like a very neat design.

A citation could be just a single level for small sources, which would work better than our two level source-citation model.

Never considered that myself. I'm typically very strict datamodel following oriented. Which fits nice with Gramps of course, as every table seems to be an editor.
Doing what you say seems more a GUI thing for simplicity. Having different possible datamodels does not seem like a good idea though, so I would limit it to GUI simplifications based on settings..
Eg, we could have a checkbox: single citation source, and then create the citation on creation of the source, and make it non-editable. Or offer a default citation selector in the source, to allow creation of a citation when in the source editor. Both approaches require a small database change to store this, but could then in the GUI lead to simplification.

No, I haven't thought much about the GUI design yet.  This was a suggestion for the data model design.  Models such as GedcomX and STEMMA seem to be heading in this direction.




Although above can be nice additions, I don't really believe small sources are common, or would be a best practice approach. It's mostly people who want to enter relationships fast and not care about sources who would like the approach. I don't mind catering to that audience though.

Small sources are quite common.  It is not unusual for a document to consist of a single sheet of paper.  Birth, marriage and death certificates are a good example.

 But the point is if that is the source, or a section of the source. Do you make the book the source, and then citations into that, or the certificate as the source itself. Bot approaches are used. The way Gramps has evolved is away from the latter. This duality explicitly supported or not is the question. In my experience, even the small sources benefit from a couple of citations.

Ok, reading your post again, real hierarchy of citations is of course also possible. There was a user some time ago who wrote his own program that had that. The same approach for places is possible. Complicated data structure though.

The place structure in v4.1 is a hierarchy.  It is also a simple structure.

Ok, it shows I'm not current with 4.1 :-)
I have not ran it at all since the database changes. Do you have a more elaborate doc already than
https://www.gramps-project.org/wiki/index.php?title=Hierarchical_Place_Structure

One of the things for 4.1 you should do is decide when to lock the 4.0 manual , and ask Nick W to generate the 4.1 manual.

And people using the software need to be very much aware of it, or they change a leaf somewhere without understanding the consequences on the inherited data. For places I tried on paper once what it would give, so with a place object having a handle to a parent place of which it inherits the data. Problem there was historical data. Things that in Poland today, but in Germany 100 years ago. Source-citation would not have problems with that.

The new place structure allows multiple parents each with a date in the link.
Nevertheless, hierarchy for citations seems like much work for a limited amount of benefit. And the risk of users finding it far too complicated.

I think I code code a citation hierarchy quite quickly.

The complexity presented to the user depends on the user interface, not the model.

But to solve which problem? You want eg registry 1814-1832,
then a citation to year 1816
then a subcitation to page 321?

What problem does that solve?

benny


------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

enno
Benny,
 
Small sources are quite common.  It is not unusual for a document to consist of a single sheet of paper.  Birth, marriage and death certificates are a good example.

But the point is if that is the source, or a section of the source. Do you make the book the source, and then citations into that, or the certificate as the source itself. Bot approaches are used. The way Gramps has evolved is away from the latter. This duality explicitly supported or not is the question. In my experience, even the small sources benefit from a couple of citations.
It depends on how you look at it. I have long used PAF, which supports the source/citation model like we have it now, pure GEDCOM in a way. I like that, but when I work on-line, on FamilySearch, the source box used there is sort of one dimensional, meaning that it's just source, and nothing else.

https://familysearch.org/pal:/MM9.1.1/NB4R-M4V

In that, sources have a title, url, a formatted citation string, and a number of notes. And when I import those into Ancestral Quest or RootsMagic (using the FamilySearch API), and then export to GEDCOM, it appears that everything goes into the source, and the citation stays empty.

In a way, this applies to many sources people find on the web today. When I use a local archive site, I get a page like this

https://www.wiewaswie.nl/personen-zoeken/zoeken/document/a2apersonid/133591631/srcid/29859570/oid/34

and where FamilySearch only presents a film number somewhere on the page, this one gives you a lot more, like you can see below the dashed line. Some may still file this as a single source, while you may prefer to create a real Gramps citation yourself.
But to solve which problem? You want eg registry 1814-1832,
then a citation to year 1816
then a subcitation to page 321?
That's indeed what I would make of the above, and probably of the FamilySearch page too, but simply saving web pages can also be done without any hierarchy.

And the current status of GedcomX is that they support the one dimensional approach of FamilySearch, and a hierarchy

https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#23-the-sourcedescription-data-type

where sources can have a parent source, and a list of sources that they are derived from. That's even more complicated than the multiple place inheritance built by Nick.

By now, you may wonder what this has to do with GEP 018, and the sad thing is that GedcomX has no definition for citation elements at all. The source description must have a citation string, and that's it.

With this in mind, and a citation model that hasn't been touched in almost a year

https://github.com/FamilySearch/gedcomx-citation/blob/master/specifications/citation-model-specification.md

I have no idea what to do. :-(

regards,

Enno


------------------------------------------------------------------------------

_______________________________________________
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: GEP 018

Nick Hall-6
In reply to this post by Benny Malengier
On 06/04/14 13:11, Benny Malengier wrote:
> But to solve which problem? You want eg registry 1814-1832,
> then a citation to year 1816
> then a subcitation to page 321?
>
> What problem does that solve?

A three level citation may have some advantages, but I was more thinking
of one and two level citations.

At the moment we have a fixed two level source-citation structure. If
you want to cite a small source without the citation level you would
have to create an empty citation record.  The alternative would be to
invent a source to fit the two level structure.  For example, you could
create a source called "Marriage certificates" and then make each
certificate a citation.  This works but isn't very nice.  If a source
was just another citation record, it could be cited just like a citation.

Three level citations could be useful where an archive or museum has a
collection, but I see them more useful for templates.  Citations are
just a list of attributes, with notes and media.  A source is similar
except that it has links to repositories.   These links could also be
attributes.  I see a template as just another citation.

Consider a citation called "Book".  It has the following attributes:
"Title", "Author", "Publisher", "Page".  They are empty.

Next consider a citation called "Gramps User Manual".  It inherits the
attributes from "Book" and assigns values to "Title", "Author", "Publisher".

Finally consider a citation called "Page 123".  It inherits the
attributes from "Gramps User Manual" and assigns a value to "Page".

We certainly don't want to encourage the user to create deep
hierarchies.  In fact, I think we should prevent it in the user
interface.  We could even implement this data model and keep the
existing user interface.


Nick.


------------------------------------------------------------------------------
_______________________________________________
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: GEP 018

enno
In reply to this post by Benny Malengier
Devs,
> It certainly needs discussion. The source styling is nice, but how to
> integrate it is the problematic thing. The discussion on what default
> styles to have also did not lead to a resolution. More a wait and see
> resolution it seemed to me. Wait and see what the developers present,
> and then post remarks.
H'm, knowing this, wouldn't it be safe to conclude that EE style
templates are practically dead? They were implemented in a couple of
programs, where I assume some genealogists actually use them, but
outside the manufacturers, and those hidden users, I see absolutely
noone putting any effort in actually implementing them. What I mean is
that I see no support for templates on any major site on the web, no
action from FHISO, nothing substantial on GedcomX, and the one
commercial product that was supposed to create a template based
exchange, i.e. AncestorSync gone too. The company site still exists, but
the product domain only creates warning in Chrome and Firefox, and
SourceTemplates.org is gone too. In other words, there is no money to be
made, because noone is interested enough to pay, nor to contribute on
FHISO and GedcomX. Apparently, there's not much gain anywhere.

And IMO, the reason is simple, EE templates are based on the false
assumption that the process can be controlled top down, with a
bureaucracy so large, that noone listens to it anymore. John Yates last
updated his evidence style page 4 years ago, so what are we discussing
here? The Walking Dead?
> The aid to users to create good sources is a plus also, but again, the
> GUI integration is a point of debate. With the source editor separate
> from citations, this could be more nicely done now I think.
Creating good sources is nice, and I still wish for better support for
that in Gramps, but I really don't see how it can be done with an EE
based template set. It is too large, not compatible with local sites,
and close to impossible to translate and maintain. Do you really think
it makes sense to update templates whenever any local site, in any of
the countries where Gramps users live, adds another field, and if so,
who do you think will really bother distributing those? I won't.
> Whatever is done, starting point is merging master into the branch. As
> Tim indicates database change collisions, it will not be easy to
> merge. It need also not be a 100% story. One could make sure the
> foundations are present in 4.1, without the user visible stuff. It
> depends on Tim though. He changed so much of my original push it's
> more his code than mine, so I feel he should do the merge. With the
> changes in master, it might be even be simpler to just start a new
> branch, and cherry pick the changes from the old branch as needed,
> rewriting the GUI parts from scratch.
As far as I'm concerned, this makes no sense, unless the code adapts to
that little thing that may be visible in GedcomX right now, which is a
simple source architecture, multi level, like Nick wrote, with support
for the existing source/citation data that we have in Gramps and GEDCOM
now. Anything else looks like a waste of time to me, because
effectively, the whole template crap would just create another vendor
lock-in like the one described by Tamura Jones:

http://www.tamurajones.net/GenealogyCitationStandard.xhtml

The article is almost 5 years old, and still valid today.

In essence, I still think that it's not that difficult to identify and
cite a source with a reasonable number of elements/parameters, like it
is expressed by Tony Proctor here

http://www.familyhistorydata.parallaxview.co/home/document-structure/citation

or by GedcomX, whenever they wake up.

cheers,

Enno


------------------------------------------------------------------------------
_______________________________________________
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: GEP 018

Nick Hall-6
In reply to this post by Benny Malengier
On 06/04/14 13:11, Benny Malengier wrote:
> Ok, it shows I'm not current with 4.1 :-)
> I have not ran it at all since the database changes. Do you have a
> more elaborate doc already than
> https://www.gramps-project.org/wiki/index.php?title=Hierarchical_Place_Structure
>
> One of the things for 4.1 you should do is decide when to lock the 4.0
> manual , and ask Nick W to generate the 4.1 manual.
>

I don't have any user documentation at the moment.  I'll email Nick W
and ask him to generate the v4.1 manual.

The "Using database API" page also needs updating.  I can start on that now.

Until then the wiki page that you have already found is the best
documentation.

Nick.


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
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: GEP 018

Tim Lyons
Administrator
In reply to this post by Nick Hall-6
Nick Hall-6 wrote
Benny,

I am against including GEP 018 in the v4.1 release.

The last time I ran it, the user interface was confusing and looked a
mess.  I'm not even convinced we have the design right yet.

The last commit was back in September.  I would have liked to follow the
development.

This needs more discussion.   There hasn't been a posting since August.
Well, if you recall, I always thought that the evidence style templates were too complicated, and the user interface was too complicated.

I just wanted to make sure that the templates and the set of evidence style attributes were not build into the program, so the changes I made ensured that. (I also made sure that what we had done was compatible with CSL).

Hence, you will not hear any arguments from me in favour of including GEPS018 in Gramps v4.1.

However, I would strongly object to the evidence style attributes being included in trunk/4.1. Nick, if you are saying that this is the only difference between trunk as a result of Benny's merge of (parts of GEPS018) and GEPS018, then that needs to be removed. I will try to have a look, but cannot guarantee.

regards,
Tim.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEP 018

Tim Lyons
Administrator
In reply to this post by enno
enno wrote
In essence, I still think that it's not that difficult to identify and
cite a source with a reasonable number of elements/parameters, like it
is expressed by Tony Proctor here

http://www.familyhistorydata.parallaxview.co/home/document-structure/citation
That looks like an infinite number of elements/parameters, because he allows flexible parameter names as far as I can see. I though you mean a small finite number when you said "reasonable number".


(I don't need any smart people pointing out that infinity is a reasonable number!)

Regards,
Tim.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: GEP 018

Nick Hall-6
In reply to this post by Tim Lyons
On 07/04/14 16:13, Tim Lyons wrote:
> However, I would strongly object to the evidence style attributes being
> included in trunk/4.1. Nick, if you are saying that this is the only
> difference between trunk as a result of Benny's merge of (parts of GEPS018)
> and GEPS018, then that needs to be removed. I will try to have a look, but
> cannot guarantee.

Tim,

As far as I can see there is no part of GEPS018 in master at the moment.

The change Benny made was to introduce Source Attributes to replace
Data.  This allows the user to order attributes, which is a good feature.

I would also strongly object to evidence style attributes being included
in the v4.1 release.

It looks like there will be three database changes for v4.1:

1. Tagging of all primary objects
2. Hierarchical place structure
3. Source Attributes to replace Data

All of these have been in master for more than five months now.

Nick.


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
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: GEP 018

Paul Franklin-5
In reply to this post by Nick Hall-6
On 4/7/14, Nick Hall <[hidden email]> wrote:
> On 06/04/14 13:11, Benny Malengier wrote:
>> Ok, it shows I'm not current with 4.1 :-)
>> I have not ran it at all since the database changes. Do you have a
>> more elaborate doc already than
>> https://www.gramps-project.org/wiki/index.php?title=Hierarchical_Place_Structure
>>
>> One of the things for 4.1 you should do is decide when to lock the 4.0
>> manual , and ask Nick W to generate the 4.1 manual.

Another thing would be to fork off the gramps41
branch as soon as you feel comfortable doing it,
so that Jerome could alert all the translators to
start translating their file in gramps41/po -- as
many of them only do a translation at a "major"
gramps release.

That will mean more pain for developers of course,
with some bugs then needing fixing in four places
(34,40,41,and master).  And I certainly would /not/
do it until 4.0.4 is released, as John and Josip are
still actively testing -- and making -- their changes
to get 7258 fixed.

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
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: GEP 018

Nick Hall-6
In reply to this post by Tim Lyons
On 07/04/14 16:13, Tim Lyons wrote:
> I just wanted to make sure that the templates and the set of evidence style
> attributes were not build into the program, so the changes I made ensured
> that. (I also made sure that what we had done was compatible with CSL).

 From what you say, we just really need to get rid of the pre-defined
source attribute types.

Do you have any objections to keeping source attributes?

Nick.


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
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: GEP 018

enno
In reply to this post by Tim Lyons
Tim,
enno wrote
In essence, I still think that it's not that difficult to identify and 
cite a source with a reasonable number of elements/parameters, like it 
is expressed by Tony Proctor here

http://www.familyhistorydata.parallaxview.co/home/document-structure/citation
That looks like an infinite number of elements/parameters, because he allows
flexible parameter names as far as I can see. I though you mean a small
finite number when you said "reasonable number".
You're absolutely right about that. And the key to my comment is that somewhere on that page Tony wrote:
The Dublin Core Metadata Initiative has encountered the issue of a chain but has tried to solve it by adding additional terms and namespaces (see dc-citation-guidelines/). Basically, the simple Dublin Core terms cannot clearly distinguish, for instance, the title of an article from the title of a journal containing that article, or provide a clear indication of other data related to the containing journal such as publication date (as distinct from the article submission date), or the volume and issue numbers.
On reading that, and keeping in mind what Nick wrote about nested citations earlier, I concluded that what DC and EE can not, what they need different terms or namespaces for, can be done in a nested citation model. In that, you can re-use any term as long as it's in another level, and avoid the explosion of templates that occurs in EE, because one has to build templates for every permutation of terms that one may find in a single one level source reference.

With nested citations, we can use a title element at the collection level, church book level, and the record level, without needing namespaces or prefixes, and thus indeed work with a limited number of elements, like the ones that exist in GEDCOM now. Tony's choice to write that they are flexible is his, but the message that I got from the above is that the number can be much reduced compared to what you find in DC and EE now, and I personally think that I can cite almost everything with the existing GEDCOM elements, once nested citations are available.

Key is that the nesting avoids permutation effects. I left that out yesterday.

regards,

Enno


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
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: GEP 018

jerome
In reply to this post by enno
If FamilySearch starts to (re-)use Source 'sand' Boxes (alternate sources?), then this will be even more fun! :-/

https://getsatisfaction.com/familysearch/topics/migrating_nfs_sources_to_family_tree_has_started
https://getsatisfaction.com/familysearch/searches?query=source

Le dim. 6 avril 2014 at 22:49, Enno Borgsteede <[hidden email]> a écrit :
Devs,
It certainly needs discussion. The source styling is nice, but how to integrate it is the problematic thing. The discussion on what default styles to have also did not lead to a resolution. More a wait and see resolution it seemed to me. Wait and see what the developers present, and then post remarks.
H'm, knowing this, wouldn't it be safe to conclude that EE style templates are practically dead? They were implemented in a couple of programs, where I assume some genealogists actually use them, but outside the manufacturers, and those hidden users, I see absolutely noone putting any effort in actually implementing them. What I mean is that I see no support for templates on any major site on the web, no action from FHISO, nothing substantial on GedcomX, and the one commercial product that was supposed to create a template based exchange, i.e. AncestorSync gone too. The company site still exists, but the product domain only creates warning in Chrome and Firefox, and SourceTemplates.org is gone too. In other words, there is no money to be made, because noone is interested enough to pay, nor to contribute on FHISO and GedcomX. Apparently, there's not much gain anywhere. And IMO, the reason is simple, EE templates are based on the false assumption that the process can be controlled top down, with a bureaucracy so large, that noone listens to it anymore. John Yates last updated his evidence style page 4 years ago, so what are we discussing here? The Walking Dead?
The aid to users to create good sources is a plus also, but again, the GUI integration is a point of debate. With the source editor separate from citations, this could be more nicely done now I think.
Creating good sources is nice, and I still wish for better support for that in Gramps, but I really don't see how it can be done with an EE based template set. It is too large, not compatible with local sites, and close to impossible to translate and maintain. Do you really think it makes sense to update templates whenever any local site, in any of the countries where Gramps users live, adds another field, and if so, who do you think will really bother distributing those? I won't.
Whatever is done, starting point is merging master into the branch. As Tim indicates database change collisions, it will not be easy to merge. It need also not be a 100% story. One could make sure the foundations are present in 4.1, without the user visible stuff. It depends on Tim though. He changed so much of my original push it's more his code than mine, so I feel he should do the merge. With the changes in master, it might be even be simpler to just start a new branch, and cherry pick the changes from the old branch as needed, rewriting the GUI parts from scratch.
As far as I'm concerned, this makes no sense, unless the code adapts to that little thing that may be visible in GedcomX right now, which is a simple source architecture, multi level, like Nick wrote, with support for the existing source/citation data that we have in Gramps and GEDCOM now. Anything else looks like a waste of time to me, because effectively, the whole template crap would just create another vendor lock-in like the one described by Tamura Jones: http://www.tamurajones.net/GenealogyCitationStandard.xhtml The article is almost 5 years old, and still valid today. In essence, I still think that it's not that difficult to identify and cite a source with a reasonable number of elements/parameters, like it is expressed by Tony Proctor here http://www.familyhistorydata.parallaxview.co/home/document-structure/citation or by GedcomX, whenever they wake up. cheers, Enno ------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel

------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
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: GEP 018

Benny Malengier
In reply to this post by Nick Hall-6



2014-04-07 18:40 GMT+02:00 Nick Hall <[hidden email]>:
On 07/04/14 16:13, Tim Lyons wrote:
> I just wanted to make sure that the templates and the set of evidence style
> attributes were not build into the program, so the changes I made ensured
> that. (I also made sure that what we had done was compatible with CSL).

 From what you say, we just really need to get rid of the pre-defined
source attribute types.

Do you have any objections to keeping source attributes?

Source attributes are needed, it fixes an old standing inconsistency/bug in Gramps.

As to GEP 18. The core points still stand.
1. how to enter more data about the source? 
2. how to obtain a better presentation in reports?

We agreed to use the source attributes for 1. GEP 18 was an elaborate way to know what attributes. Most don't like the end result. I don't mind that.
Some sensible defaults should nevertheless be included with Gramps.
You now removed all them them, http://sourceforge.net/p/gramps/source/ci/2155ae381fd7074272cd0ebe45d00c6beea47a1d/
That is a good start. Which ones to include again?
I would suggest:

(GEN_BY    , _("Generated by"), "Generated by")

For use by the importers. This is more a translation thing, if we importer adds automatic source, best to use predefined attributes, instead of custom.

Then some fields like publisher, ... ? Really nothing at all? I would suggest the bibtex fields not present yet, http://en.wikipedia.org/wiki/BibTeX#Bibliographic_information_file, and nothing more.
When working multi-lang, it's nice not to need custom attributes, as those don't translate.
Also, we don't want to have to add default attribute types in 4.2 we could have added in 4.1, as that just gives upgrade problems for multilang. So I would suggest to prune the bibtex fields, and add what is left them as predefined defaults. A simple bibtex export of the sources can then be written if one would want that.

Next the presentation. Without GEP 18, the user has no override for the programmed behavior. GEP 18 is too complicated to achieve this. I agree to that. The fact no style exchange for genealogy is present yet, is proof of that. As the resource linked by Enno indicates, just some predefined textual overrides for referencing would suffice for many people. In other words, if we now add something

(FULL_FOOTNOTE, ("Full footnote text"), "Full footnote text"),
(SHORT_FOOTNOTE, ("Short footnote text"), "Short footnote text"),

we can have a simple solution. No bold, italics, ... though, and repeat needed on citation level of the value on the source level if user wants to use it. If user entered this, we can use it for referencing, otherwise we use the current method based on author/pub.info .... fields. Nothing fancy, only for users who want to have extra control over their references.
Simple addition of two source attribute types that give users an override for the footnotes in the reports. As indicated by the links given by Enno, most users would not care one way or the other. Some do though.

Benny


Nick.


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12
Loading...