Extending org-contacts with properties: naming properties

Extending org-contacts with properties: naming properties

[Karl Voit]

Hi!

I want to extend my (IMHO already advanced) org-contacts setup with
information I gave *to* companies about myself: what email address I
gave them (I own a catch-all email domain)[1], what address they
stored about me (in case I am moving and want to update), what phone
number they got of me (land-line, mobile, nothing), and so on.

Example: http://paste.grml.org/1445/

I am unsure about the prefix of those information I gave away. In my
example, I was using "INFORMED_". However, I got other candidates as
well (from IRC: ##English) and I am open for new ones:

  - mediated
  - assigned
  - passed
  - requested
  - connexidatum
  - stored
  - delivered

As a German speaking person, I would like to read about your
thoughts on the correct naming of this stuff. 

The crucial issues are that the prefix should be understood without
much description and that is does not get mixed up with information
I am storing about contacts.

Thanks!

  1. I guess this will be very handy to automatically derive my mail
     filter set-up (spam tools, procmail, ...) :-)

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Extending org-contacts with properties: naming properties

[Samuel Wales]

Provided?  Given?

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: Extending org-contacts with properties: naming properties

[David Rogers]

Samuel Wales <samologist@gmail.com> writes:

> Provided?  Given?

I agree that this kind of simple thing looks like a better
idea. However, it would also be nice to be able to call it some name
where a person who encounters the software capability but doesn't yet
know what it's for will understand what it's for just from reading the
name. "Given" is simple and sounds clear, but it doesn't say who did the
giving so the clarity is over-rated. "CustomerInfoIGaveThem" is a bit
long. :) (and TheirRecordOfMe is hardly any better.) :)

-- 
David

Re: Extending org-contacts with properties: naming properties

[Samuel Wales]

Perhaps relaxing the understandability requirement in favor of
searchability would work.

Re: Extending org-contacts with properties: naming properties

[Karl Voit]

* David Rogers <davidandrewrogers@gmail.com> wrote:
>
> I agree that this kind of simple thing looks like a better
> idea. However, it would also be nice to be able to call it some name
> where a person who encounters the software capability but doesn't yet
> know what it's for will understand what it's for just from reading the
> name. 

This is my goal, yes.

> "Given" is simple and sounds clear, but it doesn't say who did the
> giving so the clarity is over-rated. "CustomerInfoIGaveThem" is a bit
> long. :) (and TheirRecordOfMe is hardly any better.) :)

I am trying to find something that fulfills the trade-off between
short and descriptive/long. Is it true that none of my words from
the first mail is reaching the goal somewhat?

  - mediated
  - informed
  - assigned
  - passed
  - requested
  - connexidatum
  - stored
  - delivered

I am depending here on the native speakers who can judge better than
me using a translation tool ...

Then, there are some possible combinations I could think of:

  - I_gave_phone
  - About_me_phone
  - About_my_phone
  - ...

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Extending org-contacts with properties: naming properties

[Robert Horn]

Karl Voit writes:

> * David Rogers <davidandrewrogers@gmail.com> wrote:
>>
>> I agree that this kind of simple thing looks like a better
>> idea. However, it would also be nice to be able to call it some name
>> where a person who encounters the software capability but doesn't yet
>> know what it's for will understand what it's for just from reading the
>> name. 
>
> This is my goal, yes.
>
>> "Given" is simple and sounds clear, but it doesn't say who did the
>> giving so the clarity is over-rated. "CustomerInfoIGaveThem" is a bit
>> long. :) (and TheirRecordOfMe is hardly any better.) :)
>

My first reaction was to use a short sentence like "itoldthem".  I can't
think of any single english word that doesn't also need a subject to
describe which direction the transfer went.

R Horn

Re: Extending org-contacts with properties: naming properties

[Eric Abrahamsen]

Karl Voit <devnull@Karl-Voit.at> writes:

> * David Rogers <davidandrewrogers@gmail.com> wrote:
>>
>> I agree that this kind of simple thing looks like a better
>> idea. However, it would also be nice to be able to call it some name
>> where a person who encounters the software capability but doesn't yet
>> know what it's for will understand what it's for just from reading the
>> name. 
>
> This is my goal, yes.
>
>> "Given" is simple and sounds clear, but it doesn't say who did the
>> giving so the clarity is over-rated. "CustomerInfoIGaveThem" is a bit
>> long. :) (and TheirRecordOfMe is hardly any better.) :)
>
> I am trying to find something that fulfills the trade-off between
> short and descriptive/long. Is it true that none of my words from
> the first mail is reaching the goal somewhat?
>
>   - mediated
>   - informed
>   - assigned
>   - passed
>   - requested
>   - connexidatum
>   - stored
>   - delivered
>
> I am depending here on the native speakers who can judge better than
> me using a translation tool ...
>
> Then, there are some possible combinations I could think of:
>
>   - I_gave_phone
>   - About_me_phone
>   - About_my_phone
>   - ...

Is this a prefix for multiple values? Ie, it will be "XXX_email",
"XXX_cell", "XXX_phone" and so on? I think the word "context" is pretty
relevant here; you might consider something like "CONTEXT_EMAIL" or
"CONTEXT_MY_EMAIL".

Just a thought.

E

Re: Extending org-contacts with properties: naming properties

[Karl Voit]

* Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
> Is this a prefix for multiple values? Ie, it will be "XXX_email",
> "XXX_cell", "XXX_phone" and so on? 

Yes.

> I think the word "context" is pretty
> relevant here; you might consider something like "CONTEXT_EMAIL" or
> "CONTEXT_MY_EMAIL".
>
> Just a thought.

