Linking in Notes
Locked
 
|
Devs,
I have just completed a patch on issue #3914 [1] that adds the ability via markup to add links to notes. This adds two kinds of links: 1) links to web addresses 2) links to internal objects The first option is only somewhat interesting because one could always have entered a url in a note, and the notes editor would recognize it as a web address, and allow you to jump to it. But this new feature now allows you to hide the url behind arbitrary text. The second option is much more interesting as it allows you to have notes that have links to all of the primary objects in Gramps. For example, you can now add a link to people, places, events, media, etc. This allows you to have a narrative, with the links right in the text to the people and places. You can also add lists of people, which are links. My plan is to allow the ToDo Gramplet to be a note, which would allow you to have different lists of people that you maintain that allow you to quickly bring them up. This change required some changes in a few different places: docgen backends, NarWeb, html reports, and a couple of others. Some features: * links use a URI format in the style of gramps://object/handle/XXX and gramps://object/gramps_id/YYY where XXX and YYY are a handle, and a gramps ID, respectively. The idea is that these URI's could evolve to provide for links to other things in Gramps (such as reports, filtered lists, etc.) * Gramps uses the handle method. But you can manually enter a gramps:// link using the gramps_id lookup method. * In NarWeb, the links are turned into HTML page links. This works well for people, but may create links to not-included objects for other things. This will take some re-engineering of NarWeb to rectify. * Other text reports that produce HTML will be just underlined items, not links. * ODT produces links. All others currently just give underlines (or plain text). LaTeX and PDF could also be adapted to create links. * tooltips over links shows a nice description of object (eg, "Person: James Smith [I0123]"). * link creation will default to one of an open listview object. For example, if you have a person view open, the link will default to the selected person. * Right-click a link to either jump to it (brings up editor for objects), edit the link, or copy the link address. (Currently, the gramps:// link address is only useful for pasting into the URL of other links.) * The style-clear button will now only clear a selected region is there is a selected region, and if it has style tags in it. Otherwise, it clears the whole text of styles (as before). * The primary object selection dialogs can have default values. So, when you edit a link to a person and select a new one, it will default to the old person. Some other ideas to explore: * should an object referenced by a note via a link appear in the object's References? * could we link to other trees other than the current one, or to some kind of gramps server/database, such as gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? Should we plan for that? If no one has an objection, I'll apply this patch to trunk in the next couple of days. -Doug [1] - http://www.gramps-project.org/bugs/view.php?id=3914 ------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Linking in Notes
|
On Wed, May 5, 2010 at 8:23 PM, Doug Blank <[hidden email]> wrote:
> Devs, > > I have just completed a patch on issue #3914 [1] that adds the ability > via markup to add links to notes. This adds two kinds of links: > > 1) links to web addresses > 2) links to internal objects Very nice! > > The first option is only somewhat interesting because one could always > have entered a url in a note, and the notes editor would recognize it > as a web address, and allow you to jump to it. But this new feature > now allows you to hide the url behind arbitrary text. The second > option is much more interesting as it allows you to have notes that > have links to all of the primary objects in Gramps. > > For example, you can now add a link to people, places, events, media, > etc. This allows you to have a narrative, with the links right in the > text to the people and places. You can also add lists of people, which > are links. My plan is to allow the ToDo Gramplet to be a note, which > would allow you to have different lists of people that you maintain > that allow you to quickly bring them up. > > This change required some changes in a few different places: docgen > backends, NarWeb, html reports, and a couple of others. Some features: > > * links use a URI format in the style of gramps://object/handle/XXX > and gramps://object/gramps_id/YYY where XXX and YYY are a handle, and > a gramps ID, respectively. The idea is that these URI's could evolve > to provide for links to other things in Gramps (such as reports, > filtered lists, etc.) > * Gramps uses the handle method. But you can manually enter a > gramps:// link using the gramps_id lookup method. > * In NarWeb, the links are turned into HTML page links. This works > well for people, but may create links to not-included objects for > other things. This will take some re-engineering of NarWeb to rectify. > * Other text reports that produce HTML will be just underlined items, not links. > * ODT produces links. All others currently just give underlines (or > plain text). LaTeX and PDF could also be adapted to create links. > * tooltips over links shows a nice description of object (eg, "Person: > James Smith [I0123]"). > * link creation will default to one of an open listview object. For > example, if you have a person view open, the link will default to the > selected person. > * Right-click a link to either jump to it (brings up editor for > objects), edit the link, or copy the link address. (Currently, the > gramps:// link address is only useful for pasting into the URL of > other links.) > * The style-clear button will now only clear a selected region is > there is a selected region, and if it has style tags in it. Otherwise, > it clears the whole text of styles (as before). > * The primary object selection dialogs can have default values. So, > when you edit a link to a person and select a new one, it will default > to the old person. > > Some other ideas to explore: > > * should an object referenced by a note via a link appear in the > object's References? I would say "No." since it will mean changes to the rebuild reference map, check database integrity and the import functions and probably others as well. Also, what if a link is via gramps_id and the id is later changed? I would not want to see checks everywhere to look for notes linked by gramps ids. If we treat them like web URLs then if they break due to a change/removal in the location address, they break. > * could we link to other trees other than the current one, or to some > kind of gramps server/database, such as > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? Should > we plan for that? Linking to another tree is interesting for sure. However, to follow the link you'd have to open the other db (read only), get the data then close the db. We could keep a list of open dbs for that, I suppose. I wonder if linking to an external db (not on the same machine) could not be transparently handled with normal URLs. > > If no one has an objection, I'll apply this patch to trunk in the next > couple of days. > > -Doug > > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 > > ------------------------------------------------------------------------------ > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Gerald Britton ------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
On Wed, May 5, 2010 at 9:22 PM, Gerald Britton <[hidden email]> wrote:
> On Wed, May 5, 2010 at 8:23 PM, Doug Blank <[hidden email]> wrote: >> Devs, >> >> I have just completed a patch on issue #3914 [1] that adds the ability >> via markup to add links to notes. This adds two kinds of links: >> >> 1) links to web addresses >> 2) links to internal objects > > Very nice! > >> >> The first option is only somewhat interesting because one could always >> have entered a url in a note, and the notes editor would recognize it >> as a web address, and allow you to jump to it. But this new feature >> now allows you to hide the url behind arbitrary text. The second >> option is much more interesting as it allows you to have notes that >> have links to all of the primary objects in Gramps. >> >> For example, you can now add a link to people, places, events, media, >> etc. This allows you to have a narrative, with the links right in the >> text to the people and places. You can also add lists of people, which >> are links. My plan is to allow the ToDo Gramplet to be a note, which >> would allow you to have different lists of people that you maintain >> that allow you to quickly bring them up. >> >> This change required some changes in a few different places: docgen >> backends, NarWeb, html reports, and a couple of others. Some features: >> >> * links use a URI format in the style of gramps://object/handle/XXX >> and gramps://object/gramps_id/YYY where XXX and YYY are a handle, and >> a gramps ID, respectively. The idea is that these URI's could evolve >> to provide for links to other things in Gramps (such as reports, >> filtered lists, etc.) >> * Gramps uses the handle method. But you can manually enter a >> gramps:// link using the gramps_id lookup method. >> * In NarWeb, the links are turned into HTML page links. This works >> well for people, but may create links to not-included objects for >> other things. This will take some re-engineering of NarWeb to rectify. >> * Other text reports that produce HTML will be just underlined items, not links. >> * ODT produces links. All others currently just give underlines (or >> plain text). LaTeX and PDF could also be adapted to create links. >> * tooltips over links shows a nice description of object (eg, "Person: >> James Smith [I0123]"). >> * link creation will default to one of an open listview object. For >> example, if you have a person view open, the link will default to the >> selected person. >> * Right-click a link to either jump to it (brings up editor for >> objects), edit the link, or copy the link address. (Currently, the >> gramps:// link address is only useful for pasting into the URL of >> other links.) >> * The style-clear button will now only clear a selected region is >> there is a selected region, and if it has style tags in it. Otherwise, >> it clears the whole text of styles (as before). >> * The primary object selection dialogs can have default values. So, >> when you edit a link to a person and select a new one, it will default >> to the old person. >> >> Some other ideas to explore: >> >> * should an object referenced by a note via a link appear in the >> object's References? > > I would say "No." since it will mean changes to the rebuild reference > map, check database integrity and the import functions and probably > others as well. Also, what if a link is via gramps_id and the id is > later changed? I would not want to see checks everywhere to look for > notes linked by gramps ids. If we treat them like web URLs then if > they break due to a change/removal in the location address, they > break. Thanks! I think I agree. Although, we could have a report that could produce a list of notes that references an object. That is probably the way to handle such an expensive operation. Although, it isn't that bad, I suspect... you only need look through the styledtext tags... might even have an index to do that. But until people really beg for link references, I think I would agree to leave it as is for now. > >> * could we link to other trees other than the current one, or to some >> kind of gramps server/database, such as >> gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? Should >> we plan for that? > > Linking to another tree is interesting for sure. However, to follow > the link you'd have to open the other db (read only), get the data > then close the db. We could keep a list of open dbs for that, I > suppose. I wonder if linking to an external db (not on the same > machine) could not be transparently handled with normal URLs. I just want to make sure that if we thought we maybe someday want some extension, that we didn't prevent it from happening. Does it seem warranted to insert "localhost" (or "localdb" or "self") into every link? I think that we can use normal HTTP for machine-to-machine future transfers, and leave "gramps://" to be a reference mechanism to the current computer. If we did want to refer to another DB in the future, what method would we want to use? Or should we just invent a new mechanism when we need it? -Doug >> >> If no one has an objection, I'll apply this patch to trunk in the next >> couple of days. >> >> -Doug >> >> [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Gramps-devel mailing list >> [hidden email] >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > > > > -- > Gerald Britton > ------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Linking in Notes
|
In reply to this post by DS Blank
Any thought given to using a wiki-like link? Such as [[I0123]] instead of a full URL-style link gramps://object/gramps_id/I0123 ?
"My [[I0123|grandfather]] left for war..." "My <a href="gramps://object/gramps_id/I0123">grandfather</a> left for war..." Personally, I'd go for the simpler wiki style of linking. Stéphane On Wed, May 5, 2010 at 11:23, Doug Blank <[hidden email]> wrote: Devs, ------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
2010/5/6 Stéphane Charette <[hidden email]>:
> Any thought given to using a wiki-like link? Such as [[I0123]] instead of a > full URL-style link gramps://object/gramps_id/I0123 ? > > "My [[I0123|grandfather]] left for war..." > "My <a href="gramps://object/gramps_id/I0123">grandfather</a> left for > war..." > > Personally, I'd go for the simpler wiki style of linking. Stéphane, Yes, that was suggested. However, these aren't things that humans type, and aren't necessarily even things that they see. This is really just an internal format for a link to a gramps object. Wiki-style is useful because many wikis only have one entry mode: text. In Gramps notes, we have styled markup, so what I added was a new style of markup for making internal links. However, what you suggest is a possible new formatting mode that would be text-based but would then be rendered. In fact, many wikis allow both of the above (html and the special [] formats). So I think that your suggestion is independent of the current patch. People might like being able to type formatting, like '''bold''', ''italic'', and [[I023]], rather than making the clicky-finger hurt. It might be a question of whether we want to support yet another note style. -Doug > Stéphane > > > On Wed, May 5, 2010 at 11:23, Doug Blank <[hidden email]> wrote: >> >> Devs, >> >> I have just completed a patch on issue #3914 [1] that adds the ability >> via markup to add links to notes. This adds two kinds of links: >> >> 1) links to web addresses >> 2) links to internal objects >> >> The first option is only somewhat interesting because one could always >> have entered a url in a note, and the notes editor would recognize it >> as a web address, and allow you to jump to it. But this new feature >> now allows you to hide the url behind arbitrary text. The second >> option is much more interesting as it allows you to have notes that >> have links to all of the primary objects in Gramps. >> >> For example, you can now add a link to people, places, events, media, >> etc. This allows you to have a narrative, with the links right in the >> text to the people and places. You can also add lists of people, which >> are links. My plan is to allow the ToDo Gramplet to be a note, which >> would allow you to have different lists of people that you maintain >> that allow you to quickly bring them up. >> >> This change required some changes in a few different places: docgen >> backends, NarWeb, html reports, and a couple of others. Some features: >> >> * links use a URI format in the style of gramps://object/handle/XXX >> and gramps://object/gramps_id/YYY where XXX and YYY are a handle, and >> a gramps ID, respectively. The idea is that these URI's could evolve >> to provide for links to other things in Gramps (such as reports, >> filtered lists, etc.) >> * Gramps uses the handle method. But you can manually enter a >> gramps:// link using the gramps_id lookup method. >> * In NarWeb, the links are turned into HTML page links. This works >> well for people, but may create links to not-included objects for >> other things. This will take some re-engineering of NarWeb to rectify. >> * Other text reports that produce HTML will be just underlined items, not >> links. >> * ODT produces links. All others currently just give underlines (or >> plain text). LaTeX and PDF could also be adapted to create links. >> * tooltips over links shows a nice description of object (eg, "Person: >> James Smith [I0123]"). >> * link creation will default to one of an open listview object. For >> example, if you have a person view open, the link will default to the >> selected person. >> * Right-click a link to either jump to it (brings up editor for >> objects), edit the link, or copy the link address. (Currently, the >> gramps:// link address is only useful for pasting into the URL of >> other links.) >> * The style-clear button will now only clear a selected region is >> there is a selected region, and if it has style tags in it. Otherwise, >> it clears the whole text of styles (as before). >> * The primary object selection dialogs can have default values. So, >> when you edit a link to a person and select a new one, it will default >> to the old person. >> >> Some other ideas to explore: >> >> * should an object referenced by a note via a link appear in the >> object's References? >> * could we link to other trees other than the current one, or to some >> kind of gramps server/database, such as >> gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? Should >> we plan for that? >> >> If no one has an objection, I'll apply this patch to trunk in the next >> couple of days. >> >> -Doug >> >> [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> 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 |
Re: Linking in Notes
|
In reply to this post by Gerald Britton-2
2010/5/6 Gerald Britton <[hidden email]>
Let's stick to the unix way of things with trying to do one thing really well. For links between family trees, we should use the UID/GUID/_UID method as we investigate for merge: http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge So something like gramps://object/UID/XXX But then UID must be resolved and linked. We still have to work out how to store this in Gramps (a special attribute). The logical way would be that clicking on UID brings you to a page with link to other places where that UID is registered. So the setup would be 1. you have a family tree 2. you generate UID for your objects because you want linking over trees with nice merge 3. you submit your list of UID to a "central service". This service allows to indicate two different UID refer to the same person, and keeps a 'link' to the place the object is stored 4. when generating a website, clicking a UID link goes to a page as generated by the central service, which allows click through to other databases. 5. Gramps itself can query the central service and update it's internal list of UID if user wants that 6. The central service is not really central, so different of these services can interact to update their own master list. Clearly, above is a bit futuristic, and involves some API which is eg also acceptable to the other genealogy software out there (certainly the open source). With Django you might have something quickly perhaps :-) Benny
------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
On Fri, May 7, 2010 at 3:29 AM, Benny Malengier
<[hidden email]> wrote: > > > 2010/5/6 Gerald Britton <[hidden email]> >> >> > * could we link to other trees other than the current one, or to some >> > kind of gramps server/database, such as >> > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? Should >> > we plan for that? >> >> Linking to another tree is interesting for sure. However, to follow >> the link you'd have to open the other db (read only), get the data >> then close the db. We could keep a list of open dbs for that, I >> suppose. I wonder if linking to an external db (not on the same >> machine) could not be transparently handled with normal URLs. >> > > Let's stick to the unix way of things with trying to do one thing really > well. > For links between family trees, we should use the UID/GUID/_UID method as we > investigate for merge: > http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge > > So something like > gramps://object/UID/XXX > > But then UID must be resolved and linked. We still have to work out how to > store this in Gramps (a special attribute). The logical way would be that > clicking on UID brings you to a page with link to other places where that > UID is registered. So the setup would be > 1. you have a family tree > 2. you generate UID for your objects because you want linking over trees > with nice merge > 3. you submit your list of UID to a "central service". This service allows > to indicate two different UID refer to the same person, and keeps a 'link' > to the place the object is stored > 4. when generating a website, clicking a UID link goes to a page as > generated by the central service, which allows click through to other > databases. > 5. Gramps itself can query the central service and update it's internal list > of UID if user wants that > 6. The central service is not really central, so different of these services > can interact to update their own master list. > > Clearly, above is a bit futuristic, and involves some API which is eg also > acceptable to the other genealogy software out there (certainly the open > source). With Django you might have something quickly perhaps :-) I like bringing the idea of the UID into the discussion, and I'd like to move towards such integration. Perhaps we can head in that direction by moving the linking code to a central library that will do what it currently does, and then add the abilities to "resolve" UID's into handles (ie, the UID used locally) in the future. I think for NarWeb, we'll need to at least have as an option to make it a completely static process, as many people use it as a "viewer" for their trees, even when off-line. The details of linking may change in trunk as we evolve this idea. But I will try to make it possible for those testers to migrate their links as the spec changes. Adding links to notes is time-consuming, but I'm finding really useful. It turns notes into an interface to all gramps objects. Cool! Warning: if you add links in trunk, and then edit the notes in gramps32, the links will be silently removed. -Doug > Benny > >> > >> > If no one has an objection, I'll apply this patch to trunk in the next >> > couple of days. >> > >> > -Doug >> > >> > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> > >> > >> > ------------------------------------------------------------------------------ >> > _______________________________________________ >> > Gramps-devel mailing list >> > [hidden email] >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > >> >> >> >> -- >> Gerald Britton >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> 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 |
Re: Linking in Notes
|
|
2010/5/7 Doug Blank <[hidden email]>
Ok, I further agree with Gerald: the notes are text, and linking does not mean back references are added . Links to http:'// or gramps:// can become stale. What would be usefull and perhaps even required before release of this: 1/a note quickview (or extra tab?) listing all links used in a note 2/a report/filter showing which notes contain broken links to gramps:// Benny
------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
On Fri, May 7, 2010 at 7:50 AM, Benny Malengier
<[hidden email]> wrote: > > > 2010/5/7 Doug Blank <[hidden email]> >> >> On Fri, May 7, 2010 at 3:29 AM, Benny Malengier >> <[hidden email]> wrote: >> > >> > >> > 2010/5/6 Gerald Britton <[hidden email]> >> >> >> >> > * could we link to other trees other than the current one, or to some >> >> > kind of gramps server/database, such as >> >> > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? Should >> >> > we plan for that? >> >> >> >> Linking to another tree is interesting for sure. However, to follow >> >> the link you'd have to open the other db (read only), get the data >> >> then close the db. We could keep a list of open dbs for that, I >> >> suppose. I wonder if linking to an external db (not on the same >> >> machine) could not be transparently handled with normal URLs. >> >> >> > >> > Let's stick to the unix way of things with trying to do one thing really >> > well. >> > For links between family trees, we should use the UID/GUID/_UID method >> > as we >> > investigate for merge: >> > >> > http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge >> > >> > So something like >> > gramps://object/UID/XXX >> > >> > But then UID must be resolved and linked. We still have to work out how >> > to >> > store this in Gramps (a special attribute). The logical way would be >> > that >> > clicking on UID brings you to a page with link to other places where >> > that >> > UID is registered. So the setup would be >> > 1. you have a family tree >> > 2. you generate UID for your objects because you want linking over trees >> > with nice merge >> > 3. you submit your list of UID to a "central service". This service >> > allows >> > to indicate two different UID refer to the same person, and keeps a >> > 'link' >> > to the place the object is stored >> > 4. when generating a website, clicking a UID link goes to a page as >> > generated by the central service, which allows click through to other >> > databases. >> > 5. Gramps itself can query the central service and update it's internal >> > list >> > of UID if user wants that >> > 6. The central service is not really central, so different of these >> > services >> > can interact to update their own master list. >> > >> > Clearly, above is a bit futuristic, and involves some API which is eg >> > also >> > acceptable to the other genealogy software out there (certainly the open >> > source). With Django you might have something quickly perhaps :-) >> >> I like bringing the idea of the UID into the discussion, and I'd like >> to move towards such integration. Perhaps we can head in that >> direction by moving the linking code to a central library that will do >> what it currently does, and then add the abilities to "resolve" UID's >> into handles (ie, the UID used locally) in the future. >> >> I think for NarWeb, we'll need to at least have as an option to make >> it a completely static process, as many people use it as a "viewer" >> for their trees, even when off-line. >> >> The details of linking may change in trunk as we evolve this idea. But >> I will try to make it possible for those testers to migrate their >> links as the spec changes. Adding links to notes is time-consuming, >> but I'm finding really useful. It turns notes into an interface to all >> gramps objects. Cool! >> >> Warning: if you add links in trunk, and then edit the notes in >> gramps32, the links will be silently removed. > > Ok, I further agree with Gerald: the notes are text, and linking does not > mean back references are added . Links to http:'// or gramps:// can become > stale. > What would be usefull and perhaps even required before release of this: > 1/a note quickview (or extra tab?) listing all links used in a note > 2/a report/filter showing which notes contain broken links to gramps:// I've added a "Link References" quickview that simply lists the links that are in a note with these columns: type (Gramps or Internet), a description of the gramps object or URL, and a link check (if gramps object). Double-clicking a row will bring up the gramps object. Bad links show the gramps URI and a failed check message. This immediately suggests two additional things: 1) a way to list all links across all notes (and their valid status) 2) a way to easily find and correct bad links (links know their location in the text) However, we still need a back-link-reference list so that one can easily find all of notes that mention a particular object. Doesn't the back-reference infrastructure already do this? What are the pros of replicating this, rather than just using it for link back-references? -Doug > Benny >> >> -Doug >> >> > Benny >> > >> >> > >> >> > If no one has an objection, I'll apply this patch to trunk in the >> >> > next >> >> > couple of days. >> >> > >> >> > -Doug >> >> > >> >> > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> >> > >> >> > >> >> > >> >> > ------------------------------------------------------------------------------ >> >> > _______________________________________________ >> >> > Gramps-devel mailing list >> >> > [hidden email] >> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> > >> >> >> >> >> >> >> >> -- >> >> Gerald Britton >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> >> 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 |
Re: Linking in Notes
|
|
2010/5/7 Doug Blank <[hidden email]> On Fri, May 7, 2010 at 7:50 AM, Benny Malengier To add back reference list would require needs careful planning. I would really leave the link as part of the note text, not as a formal link between database tables. Now, a person can have a note. If officially a note can 'have' a person, then the backreference of the person would show the note. Technically possible, we just have to be sure the large amount of work to do it is worth it. The question you ask can also be solved with a report/tool, without the database infrastructure. We only need the speed of storing it in the database table if 1/the question is be asked often 2/avoiding stale links. However, the use case is not working 100%. If you have note referring to a person, and you delete the person, one can remove the gramps:// link automatically, but one can not change the text. So it is very different from the other types of backreference we have. Moreover, a user might be interested in leaving the stale link, as it means he did something wrong ... Benny
------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
On Fri, May 7, 2010 at 9:37 AM, Benny Malengier
<[hidden email]> wrote: > > > 2010/5/7 Doug Blank <[hidden email]> >> >> On Fri, May 7, 2010 at 7:50 AM, Benny Malengier >> <[hidden email]> wrote: >> > >> > >> > 2010/5/7 Doug Blank <[hidden email]> >> >> >> >> On Fri, May 7, 2010 at 3:29 AM, Benny Malengier >> >> <[hidden email]> wrote: >> >> > >> >> > >> >> > 2010/5/6 Gerald Britton <[hidden email]> >> >> >> >> >> >> > * could we link to other trees other than the current one, or to >> >> >> > some >> >> >> > kind of gramps server/database, such as >> >> >> > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? >> >> >> > Should >> >> >> > we plan for that? >> >> >> >> >> >> Linking to another tree is interesting for sure. However, to follow >> >> >> the link you'd have to open the other db (read only), get the data >> >> >> then close the db. We could keep a list of open dbs for that, I >> >> >> suppose. I wonder if linking to an external db (not on the same >> >> >> machine) could not be transparently handled with normal URLs. >> >> >> >> >> > >> >> > Let's stick to the unix way of things with trying to do one thing >> >> > really >> >> > well. >> >> > For links between family trees, we should use the UID/GUID/_UID >> >> > method >> >> > as we >> >> > investigate for merge: >> >> > >> >> > >> >> > http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge >> >> > >> >> > So something like >> >> > gramps://object/UID/XXX >> >> > >> >> > But then UID must be resolved and linked. We still have to work out >> >> > how >> >> > to >> >> > store this in Gramps (a special attribute). The logical way would be >> >> > that >> >> > clicking on UID brings you to a page with link to other places where >> >> > that >> >> > UID is registered. So the setup would be >> >> > 1. you have a family tree >> >> > 2. you generate UID for your objects because you want linking over >> >> > trees >> >> > with nice merge >> >> > 3. you submit your list of UID to a "central service". This service >> >> > allows >> >> > to indicate two different UID refer to the same person, and keeps a >> >> > 'link' >> >> > to the place the object is stored >> >> > 4. when generating a website, clicking a UID link goes to a page as >> >> > generated by the central service, which allows click through to other >> >> > databases. >> >> > 5. Gramps itself can query the central service and update it's >> >> > internal >> >> > list >> >> > of UID if user wants that >> >> > 6. The central service is not really central, so different of these >> >> > services >> >> > can interact to update their own master list. >> >> > >> >> > Clearly, above is a bit futuristic, and involves some API which is eg >> >> > also >> >> > acceptable to the other genealogy software out there (certainly the >> >> > open >> >> > source). With Django you might have something quickly perhaps :-) >> >> >> >> I like bringing the idea of the UID into the discussion, and I'd like >> >> to move towards such integration. Perhaps we can head in that >> >> direction by moving the linking code to a central library that will do >> >> what it currently does, and then add the abilities to "resolve" UID's >> >> into handles (ie, the UID used locally) in the future. >> >> >> >> I think for NarWeb, we'll need to at least have as an option to make >> >> it a completely static process, as many people use it as a "viewer" >> >> for their trees, even when off-line. >> >> >> >> The details of linking may change in trunk as we evolve this idea. But >> >> I will try to make it possible for those testers to migrate their >> >> links as the spec changes. Adding links to notes is time-consuming, >> >> but I'm finding really useful. It turns notes into an interface to all >> >> gramps objects. Cool! >> >> >> >> Warning: if you add links in trunk, and then edit the notes in >> >> gramps32, the links will be silently removed. >> > >> > Ok, I further agree with Gerald: the notes are text, and linking does >> > not >> > mean back references are added . Links to http:'// or gramps:// can >> > become >> > stale. >> > What would be usefull and perhaps even required before release of this: >> > 1/a note quickview (or extra tab?) listing all links used in a note >> > 2/a report/filter showing which notes contain broken links to gramps:// >> >> I've added a "Link References" quickview that simply lists the links >> that are in a note with these columns: type (Gramps or Internet), a >> description of the gramps object or URL, and a link check (if gramps >> object). Double-clicking a row will bring up the gramps object. Bad >> links show the gramps URI and a failed check message. >> >> This immediately suggests two additional things: >> >> 1) a way to list all links across all notes (and their valid status) >> 2) a way to easily find and correct bad links (links know their >> location in the text) >> >> However, we still need a back-link-reference list so that one can >> easily find all of notes that mention a particular object. Doesn't the >> back-reference infrastructure already do this? What are the pros of >> replicating this, rather than just using it for link back-references? > > To add back reference list would require needs careful planning. > I would really leave the link as part of the note text, not as a formal link > between database tables. > > Now, a person can have a note. If officially a note can 'have' a person, > then the backreference of the person would show the note. > > Technically possible, we just have to be sure the large amount of work to do > it is worth it. As I don't know the back-ref system, I don't know how much work it would take. I just thought that when you add a link to an object, you would add a backref link to the note. If you clear a link, it would remove it from the object. Isn't that it? > The question you ask can also be solved with a report/tool, without the > database infrastructure. We only need the speed of storing it in the > database table if > 1/the question is be asked often > 2/avoiding stale links. Whatever the UI mechanism, it should be as handy as the References tab, as you would surely want to click it to go there. > However, the use case is not working 100%. If you have note referring to a > person, and you delete the person, one can remove the gramps:// link > automatically, but one can not change the text. So it is very different from > the other types of backreference we have. Moreover, a user might be > interested in leaving the stale link, as it means he did something wrong ... One idea that might solve some of this is: If you attempt to link to an object from a note, you check to see if that object shares this note. If it doesn't, you ask the user if they would like to share it. That way, the sharing could take the place of the backref. There could be a setting in preferences: ( ) Always share a note with an object that you link to ( ) Never share a note with an object that you link to ( ) Ask me each time I create a link to share note with object or not It could be argued that if you are mentioning an object from a note, it should share that note. -Doug > Benny >> >> >> -Doug >> >> > Benny >> >> >> >> -Doug >> >> >> >> > Benny >> >> > >> >> >> > >> >> >> > If no one has an objection, I'll apply this patch to trunk in the >> >> >> > next >> >> >> > couple of days. >> >> >> > >> >> >> > -Doug >> >> >> > >> >> >> > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > ------------------------------------------------------------------------------ >> >> >> > _______________________________________________ >> >> >> > Gramps-devel mailing list >> >> >> > [hidden email] >> >> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Gerald Britton >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> >> >> 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 |
Re: Linking in Notes
|
|
2010/5/7 Doug Blank <[hidden email]> On Fri, May 7, 2010 at 9:37 AM, Benny Malengier Yes and no. I agree the note might want to be shared, but if you as a user don't want it for this note, and do want for another, this way of setting things in the preferences would be annoying. It does not really fix anything however, as you would still just delete a person/place/..., even if this note is attached. Well, we understand all this because we really understand how Gramps works. For normal users this does not look like a good workflow, that is, many technical things a user is not interested in. We should make it 'just work', not require the users to decide things like this. Benny
------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
On Sun, May 9, 2010 at 1:40 PM, Benny Malengier
<[hidden email]> wrote: > > > 2010/5/7 Doug Blank <[hidden email]> >> >> On Fri, May 7, 2010 at 9:37 AM, Benny Malengier >> <[hidden email]> wrote: >> > >> > >> > 2010/5/7 Doug Blank <[hidden email]> >> >> >> >> On Fri, May 7, 2010 at 7:50 AM, Benny Malengier >> >> <[hidden email]> wrote: >> >> > >> >> > >> >> > 2010/5/7 Doug Blank <[hidden email]> >> >> >> >> >> >> On Fri, May 7, 2010 at 3:29 AM, Benny Malengier >> >> >> <[hidden email]> wrote: >> >> >> > >> >> >> > >> >> >> > 2010/5/6 Gerald Britton <[hidden email]> >> >> >> >> >> >> >> >> > * could we link to other trees other than the current one, or >> >> >> >> > to >> >> >> >> > some >> >> >> >> > kind of gramps server/database, such as >> >> >> >> > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? >> >> >> >> > Should >> >> >> >> > we plan for that? >> >> >> >> >> >> >> >> Linking to another tree is interesting for sure. However, to >> >> >> >> follow >> >> >> >> the link you'd have to open the other db (read only), get the >> >> >> >> data >> >> >> >> then close the db. We could keep a list of open dbs for that, I >> >> >> >> suppose. I wonder if linking to an external db (not on the same >> >> >> >> machine) could not be transparently handled with normal URLs. >> >> >> >> >> >> >> > >> >> >> > Let's stick to the unix way of things with trying to do one thing >> >> >> > really >> >> >> > well. >> >> >> > For links between family trees, we should use the UID/GUID/_UID >> >> >> > method >> >> >> > as we >> >> >> > investigate for merge: >> >> >> > >> >> >> > >> >> >> > >> >> >> > http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge >> >> >> > >> >> >> > So something like >> >> >> > gramps://object/UID/XXX >> >> >> > >> >> >> > But then UID must be resolved and linked. We still have to work >> >> >> > out >> >> >> > how >> >> >> > to >> >> >> > store this in Gramps (a special attribute). The logical way would >> >> >> > be >> >> >> > that >> >> >> > clicking on UID brings you to a page with link to other places >> >> >> > where >> >> >> > that >> >> >> > UID is registered. So the setup would be >> >> >> > 1. you have a family tree >> >> >> > 2. you generate UID for your objects because you want linking over >> >> >> > trees >> >> >> > with nice merge >> >> >> > 3. you submit your list of UID to a "central service". This >> >> >> > service >> >> >> > allows >> >> >> > to indicate two different UID refer to the same person, and keeps >> >> >> > a >> >> >> > 'link' >> >> >> > to the place the object is stored >> >> >> > 4. when generating a website, clicking a UID link goes to a page >> >> >> > as >> >> >> > generated by the central service, which allows click through to >> >> >> > other >> >> >> > databases. >> >> >> > 5. Gramps itself can query the central service and update it's >> >> >> > internal >> >> >> > list >> >> >> > of UID if user wants that >> >> >> > 6. The central service is not really central, so different of >> >> >> > these >> >> >> > services >> >> >> > can interact to update their own master list. >> >> >> > >> >> >> > Clearly, above is a bit futuristic, and involves some API which is >> >> >> > eg >> >> >> > also >> >> >> > acceptable to the other genealogy software out there (certainly >> >> >> > the >> >> >> > open >> >> >> > source). With Django you might have something quickly perhaps :-) >> >> >> >> >> >> I like bringing the idea of the UID into the discussion, and I'd >> >> >> like >> >> >> to move towards such integration. Perhaps we can head in that >> >> >> direction by moving the linking code to a central library that will >> >> >> do >> >> >> what it currently does, and then add the abilities to "resolve" >> >> >> UID's >> >> >> into handles (ie, the UID used locally) in the future. >> >> >> >> >> >> I think for NarWeb, we'll need to at least have as an option to make >> >> >> it a completely static process, as many people use it as a "viewer" >> >> >> for their trees, even when off-line. >> >> >> >> >> >> The details of linking may change in trunk as we evolve this idea. >> >> >> But >> >> >> I will try to make it possible for those testers to migrate their >> >> >> links as the spec changes. Adding links to notes is time-consuming, >> >> >> but I'm finding really useful. It turns notes into an interface to >> >> >> all >> >> >> gramps objects. Cool! >> >> >> >> >> >> Warning: if you add links in trunk, and then edit the notes in >> >> >> gramps32, the links will be silently removed. >> >> > >> >> > Ok, I further agree with Gerald: the notes are text, and linking does >> >> > not >> >> > mean back references are added . Links to http:'// or gramps:// can >> >> > become >> >> > stale. >> >> > What would be usefull and perhaps even required before release of >> >> > this: >> >> > 1/a note quickview (or extra tab?) listing all links used in a note >> >> > 2/a report/filter showing which notes contain broken links to >> >> > gramps:// >> >> >> >> I've added a "Link References" quickview that simply lists the links >> >> that are in a note with these columns: type (Gramps or Internet), a >> >> description of the gramps object or URL, and a link check (if gramps >> >> object). Double-clicking a row will bring up the gramps object. Bad >> >> links show the gramps URI and a failed check message. >> >> >> >> This immediately suggests two additional things: >> >> >> >> 1) a way to list all links across all notes (and their valid status) >> >> 2) a way to easily find and correct bad links (links know their >> >> location in the text) >> >> >> >> However, we still need a back-link-reference list so that one can >> >> easily find all of notes that mention a particular object. Doesn't the >> >> back-reference infrastructure already do this? What are the pros of >> >> replicating this, rather than just using it for link back-references? >> > >> > To add back reference list would require needs careful planning. >> > I would really leave the link as part of the note text, not as a formal >> > link >> > between database tables. >> > >> > Now, a person can have a note. If officially a note can 'have' a person, >> > then the backreference of the person would show the note. >> > >> > Technically possible, we just have to be sure the large amount of work >> > to do >> > it is worth it. >> >> As I don't know the back-ref system, I don't know how much work it >> would take. I just thought that when you add a link to an object, you >> would add a backref link to the note. If you clear a link, it would >> remove it from the object. Isn't that it? >> >> > The question you ask can also be solved with a report/tool, without the >> > database infrastructure. We only need the speed of storing it in the >> > database table if >> > 1/the question is be asked often >> > 2/avoiding stale links. >> >> Whatever the UI mechanism, it should be as handy as the References >> tab, as you would surely want to click it to go there. >> >> > However, the use case is not working 100%. If you have note referring to >> > a >> > person, and you delete the person, one can remove the gramps:// link >> > automatically, but one can not change the text. So it is very different >> > from >> > the other types of backreference we have. Moreover, a user might be >> > interested in leaving the stale link, as it means he did something wrong >> > ... >> >> One idea that might solve some of this is: >> >> If you attempt to link to an object from a note, you check to see if >> that object shares this note. If it doesn't, you ask the user if they >> would like to share it. That way, the sharing could take the place of >> the backref. >> >> There could be a setting in preferences: >> >> ( ) Always share a note with an object that you link to >> ( ) Never share a note with an object that you link to >> ( ) Ask me each time I create a link to share note with object or not >> >> It could be argued that if you are mentioning an object from a note, >> it should share that note. > > Yes and no. I agree the note might want to be shared, but if you as a user > don't want it for this note, and do want for another, this way of setting > things in the preferences would be annoying. > > It does not really fix anything however, as you would still just delete a > person/place/..., even if this note is attached. > > Well, we understand all this because we really understand how Gramps works. > For normal users this does not look like a good workflow, that is, many > technical things a user is not interested in. We should make it 'just work', > not require the users to decide things like this. I agree that all of the implications of making a link from a note to an object might not be clear, not even to us! For example, if you link a note to a place, should you include that place in NarWeb? If you want it to "just work" I would think that the answer should be "yes". As you pointed out, that implies that notes "can have" places. This particular issue could be solved by adding backlinks, or by adding a share to the note. But neither of those look appealing right now. So, I'll create a couple of more tools/reports to help users manage their links manually. If that creates too many issues that do not "just work", then we will perhaps have to think about spending some energy to bring them up to the same level of support as other backlinks. We can try the manual mode in gramps 3.3 and see how it works. -Doug > Benny >> >> -Doug >> >> > Benny >> >> >> >> >> >> -Doug >> >> >> >> > Benny >> >> >> >> >> >> -Doug >> >> >> >> >> >> > Benny >> >> >> > >> >> >> >> > >> >> >> >> > If no one has an objection, I'll apply this patch to trunk in >> >> >> >> > the >> >> >> >> > next >> >> >> >> > couple of days. >> >> >> >> > >> >> >> >> > -Doug >> >> >> >> > >> >> >> >> > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > ------------------------------------------------------------------------------ >> >> >> >> > _______________________________________________ >> >> >> >> > Gramps-devel mailing list >> >> >> >> > [hidden email] >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Gerald Britton >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> >> >> 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 |
Re: Linking in Notes
|
|
2010/5/10 Doug Blank <[hidden email]> On Sun, May 9, 2010 at 1:40 PM, Benny Malengier Yes. Also, if you allow links to notes so as to allow for a narrative over different pages, then it becomes really messy to use our backlink system. I think the manual way is good though, just like web pages. As always, one normally adds data in Gramps, one does not delete often. Only problem is merging, where after a merge, you might have stale links to objects. Benny
------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
On Mon, May 10, 2010 at 3:12 AM, Benny Malengier
<[hidden email]> wrote: > > > 2010/5/10 Doug Blank <[hidden email]> >> >> On Sun, May 9, 2010 at 1:40 PM, Benny Malengier >> <[hidden email]> wrote: >> > >> > >> > 2010/5/7 Doug Blank <[hidden email]> >> >> >> >> On Fri, May 7, 2010 at 9:37 AM, Benny Malengier >> >> <[hidden email]> wrote: >> >> > >> >> > >> >> > 2010/5/7 Doug Blank <[hidden email]> >> >> >> >> >> >> On Fri, May 7, 2010 at 7:50 AM, Benny Malengier >> >> >> <[hidden email]> wrote: >> >> >> > >> >> >> > >> >> >> > 2010/5/7 Doug Blank <[hidden email]> >> >> >> >> >> >> >> >> On Fri, May 7, 2010 at 3:29 AM, Benny Malengier >> >> >> >> <[hidden email]> wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> > 2010/5/6 Gerald Britton <[hidden email]> >> >> >> >> >> >> >> >> >> >> > * could we link to other trees other than the current one, >> >> >> >> >> > or >> >> >> >> >> > to >> >> >> >> >> > some >> >> >> >> >> > kind of gramps server/database, such as >> >> >> >> >> > >> >> >> >> >> > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? >> >> >> >> >> > Should >> >> >> >> >> > we plan for that? >> >> >> >> >> >> >> >> >> >> Linking to another tree is interesting for sure. However, to >> >> >> >> >> follow >> >> >> >> >> the link you'd have to open the other db (read only), get the >> >> >> >> >> data >> >> >> >> >> then close the db. We could keep a list of open dbs for that, >> >> >> >> >> I >> >> >> >> >> suppose. I wonder if linking to an external db (not on the >> >> >> >> >> same >> >> >> >> >> machine) could not be transparently handled with normal URLs. >> >> >> >> >> >> >> >> >> > >> >> >> >> > Let's stick to the unix way of things with trying to do one >> >> >> >> > thing >> >> >> >> > really >> >> >> >> > well. >> >> >> >> > For links between family trees, we should use the UID/GUID/_UID >> >> >> >> > method >> >> >> >> > as we >> >> >> >> > investigate for merge: >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge >> >> >> >> > >> >> >> >> > So something like >> >> >> >> > gramps://object/UID/XXX >> >> >> >> > >> >> >> >> > But then UID must be resolved and linked. We still have to work >> >> >> >> > out >> >> >> >> > how >> >> >> >> > to >> >> >> >> > store this in Gramps (a special attribute). The logical way >> >> >> >> > would >> >> >> >> > be >> >> >> >> > that >> >> >> >> > clicking on UID brings you to a page with link to other places >> >> >> >> > where >> >> >> >> > that >> >> >> >> > UID is registered. So the setup would be >> >> >> >> > 1. you have a family tree >> >> >> >> > 2. you generate UID for your objects because you want linking >> >> >> >> > over >> >> >> >> > trees >> >> >> >> > with nice merge >> >> >> >> > 3. you submit your list of UID to a "central service". This >> >> >> >> > service >> >> >> >> > allows >> >> >> >> > to indicate two different UID refer to the same person, and >> >> >> >> > keeps >> >> >> >> > a >> >> >> >> > 'link' >> >> >> >> > to the place the object is stored >> >> >> >> > 4. when generating a website, clicking a UID link goes to a >> >> >> >> > page >> >> >> >> > as >> >> >> >> > generated by the central service, which allows click through to >> >> >> >> > other >> >> >> >> > databases. >> >> >> >> > 5. Gramps itself can query the central service and update it's >> >> >> >> > internal >> >> >> >> > list >> >> >> >> > of UID if user wants that >> >> >> >> > 6. The central service is not really central, so different of >> >> >> >> > these >> >> >> >> > services >> >> >> >> > can interact to update their own master list. >> >> >> >> > >> >> >> >> > Clearly, above is a bit futuristic, and involves some API which >> >> >> >> > is >> >> >> >> > eg >> >> >> >> > also >> >> >> >> > acceptable to the other genealogy software out there (certainly >> >> >> >> > the >> >> >> >> > open >> >> >> >> > source). With Django you might have something quickly perhaps >> >> >> >> > :-) >> >> >> >> >> >> >> >> I like bringing the idea of the UID into the discussion, and I'd >> >> >> >> like >> >> >> >> to move towards such integration. Perhaps we can head in that >> >> >> >> direction by moving the linking code to a central library that >> >> >> >> will >> >> >> >> do >> >> >> >> what it currently does, and then add the abilities to "resolve" >> >> >> >> UID's >> >> >> >> into handles (ie, the UID used locally) in the future. >> >> >> >> >> >> >> >> I think for NarWeb, we'll need to at least have as an option to >> >> >> >> make >> >> >> >> it a completely static process, as many people use it as a >> >> >> >> "viewer" >> >> >> >> for their trees, even when off-line. >> >> >> >> >> >> >> >> The details of linking may change in trunk as we evolve this >> >> >> >> idea. >> >> >> >> But >> >> >> >> I will try to make it possible for those testers to migrate their >> >> >> >> links as the spec changes. Adding links to notes is >> >> >> >> time-consuming, >> >> >> >> but I'm finding really useful. It turns notes into an interface >> >> >> >> to >> >> >> >> all >> >> >> >> gramps objects. Cool! >> >> >> >> >> >> >> >> Warning: if you add links in trunk, and then edit the notes in >> >> >> >> gramps32, the links will be silently removed. >> >> >> > >> >> >> > Ok, I further agree with Gerald: the notes are text, and linking >> >> >> > does >> >> >> > not >> >> >> > mean back references are added . Links to http:'// or gramps:// >> >> >> > can >> >> >> > become >> >> >> > stale. >> >> >> > What would be usefull and perhaps even required before release of >> >> >> > this: >> >> >> > 1/a note quickview (or extra tab?) listing all links used in a >> >> >> > note >> >> >> > 2/a report/filter showing which notes contain broken links to >> >> >> > gramps:// >> >> >> >> >> >> I've added a "Link References" quickview that simply lists the links >> >> >> that are in a note with these columns: type (Gramps or Internet), a >> >> >> description of the gramps object or URL, and a link check (if gramps >> >> >> object). Double-clicking a row will bring up the gramps object. Bad >> >> >> links show the gramps URI and a failed check message. >> >> >> >> >> >> This immediately suggests two additional things: >> >> >> >> >> >> 1) a way to list all links across all notes (and their valid status) >> >> >> 2) a way to easily find and correct bad links (links know their >> >> >> location in the text) >> >> >> >> >> >> However, we still need a back-link-reference list so that one can >> >> >> easily find all of notes that mention a particular object. Doesn't >> >> >> the >> >> >> back-reference infrastructure already do this? What are the pros of >> >> >> replicating this, rather than just using it for link >> >> >> back-references? >> >> > >> >> > To add back reference list would require needs careful planning. >> >> > I would really leave the link as part of the note text, not as a >> >> > formal >> >> > link >> >> > between database tables. >> >> > >> >> > Now, a person can have a note. If officially a note can 'have' a >> >> > person, >> >> > then the backreference of the person would show the note. >> >> > >> >> > Technically possible, we just have to be sure the large amount of >> >> > work >> >> > to do >> >> > it is worth it. >> >> >> >> As I don't know the back-ref system, I don't know how much work it >> >> would take. I just thought that when you add a link to an object, you >> >> would add a backref link to the note. If you clear a link, it would >> >> remove it from the object. Isn't that it? >> >> >> >> > The question you ask can also be solved with a report/tool, without >> >> > the >> >> > database infrastructure. We only need the speed of storing it in the >> >> > database table if >> >> > 1/the question is be asked often >> >> > 2/avoiding stale links. >> >> >> >> Whatever the UI mechanism, it should be as handy as the References >> >> tab, as you would surely want to click it to go there. >> >> >> >> > However, the use case is not working 100%. If you have note referring >> >> > to >> >> > a >> >> > person, and you delete the person, one can remove the gramps:// link >> >> > automatically, but one can not change the text. So it is very >> >> > different >> >> > from >> >> > the other types of backreference we have. Moreover, a user might be >> >> > interested in leaving the stale link, as it means he did something >> >> > wrong >> >> > ... >> >> >> >> One idea that might solve some of this is: >> >> >> >> If you attempt to link to an object from a note, you check to see if >> >> that object shares this note. If it doesn't, you ask the user if they >> >> would like to share it. That way, the sharing could take the place of >> >> the backref. >> >> >> >> There could be a setting in preferences: >> >> >> >> ( ) Always share a note with an object that you link to >> >> ( ) Never share a note with an object that you link to >> >> ( ) Ask me each time I create a link to share note with object or not >> >> >> >> It could be argued that if you are mentioning an object from a note, >> >> it should share that note. >> > >> > Yes and no. I agree the note might want to be shared, but if you as a >> > user >> > don't want it for this note, and do want for another, this way of >> > setting >> > things in the preferences would be annoying. >> > >> > It does not really fix anything however, as you would still just delete >> > a >> > person/place/..., even if this note is attached. >> > >> > Well, we understand all this because we really understand how Gramps >> > works. >> > For normal users this does not look like a good workflow, that is, many >> > technical things a user is not interested in. We should make it 'just >> > work', >> > not require the users to decide things like this. >> >> I agree that all of the implications of making a link from a note to >> an object might not be clear, not even to us! For example, if you link >> a note to a place, should you include that place in NarWeb? If you >> want it to "just work" I would think that the answer should be "yes". >> As you pointed out, that implies that notes "can have" places. >> >> This particular issue could be solved by adding backlinks, or by >> adding a share to the note. But neither of those look appealing right >> now. >> >> So, I'll create a couple of more tools/reports to help users manage >> their links manually. If that creates too many issues that do not >> "just work", then we will perhaps have to think about spending some >> energy to bring them up to the same level of support as other >> backlinks. We can try the manual mode in gramps 3.3 and see how it >> works. > > Yes. > Also, if you allow links to notes so as to allow for a narrative over > different pages, then it becomes really messy to use our backlink system. > I think the manual way is good though, just like web pages. As always, one > normally adds data in Gramps, one does not delete often. Only problem is > merging, where after a merge, you might have stale links to objects. Merging could be handled by a better UID system where both handles map to the same object. Even deleting could be handled through the UID system: "You have attempted to access Martha Smith [I0023] who is no longer in this tree". -Doug > Benny > >> >> -Doug >> >> > Benny >> >> >> >> -Doug >> >> >> >> > Benny >> >> >> >> >> >> >> >> >> -Doug >> >> >> >> >> >> > Benny >> >> >> >> >> >> >> >> -Doug >> >> >> >> >> >> >> >> > Benny >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > If no one has an objection, I'll apply this patch to trunk >> >> >> >> >> > in >> >> >> >> >> > the >> >> >> >> >> > next >> >> >> >> >> > couple of days. >> >> >> >> >> > >> >> >> >> >> > -Doug >> >> >> >> >> > >> >> >> >> >> > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > ------------------------------------------------------------------------------ >> >> >> >> >> > _______________________________________________ >> >> >> >> >> > Gramps-devel mailing list >> >> >> >> >> > [hidden email] >> >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> Gerald Britton >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> >> >> >> >> 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 |
Re: Linking in Notes
|
|
don't know if this has come up before, but with links in notes you can
have circular refs, I think: e.g. person 1 has a note which links to person 2 who is married to person 1. event 1 has a note linking to a family which has a note linking to event 1. You would need logic to detect the cycles or turn the chain of links into a DAG somehow. On Mon, May 10, 2010 at 12:36 PM, Doug Blank <[hidden email]> wrote: > On Mon, May 10, 2010 at 3:12 AM, Benny Malengier > <[hidden email]> wrote: >> >> >> 2010/5/10 Doug Blank <[hidden email]> >>> >>> On Sun, May 9, 2010 at 1:40 PM, Benny Malengier >>> <[hidden email]> wrote: >>> > >>> > >>> > 2010/5/7 Doug Blank <[hidden email]> >>> >> >>> >> On Fri, May 7, 2010 at 9:37 AM, Benny Malengier >>> >> <[hidden email]> wrote: >>> >> > >>> >> > >>> >> > 2010/5/7 Doug Blank <[hidden email]> >>> >> >> >>> >> >> On Fri, May 7, 2010 at 7:50 AM, Benny Malengier >>> >> >> <[hidden email]> wrote: >>> >> >> > >>> >> >> > >>> >> >> > 2010/5/7 Doug Blank <[hidden email]> >>> >> >> >> >>> >> >> >> On Fri, May 7, 2010 at 3:29 AM, Benny Malengier >>> >> >> >> <[hidden email]> wrote: >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > 2010/5/6 Gerald Britton <[hidden email]> >>> >> >> >> >> >>> >> >> >> >> > * could we link to other trees other than the current one, >>> >> >> >> >> > or >>> >> >> >> >> > to >>> >> >> >> >> > some >>> >> >> >> >> > kind of gramps server/database, such as >>> >> >> >> >> > >>> >> >> >> >> > gramps://myserver.com/myTree/Person/handle/127562365bvsdgh986? >>> >> >> >> >> > Should >>> >> >> >> >> > we plan for that? >>> >> >> >> >> >>> >> >> >> >> Linking to another tree is interesting for sure. However, to >>> >> >> >> >> follow >>> >> >> >> >> the link you'd have to open the other db (read only), get the >>> >> >> >> >> data >>> >> >> >> >> then close the db. We could keep a list of open dbs for that, >>> >> >> >> >> I >>> >> >> >> >> suppose. I wonder if linking to an external db (not on the >>> >> >> >> >> same >>> >> >> >> >> machine) could not be transparently handled with normal URLs. >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > Let's stick to the unix way of things with trying to do one >>> >> >> >> > thing >>> >> >> >> > really >>> >> >> >> > well. >>> >> >> >> > For links between family trees, we should use the UID/GUID/_UID >>> >> >> >> > method >>> >> >> >> > as we >>> >> >> >> > investigate for merge: >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > http://gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge >>> >> >> >> > >>> >> >> >> > So something like >>> >> >> >> > gramps://object/UID/XXX >>> >> >> >> > >>> >> >> >> > But then UID must be resolved and linked. We still have to work >>> >> >> >> > out >>> >> >> >> > how >>> >> >> >> > to >>> >> >> >> > store this in Gramps (a special attribute). The logical way >>> >> >> >> > would >>> >> >> >> > be >>> >> >> >> > that >>> >> >> >> > clicking on UID brings you to a page with link to other places >>> >> >> >> > where >>> >> >> >> > that >>> >> >> >> > UID is registered. So the setup would be >>> >> >> >> > 1. you have a family tree >>> >> >> >> > 2. you generate UID for your objects because you want linking >>> >> >> >> > over >>> >> >> >> > trees >>> >> >> >> > with nice merge >>> >> >> >> > 3. you submit your list of UID to a "central service". This >>> >> >> >> > service >>> >> >> >> > allows >>> >> >> >> > to indicate two different UID refer to the same person, and >>> >> >> >> > keeps >>> >> >> >> > a >>> >> >> >> > 'link' >>> >> >> >> > to the place the object is stored >>> >> >> >> > 4. when generating a website, clicking a UID link goes to a >>> >> >> >> > page >>> >> >> >> > as >>> >> >> >> > generated by the central service, which allows click through to >>> >> >> >> > other >>> >> >> >> > databases. >>> >> >> >> > 5. Gramps itself can query the central service and update it's >>> >> >> >> > internal >>> >> >> >> > list >>> >> >> >> > of UID if user wants that >>> >> >> >> > 6. The central service is not really central, so different of >>> >> >> >> > these >>> >> >> >> > services >>> >> >> >> > can interact to update their own master list. >>> >> >> >> > >>> >> >> >> > Clearly, above is a bit futuristic, and involves some API which >>> >> >> >> > is >>> >> >> >> > eg >>> >> >> >> > also >>> >> >> >> > acceptable to the other genealogy software out there (certainly >>> >> >> >> > the >>> >> >> >> > open >>> >> >> >> > source). With Django you might have something quickly perhaps >>> >> >> >> > :-) >>> >> >> >> >>> >> >> >> I like bringing the idea of the UID into the discussion, and I'd >>> >> >> >> like >>> >> >> >> to move towards such integration. Perhaps we can head in that >>> >> >> >> direction by moving the linking code to a central library that >>> >> >> >> will >>> >> >> >> do >>> >> >> >> what it currently does, and then add the abilities to "resolve" >>> >> >> >> UID's >>> >> >> >> into handles (ie, the UID used locally) in the future. >>> >> >> >> >>> >> >> >> I think for NarWeb, we'll need to at least have as an option to >>> >> >> >> make >>> >> >> >> it a completely static process, as many people use it as a >>> >> >> >> "viewer" >>> >> >> >> for their trees, even when off-line. >>> >> >> >> >>> >> >> >> The details of linking may change in trunk as we evolve this >>> >> >> >> idea. >>> >> >> >> But >>> >> >> >> I will try to make it possible for those testers to migrate their >>> >> >> >> links as the spec changes. Adding links to notes is >>> >> >> >> time-consuming, >>> >> >> >> but I'm finding really useful. It turns notes into an interface >>> >> >> >> to >>> >> >> >> all >>> >> >> >> gramps objects. Cool! >>> >> >> >> >>> >> >> >> Warning: if you add links in trunk, and then edit the notes in >>> >> >> >> gramps32, the links will be silently removed. >>> >> >> > >>> >> >> > Ok, I further agree with Gerald: the notes are text, and linking >>> >> >> > does >>> >> >> > not >>> >> >> > mean back references are added . Links to http:'// or gramps:// >>> >> >> > can >>> >> >> > become >>> >> >> > stale. >>> >> >> > What would be usefull and perhaps even required before release of >>> >> >> > this: >>> >> >> > 1/a note quickview (or extra tab?) listing all links used in a >>> >> >> > note >>> >> >> > 2/a report/filter showing which notes contain broken links to >>> >> >> > gramps:// >>> >> >> >>> >> >> I've added a "Link References" quickview that simply lists the links >>> >> >> that are in a note with these columns: type (Gramps or Internet), a >>> >> >> description of the gramps object or URL, and a link check (if gramps >>> >> >> object). Double-clicking a row will bring up the gramps object. Bad >>> >> >> links show the gramps URI and a failed check message. >>> >> >> >>> >> >> This immediately suggests two additional things: >>> >> >> >>> >> >> 1) a way to list all links across all notes (and their valid status) >>> >> >> 2) a way to easily find and correct bad links (links know their >>> >> >> location in the text) >>> >> >> >>> >> >> However, we still need a back-link-reference list so that one can >>> >> >> easily find all of notes that mention a particular object. Doesn't >>> >> >> the >>> >> >> back-reference infrastructure already do this? What are the pros of >>> >> >> replicating this, rather than just using it for link >>> >> >> back-references? >>> >> > >>> >> > To add back reference list would require needs careful planning. >>> >> > I would really leave the link as part of the note text, not as a >>> >> > formal >>> >> > link >>> >> > between database tables. >>> >> > >>> >> > Now, a person can have a note. If officially a note can 'have' a >>> >> > person, >>> >> > then the backreference of the person would show the note. >>> >> > >>> >> > Technically possible, we just have to be sure the large amount of >>> >> > work >>> >> > to do >>> >> > it is worth it. >>> >> >>> >> As I don't know the back-ref system, I don't know how much work it >>> >> would take. I just thought that when you add a link to an object, you >>> >> would add a backref link to the note. If you clear a link, it would >>> >> remove it from the object. Isn't that it? >>> >> >>> >> > The question you ask can also be solved with a report/tool, without >>> >> > the >>> >> > database infrastructure. We only need the speed of storing it in the >>> >> > database table if >>> >> > 1/the question is be asked often >>> >> > 2/avoiding stale links. >>> >> >>> >> Whatever the UI mechanism, it should be as handy as the References >>> >> tab, as you would surely want to click it to go there. >>> >> >>> >> > However, the use case is not working 100%. If you have note referring >>> >> > to >>> >> > a >>> >> > person, and you delete the person, one can remove the gramps:// link >>> >> > automatically, but one can not change the text. So it is very >>> >> > different >>> >> > from >>> >> > the other types of backreference we have. Moreover, a user might be >>> >> > interested in leaving the stale link, as it means he did something >>> >> > wrong >>> >> > ... >>> >> >>> >> One idea that might solve some of this is: >>> >> >>> >> If you attempt to link to an object from a note, you check to see if >>> >> that object shares this note. If it doesn't, you ask the user if they >>> >> would like to share it. That way, the sharing could take the place of >>> >> the backref. >>> >> >>> >> There could be a setting in preferences: >>> >> >>> >> ( ) Always share a note with an object that you link to >>> >> ( ) Never share a note with an object that you link to >>> >> ( ) Ask me each time I create a link to share note with object or not >>> >> >>> >> It could be argued that if you are mentioning an object from a note, >>> >> it should share that note. >>> > >>> > Yes and no. I agree the note might want to be shared, but if you as a >>> > user >>> > don't want it for this note, and do want for another, this way of >>> > setting >>> > things in the preferences would be annoying. >>> > >>> > It does not really fix anything however, as you would still just delete >>> > a >>> > person/place/..., even if this note is attached. >>> > >>> > Well, we understand all this because we really understand how Gramps >>> > works. >>> > For normal users this does not look like a good workflow, that is, many >>> > technical things a user is not interested in. We should make it 'just >>> > work', >>> > not require the users to decide things like this. >>> >>> I agree that all of the implications of making a link from a note to >>> an object might not be clear, not even to us! For example, if you link >>> a note to a place, should you include that place in NarWeb? If you >>> want it to "just work" I would think that the answer should be "yes". >>> As you pointed out, that implies that notes "can have" places. >>> >>> This particular issue could be solved by adding backlinks, or by >>> adding a share to the note. But neither of those look appealing right >>> now. >>> >>> So, I'll create a couple of more tools/reports to help users manage >>> their links manually. If that creates too many issues that do not >>> "just work", then we will perhaps have to think about spending some >>> energy to bring them up to the same level of support as other >>> backlinks. We can try the manual mode in gramps 3.3 and see how it >>> works. >> >> Yes. >> Also, if you allow links to notes so as to allow for a narrative over >> different pages, then it becomes really messy to use our backlink system. >> I think the manual way is good though, just like web pages. As always, one >> normally adds data in Gramps, one does not delete often. Only problem is >> merging, where after a merge, you might have stale links to objects. > > Merging could be handled by a better UID system where both handles map > to the same object. Even deleting could be handled through the UID > system: "You have attempted to access Martha Smith [I0023] who is no > longer in this tree". > > -Doug > >> Benny >> >>> >>> -Doug >>> >>> > Benny >>> >> >>> >> -Doug >>> >> >>> >> > Benny >>> >> >> >>> >> >> >>> >> >> -Doug >>> >> >> >>> >> >> > Benny >>> >> >> >> >>> >> >> >> -Doug >>> >> >> >> >>> >> >> >> > Benny >>> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > If no one has an objection, I'll apply this patch to trunk >>> >> >> >> >> > in >>> >> >> >> >> > the >>> >> >> >> >> > next >>> >> >> >> >> > couple of days. >>> >> >> >> >> > >>> >> >> >> >> > -Doug >>> >> >> >> >> > >>> >> >> >> >> > [1] - http://www.gramps-project.org/bugs/view.php?id=3914 >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > ------------------------------------------------------------------------------ >>> >> >> >> >> > _______________________________________________ >>> >> >> >> >> > Gramps-devel mailing list >>> >> >> >> >> > [hidden email] >>> >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> -- >>> >> >> >> >> Gerald Britton >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> ------------------------------------------------------------------------------ >>> >> >> >> >> _______________________________________________ >>> >> >> >> >> Gramps-devel mailing list >>> >> >> >> >> [hidden email] >>> >> >> >> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> >> >> > >>> >> >> >> > >>> >> >> > >>> >> >> > >>> >> > >>> >> > >>> > >>> > >> >> > -- Gerald Britton ------------------------------------------------------------------------------ _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
«
Return to GRAMPS - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |