More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el

[Jean Louis <bugs@gnu.support>]

* stardiviner <numbchild@gmail.com> [2020-11-11 15:05]:
  :PROPERTIES:
  :CREATED:  [2020-11-11 Wed 16:57]
  :ID:       17d463d2-ff0c-4614-93da-06e3de8e6035
  :END:
> Thank you too.
> I indeed want to extend org-contacts.el. So I would like to be it's
> maintainer.
> 
> Currently how many org-mode maintainer(mailing list manager)?
> If patch need to wait a month. Because I spend less time on org-mode too
> comparing before time. I agree with that, I might will add multiple PATCHes
> together.

Side notes:

I have looked into contacts. It relies on a query to find a contact. I
hope that I am right.

Text based Org mode anyway may rely on built-in text searches like
incremental Emacs's search.

org-contact wishes to pin point to specific contact. It wants to
create a hyperlink to one specific contact. It does not want to find 2
contacts with the same query or more of them. 

As I have 195000 contacts in PostgreSQL database I know from browsing
them that many of them have same unique names. To reference to a
specific contact by using name query would be useless as I could miss
it and take other contact. Thus search involves narrowing contacts by
maybe state, location and other filters. Each contact has its own
uniquely assigned ID number. An integer assigned by the database
automatically.

By using the ID number I can easily capture the reference link to th
contact from the database and insert such link into the Org file. As
long as I do not change the ID number even if contact name is changed
I would be able to pin point the specific number.

Thus for org-contacts I recommend creation of unique IDs in the
properties for headings for each contact so that contact may be
referenced by the unique ID.

Additional proposals:

Each hyperdocument (within or without Emacs) that allows back linking
to its specifical parts should have a function or key binding to
quickly obtain the link reference.

For example if user browses heading for *** John Doe anywhere within
such heading user should be able to press a key to capture the link to
the contact automatically.

In the file my-contacts.org:

*** John Doe
    :PROPERTIES:
    :ID:       cc400d57-2adf-47af-90d9-c4d9fdd70d2b
    :CREATED:  [2020-11-11 Wed 16:57]
    :END:

DATA

**** DATA
     :PROPERTIES:
     :CREATED:  [2020-11-11 Wed 16:57]
     :ID:       19781b53-211b-4291-af48-5f3655dd7cec
     :END:

**** DATA
     :PROPERTIES:
     :CREATED:  [2020-11-11 Wed 16:57]
     :ID:       e8eb6647-8d8e-4ec6-b759-43dcfd60d17b
     :END:

Anywhere within the subtree for John Doe user should be able to obtain
the reference to the contact. For example by clicking `C-x w'.

Upon key press following link could then be stored into memory, or
register, whatever is better design:

[[org-contact:~/file/my-contacts.org#cc400d57-2adf-47af-90d9-c4d9fdd70d2b][John Doe]]

Then user would go to other Org file and use `C-y' to yank the contact
into the new file.

One shall consider that obtaining the object reference should be
on the fly customizable. As maybe I wish to have in the link:

- Contact's first name only like when addressing friends

- Contact's full name, with or without middle names

- Contact's name plus city and country

Having several ways to obtain quickly reference to the contact (to
generate link in memory) is useful feature that shortens the time and
makes it less error prone for the user. If only query is used with
simple typo contact link will not work. What will follow is tedious
browsing and opening of files to find the right contact.

User can have many Org contact files and file reference should be
included into the file. This assumes that files should be fixed in
file system.

This proposal follows the Doug Engelbart's Technology Template Project
for Open Hyperdocument Systems (OHS) in relation to addressing:
https://www.dougengelbart.org/content/view/110/460/#2b1

Global, Human-Understandable, Object Addresses

Every object that someone might validly want/need to cite or otherwise
access should have an unambiguous address, capable of being portrayed
in a human readable and interpretable manner. Most common existing
spreadsheet programs have provisions similar to this for cell
addressibility

And:

Link Addresses That Are Readable and Interpretable by Humans
https://www.dougengelbart.org/content/view/110/460/#2b1b

It should be possible to display and specify the complete link address
of any object in the global domain of the OHS. This human-readable
description of the "address path" leading to the cited object should
permit a transparent possibility for human understanding of the path
including the possibility of reading, interpretation, and conceptually
following the specification

As Emacs already supports remote files, contact path can be
automatically obtained. If I am editing contacts on remote VPS server,
maybe users on the remote server and their details, then my local Org
file should be able to point to remote server. Such link would look
like:

[[org-contact:/ssh:example.com/home/me/my-contacts.org#cc400d57-2adf-47af-90d9-c4d9fdd70d2b][John Doe]]

That way the object to cite or access has:

- unambiguious address by having unique ID

- by showing literal links user can see WHERE the object is located,
  is it on localhost, remote server, could be even on https or various
  other locations.

- contact's name remain very human readable

Additionally I have been looking into contacts and have seen the
structure and I think I did not see the group reference. Contact may
belong to one or more groups which I call accounts:

Contact may in in "My family" group, working in the "ABC Company"
group and being member of "Heidelberger Sportverein" group. And each
of those groups can be also a contact with or without individual
names. Every contact management requires groups to satisfy basics of
off-line contact management. People contact hospitals, network
providers, government offices and need not have specific individual
name.

Thus Org contact need a switch or designation to say if the contact is
a group or just individual. And for individuals it should ask in which
group it belongs, while remembering that one contact may belong to
multiple groups.

Text is alright for contact management until it reaches certain size
when it becomes unmanageable. Then it requires GNU GDBM database or
other type of database which we sadly do not have as built-in.

Jean