I agree, that the context is important here. However,
"context_address" could be mixed up with "this is the address where
I met this person" or similar.

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Extending org-contacts with properties: naming properties

[Karl Voit]

* Robert Horn <rjhorn@alum.mit.edu> wrote:
>
> My first reaction was to use a short sentence like "itoldthem".  I can't
> think of any single english word that doesn't also need a subject to
> describe which direction the transfer went.

I love it :-)

It's set: my first properties will be:

    :ITOLDTHEM_EMAIL:
    :ITOLDTHEM_ADDRESS:
    :ITOLDTHEM_PHONE:

Thanks!

Can't wait until my mail filter rule file is generated directly
using my contacts.org :-)

-- 
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <

https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github

Re: Extending org-contacts with properties: naming properties

[Esben Stien]

Karl Voit <devnull@Karl-Voit.at> writes:

> It's set: my first properties will be:
>
>     :ITOLDTHEM_EMAIL:
>     :ITOLDTHEM_ADDRESS:
>     :ITOLDTHEM_PHONE:

We can't use a hierarchy?

* Hukarz
:PROPERTIES:
 :TRANSFER:
  :[LINKTOKARLJUNIOR]:
   :EMAIL: bar
   :ADDRESS:
   :PHONE:
  :[LINKTOYOURSELF]:
   :EMAIL: baz
:END:

If this were the contact heading of Hukarz, it would tell you that Karl
Junior transmitted "bar" as the email address of Hukarz and that yourself
transmitted the email "baz"

Using a drawer inside a drawer would also be nice for org-contacts when
you have multiple addresses and a whole slew of other cool stuff. 

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e 
           jid:b0ef@    n     n

Re: Extending org-contacts with properties: naming properties

[Bastien]

Esben Stien <b0ef@esben-stien.name> writes:

> We can't use a hierarchy?

Well, no, sorry!

-- 
 Bastien

Re: Extending org-contacts with properties: naming properties

[Esben Stien]

Esben Stien <b0ef@esben-stien.name> writes:

> * Hukarz
> :PROPERTIES:
>  :TRANSFER:
>   :[LINKTOKARLJUNIOR]:
>    :EMAIL: bar
>    :ADDRESS:
>    :PHONE:
>   :[LINKTOYOURSELF]:
>    :EMAIL: baz
> :END:

Or how about just make the heading a type contact? That would be
infinitely more useful. 

* Hukarz
 :PROPERTIES:
 :ORGTYPE: contact
 :END
** EMAIL
*** foo@bar.bz
 :PROPERTIES:
 :EMAILTYPE: business
 :END:
This dude uses this for business, but actually send him mail via
 private email, cause he sees that after business hours as well;)
** transfer
*** [LINKTOCARLJUNIOR]
**** EMAIL
**** ADDRESS
***** STREET
***** ZIP
**** PHONE
*** [LINKTOYOURSELF]
**** EMAIL

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e 
           jid:b0ef@    n     n

Re: Extending org-contacts with properties: naming properties

[Esben Stien]

Esben Stien <b0ef@esben-stien.name> writes:

Then you could do: 

* Hukarz
 :PROPERTIES:
 :ORGTYPE: contact
 :END
** EMAIL
*** foo@bar.bz
 :PROPERTIES:
 :EMAILTYPE: business0
 :ID: 000
 :END:
This dude uses this for business, but actually send him mail via
 private email, cause he sees that after business hours as well;)
*** foo@baz.quux
 :PROPERTIES:
 :ID: 111
 :EMAILTYPE: private0
 :END:
This is his private email. Only a cool million know this address. It's a
secret. Never teach the wu-tang. 
** transfer
*** [LINKTOCARLJUNIOR]
**** EMAIL
***** [LINKTOID000]
**** ADDRESS
***** STREET
***** ZIP
**** PHONE
*** [LINKTOYOURSELF]
**** EMAIL
***** [LINKTOID111]

When thinking about it, the transfer under each contact, should really
tell what information this person has provided to some other contact

So, 

* Karl Junior
**** email
***** foo@bar.baz
***** quux@bar.baz
 :PROPERTIES:
 :ID: 000
 :END: 
**** informant
***** [Link to Karl Yes Man]

* Karl Yes Man
**** transfer
***** [Link to Karl Junior]
****** [Link to Karl Gustav]
******* email
******** [Link to ID 000]
***** [Link to other witnesses]

..tells us that Karl Yes Man (informant) has transferred information
about Karl Gustav with the email of Karl Junior (quux@foo.bar)

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef@   e     e 
           jid:b0ef@    n     n

Re: Extending org-contacts with properties: naming properties

[Alexis]

Hi Esben,

The way that org-contacts currently works is that contact details are
grouped together in the same PROPERTIES drawer, e.g.

* Alexis
:PROPERTIES:
:EMAIL:  alexis@example.com
:PHONE:  9999-9999
:END:

and that's what i've assumed in my MobileOrg code for parsing
org-contacts data. i imagine that moving away from such a data layout
would require substantial changes to the org-contacts.el code, which i
have no intention of doing - particularly given the work that would be
needed to ensure backwards-compatibility with people's existing data.

For reference, at the moment, in my own org-contacts file, i've set up
grouping via a headings hierarchy like:

* Lists
** Org-mode
:PROPERTIES:
:EMAIL:  emacs-orgmode@gnu.org
:END:
* People
** Mum and Dad
:PROPERTIES:
:PHONE:  8888-8888
:END:
* Organisations
** Free Software Foundation
:PROPERTIES:
:EMAIL:  info@fsf.org
:END:
*** A. Person
:PROPERTIES:
:EMAIL:  a.person@fsf.org
:END:


Alexis.