Re: [O] Extending org-contacts with properties: naming properties

2014-05-24 Thread Esben Stien
Karl Voit devn...@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 tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n



Re: [O] Extending org-contacts with properties: naming properties

2014-05-24 Thread Bastien
Esben Stien b...@esben-stien.name writes:

 We can't use a hierarchy?

Well, no, sorry!

-- 
 Bastien



Re: [O] Extending org-contacts with properties: naming properties

2014-05-24 Thread Esben Stien
Esben Stien b...@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
*** f...@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 tn m
  irc://irc.  b  -  i  .   e/%23contact
   sip:b0ef@   e e 
   jid:b0ef@n n



Re: [O] Extending org-contacts with properties: naming properties

2014-05-24 Thread Esben Stien
Esben Stien b...@esben-stien.name writes:

Then you could do: 

* Hukarz
 :PROPERTIES:
 :ORGTYPE: contact
 :END
** EMAIL
*** f...@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;)
*** f...@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
* f...@bar.baz
* q...@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 (q...@foo.bar)

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



Re: [O] Extending org-contacts with properties: naming properties

2014-05-24 Thread 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:  ale...@example.com
:PHONE:  -
: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:  -
:END:
* Organisations
** Free Software Foundation
:PROPERTIES:
:EMAIL:  i...@fsf.org
:END:
*** A. Person
:PROPERTIES:
:EMAIL:  a.per...@fsf.org
:END:


Alexis.



Re: [O] Extending org-contacts with properties: naming properties

2013-08-07 Thread Karl Voit
* David Rogers davidandrewrog...@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: [O] Extending org-contacts with properties: naming properties

2013-08-07 Thread Robert Horn

Karl Voit writes:

 * David Rogers davidandrewrog...@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: [O] Extending org-contacts with properties: naming properties

2013-08-07 Thread Eric Abrahamsen
Karl Voit devn...@karl-voit.at writes:

 * David Rogers davidandrewrog...@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: [O] Extending org-contacts with properties: naming properties

2013-08-07 Thread Karl Voit
* Eric Abrahamsen e...@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: [O] Extending org-contacts with properties: naming properties

2013-08-07 Thread Karl Voit
* Robert Horn rjh...@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




[O] Extending org-contacts with properties: naming properties

2013-08-05 Thread 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: [O] Extending org-contacts with properties: naming properties

2013-08-05 Thread 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: [O] Extending org-contacts with properties: naming properties

2013-08-05 Thread David Rogers
Samuel Wales samolog...@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: [O] Extending org-contacts with properties: naming properties

2013-08-05 Thread Samuel Wales
Perhaps relaxing the understandability requirement in favor of
searchability would work.