Quantcast

Linking in Notes

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

Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Gerald Britton-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Stéphane Charette-2
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,

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Benny Malengier
In reply to this post by Gerald Britton-2


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

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Benny Malengier


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

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Benny Malengier


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.
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
 
-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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Benny Malengier


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.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Benny Malengier


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.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linking in Notes

Gerald Britton-2
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
Loading...