org-contacts development

org-contacts development

[Alexis]

Hi all,

i use org-contacts as my primary system for contact
management. Consequently, i'd love to be able to make use of my
org-contacts data on my Android phone.

To that end, i recently wrote some code for MobileOrg-Android which adds
basic PROPERTIES drawer support:

https://github.com/matburt/mobileorg-android/pull/434

What i'd now like to do is to add support for transferring data back and
forth between my org-contacts file and the Contacts store on my
phone. The challenge is the mapping between these two systems.

For example, org-contacts provides only one EMAIL property, which can
contain multiple addresses separated by spaces, whereas Android's
ContactsContract.CommonDataKinds.Email class is able to distinguish
between different addresses for different purposes:

http://developer.android.com/reference/android/provider/ContactsContract.CommonDataKinds.Email.html

What would be useful would be an 'official', fleshed-out spec for
org-contacts data, which handles a greater range of contact-related
info. At the moment, for example, my org-contacts file makes use of the
properties:

#+PROPERTY: LANDLINE
#+PROPERTY: MOBILE
#+PROPERTY: POST
#+PROPERTY: RESIDENCE

A search of this list's archives for references to 'org-contacts':

https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-contacts&submit=Search!&idxname=emacs-orgmode&max=20&result=normal&sort=date%3Alate

suggests that org-contacts is something people are using heavily enough
that they're writing code, ad-hoc, to provide functionality they
require, e.g.

http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00869.html

i'm wondering if it might now be appropriate for org-contacts to become
part of org-mode proper, rather than simply a contrib, to reduce
unnecessary duplication of efforts. i suspect that, at the moment, a
number of people interested in making use of org-contacts might be
reluctant to do so (or do so more heavily) because it's not an
'official' part of org-mode. Yet contacts management seems to me to be
functionality well within org-mode's remit.

Fleshing out an extended spec for org-contacts data could be part of the
process of making org-contacts a first-class citizen of org-mode, and
provide a more solid foundation on which people can build (and share)
the org-contacts functionality they're after. And in my own particular
case, it would greatly facilitate my work in org-contacts / Android
Contacts integration. :-)

What do people think?


Alexis.

Re: org-contacts development

[Rasmus]

Alexis <flexibeast@gmail.com> writes:

> What i'd now like to do is to add support for transferring data back and
> forth between my org-contacts file and the Contacts store on my
> phone. The challenge is the mapping between these two systems.

You could also put yourself a slightly different challenge: map
between the org-contacts-format and an carddav server that you
establish as a backend on your phone.  E.g. google contacts is a
carddav server, I think.

I use DAVdroid for syncing my calendar and my contacts with my
OwnCloud and it very, very well!  I sync my agenda with my OwnCloud
using org-caldav, which works great except when you have multiple time
stamps per heading.  For contacts I tried Asynk to sync my bbdb
contacts with OwnCloud, but I was using too many fields unknown to it,
and my contacts got messed up.

Mayhaps you already thought of this approach.  I think it is more
future-proof.


> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of
> the properties:

I would go for whatever properties are supported by Carddav, if
there's a limit.


-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere

Re: org-contacts development

[Alexander Baier]

Hello Alexis,

On 2014-05-23 06:07 Alexis wrote:

[...]

> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of the
> properties:
>
> #+PROPERTY: LANDLINE
> #+PROPERTY: MOBILE
> #+PROPERTY: POST
> #+PROPERTY: RESIDENCE
>

[...]

> Fleshing out an extended spec for org-contacts data could be part of the
> process of making org-contacts a first-class citizen of org-mode, and
> provide a more solid foundation on which people can build (and share)
> the org-contacts functionality they're after. And in my own particular
> case, it would greatly facilitate my work in org-contacts / Android
> Contacts integration. :-)
>
> What do people think?

I, for one, would love to see org-contacts being improved in any way.
Integrating this with MobileOrg would be an extremely helpful and
something I have wanted since the day I started using org-contacts.

About the spec, might it make sense to use a standard already in
existence as a starting point or even a major inspiration?  Something
like vCard for example?

Regards,
-- 
Alexander Baier

Re: org-contacts development

[Xebar Saram]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

Hi Alexis

This sounds awesome, i would love syncing org contacts with my android phone

thx alot!

z


On Fri, May 23, 2014 at 1:30 PM, Alexander Baier <
alexander.baier@mailbox.org> wrote:

> Hello Alexis,
>
> On 2014-05-23 06:07 Alexis wrote:
>
> [...]
>
> > What would be useful would be an 'official', fleshed-out spec for
> > org-contacts data, which handles a greater range of contact-related
> > info. At the moment, for example, my org-contacts file makes use of the
> > properties:
> >
> > #+PROPERTY: LANDLINE
> > #+PROPERTY: MOBILE
> > #+PROPERTY: POST
> > #+PROPERTY: RESIDENCE
> >
>
> [...]
>
> > Fleshing out an extended spec for org-contacts data could be part of the
> > process of making org-contacts a first-class citizen of org-mode, and
> > provide a more solid foundation on which people can build (and share)
> > the org-contacts functionality they're after. And in my own particular
> > case, it would greatly facilitate my work in org-contacts / Android
> > Contacts integration. :-)
> >
> > What do people think?
>
> I, for one, would love to see org-contacts being improved in any way.
> Integrating this with MobileOrg would be an extremely helpful and
> something I have wanted since the day I started using org-contacts.
>
> About the spec, might it make sense to use a standard already in
> existence as a starting point or even a major inspiration?  Something
> like vCard for example?
>
> Regards,
> --
> Alexander Baier
>
>

[-- Attachment #2: Type: text/html, Size: 2129 bytes --]

Re: org-contacts development

[Alexis]

Xebar Saram <zeltakc@gmail.com> writes:

> This sounds awesome, i would love syncing org contacts with my android
> phone

:-) It's good to know i'm not the only one wanting this functionality -
gives me more incentive to actually implement it!


Alexis.

Re: org-contacts development

[Alexis]

Alexander Baier <alexander.baier@mailbox.org> writes:

> About the spec, might it make sense to use a standard already in
> existence as a starting point or even a major inspiration?  Something
> like vCard for example?

Yeah, i like the idea of building on top of vCard, given how widely it's
used and supported, and that it doesn't seem to be a horrible format
.... Those who feel otherwise are going to need to speak up soon or
forever hold their peace. :-)


Alexis.

Re: org-contacts development

[Alexander Baier]

On 2014-05-24 12:15 Alexis wrote:
> Alexander Baier <alexander.baier@mailbox.org> writes:
>
>> About the spec, might it make sense to use a standard already in
>> existence as a starting point or even a major inspiration?  Something
>> like vCard for example?
>
> Yeah, i like the idea of building on top of vCard, given how widely it's
> used and supported, and that it doesn't seem to be a horrible format
> .... Those who feel otherwise are going to need to speak up soon or
> forever hold their peace. :-)
>
>
> Alexis.

For what it's worth, I would love to help out in any way I can.  I use
org-contacts myself and know elisp well enough to also do some
implementing.  But I wouldn't mind writing some documentation, either.
I, however, don't know much about Android programming or the syncing
aspect of this task.

Regards,
-- 
Alexander Baier

Re: org-contacts development

[Bastien]

Hi Alexander,

Alexander Baier <alexander.baier@mailbox.org> writes:

> For what it's worth, I would love to help out in any way I can.  I use
> org-contacts myself and know elisp well enough to also do some
> implementing.  But I wouldn't mind writing some documentation, either.
> I, however, don't know much about Android programming or the syncing
> aspect of this task.

I'm adding Greg (Daimrod) to this thread, as I remember he was kinda
unofficial org-contacts.el maintainer for a while -- you may both
collaborate on org-contacts.el to speed up development.

Thanks in any case!

-- 
 Bastien

Re: org-contacts development

[Alexis]

Alexander Baier <alexander.baier@mailbox.org> writes:

> For what it's worth, I would love to help out in any way I can.  I use
> org-contacts myself and know elisp well enough to also do some
> implementing.  But I wouldn't mind writing some documentation, either.

Thank you! At this point i'm studying RFC 6350 (vCard 4) and the
org-contacts.el source, trying to work out how to bring more of the
former to the latter with a minimal amount of work and fuss. :-)

> I, however, don't know much about Android programming or the syncing
> aspect of this task.

*nod* i'm not sure how much work is involved in the syncing aspect, and
so my first priority is to at least be able to export individual
contacts from MobileOrg to an individual vCard file that can be imported
into the Android Contacts system, and vice versa. There might already be
a FOSS CardDAV library for Android out there that could be used for
syncing, but i've not researched that yet.


Alexis.

Re: org-contacts development

[Rasmus]

Alexis <flexibeast@gmail.com> writes:

> There might already be
> a FOSS CardDAV library for Android out there that could be used for
> syncing, but i've not researched that yet.

Check here:

https://f-droid.org/repository/browse/?fdfilter=carddav&fdpage=1&page_id=0

DAVdroid works very well.

-- 
Sådan en god dansk lagereddike kan man slet ikke bruge mere

Re: org-contacts development

[Alexis]

Rasmus <rasmus@gmx.us> writes:

> Check here:
>
> https://f-droid.org/repository/browse/?fdfilter=carddav&fdpage=1&page_id=0
>
> DAVdroid works very well.

Oh okay, i didn't realise DAVdroid was FOSS.

DAVdroid makes use of the ez-vcard library, which is BSD-licensed, and
certainly seems like it might be useful. However, i'm not sure to what
extent the sync-specific functionality of DAVdroid can be separated from
the rest of the app; superficially, it seems like it's fairly tightly
integrated. But if nothing else, it does show how it can be done! Thank
you. :-)


Alexis.

Re: org-contacts development

[Bastien]

Hi Alexis,

Alexis <flexibeast@gmail.com> writes:

> What do people think?

Improving org-contacts.el and making it part of Org core are two
separate issues -- not everything that is part of Org core gets a
lot of attention, and some contributed packages do.

I'd say: go ahead with whatever conventions you want to enforce
and the community will step up -- or just applaud :)

PS: Actually, being part of Org core sometimes slow down things,
because substantial contributions then need to come from people
who assign their copyright to the Free Software Foundation.

-- 
 Bastien

Re: org-contacts development

[Rasmus]

Bastien <bzg@gnu.org> writes:

> PS: Actually, being part of Org core sometimes slow down things,
> because substantial contributions then need to come from people
> who assign their copyright to the Free Software Foundation.

PPS: This is a feature.

-- 
ツ

Re: org-contacts development

[Alexis]

Bastien <bzg@gnu.org> writes:

> Improving org-contacts.el and making it part of Org core are two
> separate issues -- not everything that is part of Org core gets a
> lot of attention, and some contributed packages do.

Oh okay, fair enough!

> I'd say: go ahead with whatever conventions you want to enforce
> and the community will step up -- or just applaud :)

Heh, okay. :-)

> PS: Actually, being part of Org core sometimes slow down things,
> because substantial contributions then need to come from people
> who assign their copyright to the Free Software Foundation.

*nod* Good point .... i'd be happy to assign copyright to the FSF,
myself, but i know that doing so is an issue for many people.


Alexis.

Re: org-contacts development

[Bastien]

Alexis <flexibeast@gmail.com> writes:

> *nod* Good point .... i'd be happy to assign copyright to the FSF,
> myself, but i know that doing so is an issue for many people.

Here you go!

http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt

:)

-- 
 Bastien

Re: org-contacts development

[Alexis]

Bastien <bzg@gnu.org> writes:

> Alexis <flexibeast@gmail.com> writes:
>
>> *nod* Good point .... i'd be happy to assign copyright to the FSF,
>> myself, but i know that doing so is an issue for many people.
>
> Here you go!
>
> http://orgmode.org/cgit.cgi/org-mode.git/plain/request-assign-future.txt
>
> :)

Heh, thank you! i'll definitely make sure to complete that form and send
it in. :-)


Alexis.

Org-contacts standardization (was: org-contacts development)

[Karl Voit]

Hi Alexis!

* Alexis <flexibeast@gmail.com> wrote:
>
> Hi all,
>
> i use org-contacts as my primary system for contact
> management. Consequently, i'd love to be able to make use of my
> org-contacts data on my Android phone.

Agreed!

> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of the
> properties:
>
> #+PROPERTY: LANDLINE
> #+PROPERTY: MOBILE
> #+PROPERTY: POST
> #+PROPERTY: RESIDENCE
>
> A search of this list's archives for references to 'org-contacts':
>
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-contacts&submit=Search!&idxname=emacs-orgmode&max=20&result=normal&sort=date%3Alate
>
> suggests that org-contacts is something people are using heavily enough
> that they're writing code, ad-hoc, to provide functionality they
> require, e.g.
>
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00869.html

And I also posted a suggestion how to name properties:
https://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00144.html
... which was meanwhile extended by me to:

,----[ my current yasnippet template for contacts ]
| # name : Org-contacts template for a person
| # --
| ** $1 $2  :$1$2:
| :PROPERTIES:
| :TYPE: ${3:$$(yas/choose-value '("person" "company"))}
| :TITLE:
| :EMAIL: $4
| :URL:
| :MOBILE: 0043/
| :HOMEPHONE:
| :WORKPHONE:
| :PHONE:
| :COMPANY:
| :STREET:
| :POSTALCODE:
| :CITY:
| :COUNTRY: Österreich
| :PHOTOGRAPH: [[photo:$1$2.jpg]]
| :BORN:
| :ITOLDTHEM_EMAIL:
| :ITOLDTHEM_ADDRESS:
| :ITOLDTHEM_PHONE:
| :ADDRESS_CHANGE_METHOD:
| :END:
|
| - first contact: $0
`----

I invested quite some time to come up with this approach. For
example, I am generating my procmail filter by scanning all :EMAIL:
entries and :ITOLDTHEM_EMAIL: (whitelisting). 

With [1] I convert my contacts.org to the VCard format for Android
4.4. I did this using Python because I wanted full control to filter
out (most) data and also to provide a sanity check on all entries
(mistyped email address format, mistyped property names, ...).

However, I currently do have an issue here where only few items do not
get imported on Android. I did not have time to nail down the issue
any further yet since there was no obvious common pattern to
identify missing contacts and Android does not throw any error at
all.

> i'm wondering if it might now be appropriate for org-contacts to become
> part of org-mode proper, rather than simply a contrib, to reduce
> unnecessary duplication of efforts. i suspect that, at the moment, a
> number of people interested in making use of org-contacts might be
> reluctant to do so (or do so more heavily) because it's not an
> 'official' part of org-mode. Yet contacts management seems to me to be
> functionality well within org-mode's remit.

In my opinion, the most important first step would be to standardize
all important property names or enhance any kind of mapping scheme.

  1. https://github.com/novoid/org-contacts2vcard
-- 
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: org-contacts development

[Alexis]

Rasmus <rasmus@gmx.us> writes:

> You could also put yourself a slightly different challenge: map
> between the org-contacts-format and an carddav server that you
> establish as a backend on your phone.  E.g. google contacts is a
> carddav server, I think.
>
> I use DAVdroid for syncing my calendar and my contacts with my
> OwnCloud and it very, very well!  I sync my agenda with my OwnCloud
> using org-caldav, which works great except when you have multiple time
> stamps per heading.  For contacts I tried Asynk to sync my bbdb
> contacts with OwnCloud, but I was using too many fields unknown to it,
> and my contacts got messed up.
>
> Mayhaps you already thought of this approach.  I think it is more
> future-proof.

i wasn't aware of CardDAV - thanks for pointing it out! My thoughts of
how to deal with org-contacts data have indeed been revolving around
vCard though, so this approach looks interesting indeed. :-)


Alexis.

Re: org-contacts development

[Daimrod]

Alexis <flexibeast@gmail.com> writes:

> Hi all,
Hi,

> [snip...]
>
> Fleshing out an extended spec for org-contacts data could be part of the
> process of making org-contacts a first-class citizen of org-mode, and
> provide a more solid foundation on which people can build (and share)
> the org-contacts functionality they're after. And in my own particular
> case, it would greatly facilitate my work in org-contacts / Android
> Contacts integration. :-)
>
> What do people think?

IMHO, the "problem" with org-contacts isn't that it isn't part of
org-mode, but that its format isn't well defined enough.

Some fields accept only one value, some multiple values, with different
separators, etc... And on top of that, there is no easy way to access
the database (`car', `cadr', `caddr', ...) which makes it difficult to
read and write code.


So, as you said, we would need to define and document a specification
for org-contacts. And we need to be clear from the beginning about
what it can do and what it can not do. For example, it is unlikely
that org-contacts will be a 1:1 mapping with the vCard format in its
current form because vCard properties can have values.

e.g.
PROP1;PROP2=VAL:FOO BAR
      ^^^^^^^^^

And AFAIK we can't do that with org-mode properties.

An approach would be to keep using properties whenever it's possible
to keep the format simple when possible and use subtree instead of
properties when necessary.

e.g.
#+BEGIN_SRC org
  ,* Contact Name
  ,** PHONE
     :PROPERTIES:
     :TYPE:     WORK
     :END:
  - num1
  - num2
#+END_SRC

But then we would need a special property to indicate that a subtree
is a contact and ignore subtree without this property (just like it
does with the EMAIL property ATM).

#+BEGIN_SRC org
  ,* Contact Name
    :PROPERTIES:
    :TYPE:     org-contacts
    :END:

  ,** PHONE
     :PROPERTIES:
     :TYPE:     WORK
     :END:
  - num1
  - num2
#+END_SRC

And of course it would be nice if we could keep as much compatibility
with the current format :)

-- 
Daimrod/Greg

Re: org-contacts development

[Alexis]

Daimrod <daimrod@gmail.com> writes:

> So, as you said, we would need to define and document a specification
> for org-contacts. And we need to be clear from the beginning about
> what it can do and what it can not do. For example, it is unlikely
> that org-contacts will be a 1:1 mapping with the vCard format in its
> current form because vCard properties can have values.
>
> e.g.
> PROP1;PROP2=VAL:FOO BAR
>       ^^^^^^^^^

Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which
is how my Android phone vCard-exports a mobile number) to
e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like
e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just
brainstorming, however. :-)

> An approach would be to keep using properties whenever it's possible
> to keep the format simple when possible and use subtree instead of
> properties when necessary.
>
> e.g.
> #+BEGIN_SRC org
>   ,* Contact Name
>   ,** PHONE
>      :PROPERTIES:
>      :TYPE:     WORK
>      :END:
>   - num1
>   - num2
> #+END_SRC
>
> But then we would need a special property to indicate that a subtree
> is a contact and ignore subtree without this property (just like it
> does with the EMAIL property ATM).
>
> #+BEGIN_SRC org
>   ,* Contact Name
>     :PROPERTIES:
>     :TYPE:     org-contacts
>     :END:
>
>   ,** PHONE
>      :PROPERTIES:
>      :TYPE:     WORK
>      :END:
>   - num1
>   - num2
> #+END_SRC
>
> And of course it would be nice if we could keep as much compatibility
> with the current format :)

Well, to me this looks broadly similar to what Esben has proposed:

https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html

Although i like the idea of such a format in principle, my concern (as i
noted in my reply to Esben) is that this might require a substantial
modification of org-contacts.el, both to accommodate this format and to
ensure backwards-compatibility. If this is indeed the case, and someone
else is willing to commit to being the lead on undertaking that work,
then i'll certainly support that work and write relevant MobileOrg code
to work with both the new and old formats. Otherwise, from my
perspective of wanting to simply add some more fields and be able to
transfer contact details between MobileOrg and my phone's Contacts
system, it's more than i'm willing to take on at this point.


Alexis.

Re: org-contacts development

[Daimrod]

[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]

Alexis <flexibeast@gmail.com> writes:

> Daimrod <daimrod@gmail.com> writes:
>
>> So, as you said, we would need to define and document a specification
>> for org-contacts. And we need to be clear from the beginning about
>> what it can do and what it can not do. For example, it is unlikely
>> that org-contacts will be a 1:1 mapping with the vCard format in its
>> current form because vCard properties can have values.
>>
>> e.g.
>> PROP1;PROP2=VAL:FOO BAR
>>       ^^^^^^^^^
>
> Agreed. But it seem to me we could at least map e.g. "TEL;CELL:" (which
> is how my Android phone vCard-exports a mobile number) to
> e.g. ":MOBILE:" or ":PHONE_CELL:". And we could map things like
> e.g. "EMAIL;TYPE=work:" to e.g. ":EMAIL_WORK:". This is just
> brainstorming, however. :-)

Sure, but then how would we define the map? with a fixed set of rules?
with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL")
("EMAIL_WORK" -> "EMAIL;TYPE=work")))?

I'm not saying that it's impossible nor that we shouldn't do it but that
we need to think about it first. :)

>> An approach would be to keep using properties whenever it's possible
>> to keep the format simple when possible and use subtree instead of
>> properties when necessary.
>>
>> e.g.
>> #+BEGIN_SRC org
>>   ,* Contact Name
>>   ,** PHONE
>>      :PROPERTIES:
>>      :TYPE:     WORK
>>      :END:
>>   - num1
>>   - num2
>> #+END_SRC
>>
>> But then we would need a special property to indicate that a subtree
>> is a contact and ignore subtree without this property (just like it
>> does with the EMAIL property ATM).
>>
>> #+BEGIN_SRC org
>>   ,* Contact Name
>>     :PROPERTIES:
>>     :TYPE:     org-contacts
>>     :END:
>>
>>   ,** PHONE
>>      :PROPERTIES:
>>      :TYPE:     WORK
>>      :END:
>>   - num1
>>   - num2
>> #+END_SRC
>>
>> And of course it would be nice if we could keep as much compatibility
>> with the current format :)
>
> Well, to me this looks broadly similar to what Esben has proposed:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2014-05/msg01055.html
>
> Although i like the idea of such a format in principle, my concern (as i
> noted in my reply to Esben) is that this might require a substantial
> modification of org-contacts.el, both to accommodate this format and to
> ensure backwards-compatibility. If this is indeed the case, and someone
> else is willing to commit to being the lead on undertaking that work,
> then i'll certainly support that work and write relevant MobileOrg code
> to work with both the new and old formats. Otherwise, from my
> perspective of wanting to simply add some more fields and be able to
> transfer contact details between MobileOrg and my phone's Contacts
> system, it's more than i'm willing to take on at this point.

Well, if people are willing to help, I'll see if I can come up with a
proposal.

-- 
Daimrod/Greg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: org-contacts development

[Alexis]

Daimrod <daimrod@gmail.com> writes:

> Sure, but then how would we define the map? with a fixed set of rules?
> with a user customizable map (e.g. '(("MOBILE" -> "TELL;CELL")
> ("EMAIL_WORK" -> "EMAIL;TYPE=work")))?

More the latter. My initial (again, brainstorming!) thinking has an
user-modifiable data structure along the lines of the following:

+-----------------------------------+------------+--------------------+
| elisp var                         |org property| ~ vCard equivalent |
+-----------------------------------+------------+--------------------+
| org-contacts-email-work-property  |EMAIL_WORK  |EMAIL;TYPE=work     |
| org-contacts-mobile-work-property |MOBILE_WORK |TEL;CELL;TYPE=work  |
+-----------------------------------+------------+--------------------+

English-language properties for the org property column could be
provided by default, but users who wanted to use non-English property
names could do so by modifying the relevant entries.

> I'm not saying that it's impossible nor that we shouldn't do it but that
> we need to think about it first. :)

Oh 100% agreed! That's why i've started this discussion here, so as to
get input, feedback, and hopefully at least rough consensus, on how to
approach all this. :-)

> Well, if people are willing to help, I'll see if I can come up with a
> proposal.

:-) Sounds good!


Alexis.

Re: org-contacts development

[Michael Strey]

On 2014-05-23, Alexis wrote:

> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of the
> properties:
>
> #+PROPERTY: LANDLINE
> #+PROPERTY: MOBILE
> #+PROPERTY: POST
> #+PROPERTY: RESIDENCE

I have been following a VCard-like naming scheme for org-contacts
properties for a longer time. 

see
https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg01224.html

Recently, because of the lack of support for properties in MobileOrg and
the lost support for links in properties, I finally decided to export my
contact data to Google Contacts and -- just in order to try it -- to
BBDB.  I accomplished this by creating a table with org-collector and
exporting it to CSV that can be imported by Google Contacts and BBDB.

Therefore I had to change the naming scheme.  It is now similar to that
of Google Contacts.

Here is the appropriate code:

#+BEGIN_SRC org
# -*- mode: org; org-cycle-hook: (org-cycle-hide-archived-subtrees org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) -*-
* Contacts
:PROPERTIES:
:CATEGORY: Contacts
:ID: 39584cda-bff0-4b8a-9460-4fefb5b5922c
:END:
** A - Contacts                                                     :CONTACT:
:PROPERTIES:
:CATEGORY: Contacts
:END:
*** Actia Sodielec                              :DAB:DVB:EMPFÄNGER:noexport:
:PROPERTIES:
:KIND:     org
:Organization 1 - Name: Actia Sodielec
:Address 1 - Type: Work
:Address 1 - Street: 
:Address 1 - PO Box: Site Aveyron
:Address 1 - Extended Address: BP-9 Route de Mayres
:Address 1 - City: Saint Georges de Luzen\c{c}on
:Address 1 - Region: 
:Address 1 - Postal Code: 12100
:Address 1 - Country: France
:Phone 1 - Type: Work
:Phone 1 - Value: +33 565 623740
:Phone 2 - Type: Fax
:Phone 2 - Value: +33 565 623070
:Website 1 - Type: Work
:Website 1 - Value: http://www.actiasodielec.fr
:LANG:     en
:END:

Saint Georges de Luzenḉon

**** Carsac, Sara
:PROPERTIES:
:KIND:     individual
:Organization 1 - Name: Actia Sodielec
:Organization 1 - Department: Broadcast, Rail & Transport (BTF)
:Organization 1 - Title: Responsable Commercial, Sales Manager
:FN:       Sara Carsac
:Family Name: Carsac
:Given Name: Sara
:Nickname: Dear Sara
:EMAIL: s.carsac@actiasodielec.fr
:Phone 1 - Type: Work
:Phone 1 - Value: +33 618 12345
:Phone 3 - Type: Mobile
:Phone 3 - Value: +33 668 12345
:Phone 2 - Type: Fax
:Phone 2 - Value: +33 565 12345
:Website 1 - Type: Work
:Website 1 - Value: http://actiasodielec.fr
:LANG:     en
:END:

** B - Contacts                                                     :CONTACT:
:PROPERTIES:
:CATEGORY: Contacts
:END:
*** BTI Technologieagentur Dresden GmbH                              :ADMIN:

**** Naumann, Michael
:PROPERTIES:
:KIND:     individual
:Organization 1 - Name: BTI Technologieagentur Dresden GmbH
:Organization 1 - Department: EU Forschung und Technologie
:FN:       Michael  Naumann
:Family Name: Naumann
:Given Name: Michael
:Nickname: Sehr geehrter Herr Naumann
:Address 1 - Type: Work
:Address 1 - Street: Gostritzer Str. 61-63
:Address 1 - PO Box: 
:Address 1 - Extended Address: 
:Address 1 - City: Dresden
:Address 1 - Region: 
:Address 1 - Postal Code: DE-01217
:Address 1 - Country: Germany
:EMAIL: eu-forschung@bti-dresden.de
:Phone 1 - Type: Work
:Phone 1 - Value: +49 351 871 7560
:Website 1 - Type: Work
:Website 1 - Value: http://www.bti-dresden.de
:LANG:     de
:END:

* Export

** Export for Google Contacts
- C-c C-c on line #+BEGIN: updates the table
- place cursor within the table
- M-x org-table-export

#+BEGIN: propview :id "39584cda-bff0-4b8a-9460-4fefb5b5922c" :cols (Given\ Name Family\ Name ITEM Name\ Prefix Name\ Suffix Nickname EMAIL Phone\ 1\ -\ Type Phone\ 1\ -\ Value Phone\ 2\ -\ Type Phone\ 2\ -\ Value Phone\ 3\ -\ Type Phone\ 3\ -\ Value Phone\ 4\ -\ Type Phone\ 4\ -\ Value Address\ 1\ -\ Type Address\ 1\ -\ Street Address\ 1\ -\ PO\ Box Address\ 1\ -\ Extended\ Address Address\ 1\ -\ City Address\ 1\ -\ Region Address\ 1\ -\ Postal\ Code Address\ 1\ -\ Country Address\ 2\ -\ Type Address\ 2\ -\ Street Address\ 2\ -\ PO\ Box Address\ 2\ -\ Extended\ Address Address\ 2\ -\ City Address\ 2\ -\ Region Address\ 2\ -\ Postal\ Code Address\ 2\ -\ Country Address\ 3\ -\ Type Address\ 3\ -\ Street Address\ 3\ -\ PO\ Box Address\ 3\ -\ Extended\ Address Address\ 3\ -\ City Address\ 3\ -\ Region Address\ 3\ -\ Postal\ Code Address\ 3\ -\ Country Organization\ 1\ -\ Name Birthday Organization\ 1\ -\ Title Organization\ 1\ -\ Department Website\ 1\ -\ Type Website\ 1\ -\ Value LANG TAGS) :colnames ("Given Name" "Family Name" "Name" "Name Prefix" "Name Suffix" "Nickname" "E-mail 1 - Value" "Phone 1 - Type" "Phone 1 - Value" "Phone 2 - Type" "Phone 2 - Value" "Phone 3 - Type" "Phone 3 - Value" "Phone 4 - Type" "Phone 4 - Value" "Address 1 - Type" "Address 1 - Street" "Address 1 - PO Box" "Address 1 - Extended Address" "Address 1 - City" "Address 1 - Region" "Address 1 - Postal Code" "Address 1 - Country" "Address 2 - Type" "Address 2 - Street" "Address 2 - PO Box" "Address 2 - Extended Address" "Address 2 - City" "Address 2 - Region" "Address 2 - Postal Code" "Address 2 - Country" "Address 3 - Type" "Address 3 - Street" "Address 3 - PO Box" "Address 3 - Extended Address" "Address 3 - City" "Address 3 - Region" "Address 3 - Postal Code" "Address 3 - Country" "Organization 1 - Name" "Birthday" "Oganization 1 - Title" "Organization 1 - Department" "Website 1 - Type" "Website 1 - Value" "Language" "org-tags") :defaultval "" :inherit (TAGS) :conds ((stringp KIND)) :match "-ARCHIVE" :noquote t

#+END_SRC

-- 
Michael Strey
mailto:mstrey@strey.biz
http://www.strey.biz

Re: org-contacts development

[Michael Strey]

Reading http://orgmode.org/worg/dev/org-syntax.html#Node_Properties
I just realised that my clumsy property keys are against the rules since
they are containing whitespace characters.

Nevertheless I still like the idea of having a Type, a number and a
Value for every property that can occur multiple.  Thus the properties
can be easily mapped to the VCard scheme as well as to any other scheme.

Thus, what I would like to propose is the following scheme:

#+BEGIN_SRC org
:PROPERTIES:
:Contact_Type:     individual or organisation
:Organization_1_Type: company
:Organization_1_Name: The company name
:Organization_1_Department: department, business unit, division
:Organization_1_Title: job title of an individual
:FN: The full name
:GivenName:
:FamilyName:
:Name_Prefix:
:Name_Suffix:
:Nickname:
:Email_1_Type: Work
:Email_1_Value: name@company.fr
:Address_1_Type: Work
:Address_1_Street: The street can contain multiple lines \\ second line
:Address_1_Box: Postal box
:Address_1_Extension: other extensions that can occur in addresses
:Address_1_City: The city
:Address_1_Region: Region, federal state etc.
:Address_1_Code: 12100
:Address_1_Country: France
:Phone_1_Type: Work
:Phone_1_Value: +33 565 623740
:Phone_2_Type: Fax
:Phone_2_Value: +33 565 623070
:Website_1_Type: Work
:Website_1_Value: http://www.domain.fr
:Birthday:
:Language:     en
:Salutation:
:END:
#+END_SRC

Other user defined properties can be added and mapped to the appropriate
user defined keys during export.


Further remarks regarding my last e-mail:

> #+BEGIN: propview :id "39584cda-bff0-4b8a-9460-4fefb5b5922c" :cols (Given\ Name Family\ Name ITEM Name\ Prefix Name\ Suffix Nickname EMAIL Phone\ 1\ -\ Type Phone\ 1\ -\ Value Phone\ 2\ -\ Type Phone\ 2\ -\ Value Phone\ 3\ -\ Type Phone\ 3\ -\ Value Phone\ 4\ -\ Type Phone\ 4\ -\ Value Address\ 1\ -\ Type Address\ 1\ -\ Street Address\ 1\ -\ PO\ Box Address\ 1\ -\ Extended\ Address Address\ 1\ -\ City Address\ 1\ -\ Region Address\ 1\ -\ Postal\ Code Address\ 1\ -\ Country Address\ 2\ -\ Type Address\ 2\ -\ Street Address\ 2\ -\ PO\ Box Address\ 2\ -\ Extended\ Address Address\ 2\ -\ City Address\ 2\ -\ Region Address\ 2\ -\ Postal\ Code Address\ 2\ -\ Country Address\ 3\ -\ Type Address\ 3\ -\ Street Address\ 3\ -\ PO\ Box Address\ 3\ -\ Extended\ Address Address\ 3\ -\ City Address\ 3\ -\ Region Address\ 3\ -\ Postal\ Code Address\ 3\ -\ Country Organization\ 1\ -\ Name Birthday Organization\ 1\ -\ Title Organization\ 1\ -\ Department Website\ 1\ -\ Type Website\ 1\ -\ Value LANG TAGS) :colnames ("Given Name" "Family Name" "Name" "Name Prefix" "Name Suffix" "Nickname" "E-mail 1 - Value" "Phone 1 - Type" "Phone 1 - Value" "Phone 2 - Type" "Phone 2 - Value" "Phone 3 - Type" "Phone 3 - Value" "Phone 4 - Type" "Phone 4 - Value" "Address 1 - Type" "Address 1 - Street" "Address 1 - PO Box" "Address 1 - Extended Address" "Address 1 - City" "Address 1 - Region" "Address 1 - Postal Code" "Address 1 - Country" "Address 2 - Type" "Address 2 - Street" "Address 2 - PO Box" "Address 2 - Extended Address" "Address 2 - City" "Address 2 - Region" "Address 2 - Postal Code" "Address 2 - Country" "Address 3 - Type" "Address 3 - Street" "Address 3 - PO Box" "Address 3 - Extended Address" "Address 3 - City" "Address 3 - Region" "Address 3 - Postal Code" "Address 3 - Country" "Organization 1 - Name" "Birthday" "Oganization 1 - Title" "Organization 1 - Department" "Website 1 - Type" "Website 1 - Value" "Language" "org-tags") :defaultval "" :inherit (TAGS) :conds ((stringp KIND)) :match "-ARCHIVE" :noquote t

Here I forgot to copy the #+END: 

Please note that org-collector tries to convert property values from
strings into numbers if possible.  For postal codes with leading Zeros
this can lead to unexpected results.  I did not find any other way to
solve this problem than to add a national code like in the following
example

:Address_1_Code:  01169
would lead to "1169" in the propview table.

so I replaced it with
:Address_1_Code:  DE-01169


-- 
Michael Strey
mailto:mstrey@strey.biz
http://www.strey.biz
https://twitter.com/michaelstrey

Re: org-contacts development

[Daimrod]

Michael Strey <mstrey@strey.biz> writes:
Hi Michael,

> Reading http://orgmode.org/worg/dev/org-syntax.html#Node_Properties
> I just realised that my clumsy property keys are against the rules since
> they are containing whitespace characters.
>
> Nevertheless I still like the idea of having a Type, a number and a
> Value for every property that can occur multiple.  Thus the properties
> can be easily mapped to the VCard scheme as well as to any other scheme.
>
> Thus, what I would like to propose is the following scheme:
>
>
> #+BEGIN_SRC org
> :PROPERTIES:
> :Contact_Type:     individual or organisation
> :Organization_1_Type: company
> :Organization_1_Name: The company name
> :Organization_1_Department: department, business unit, division
> :Organization_1_Title: job title of an individual
> :FN: The full name
> :GivenName:
> :FamilyName:
> :Name_Prefix:
> :Name_Suffix:
> :Nickname:
> :Email_1_Type: Work
> :Email_1_Value: name@company.fr
> :Address_1_Type: Work
> :Address_1_Street: The street can contain multiple lines \\ second line
> :Address_1_Box: Postal box
> :Address_1_Extension: other extensions that can occur in addresses
> :Address_1_City: The city
> :Address_1_Region: Region, federal state etc.
> :Address_1_Code: 12100
> :Address_1_Country: France
> :Phone_1_Type: Work
> :Phone_1_Value: +33 565 623740
> :Phone_2_Type: Fax
> :Phone_2_Value: +33 565 623070
> :Website_1_Type: Work
> :Website_1_Value: http://www.domain.fr
> :Birthday:
> :Language:     en
> :Salutation:
> :END:
> #+END_SRC
>

Hmm, I kinda like this. It seems a bit verbose but it's better than
having multiple values per properties (IMHO).

Though, if we adopt this scheme, we would need to add some helper
bindings/functions so that we don't have to fill this by hands.

> Other user defined properties can be added and mapped to the appropriate
> user defined keys during export.

I'm not sure to understand what you mean. Could you give more details
and maybe an example?

>
> [snip]
>
> Please note that org-collector tries to convert property values from
> strings into numbers if possible.  For postal codes with leading Zeros
> this can lead to unexpected results.  I did not find any other way to
> solve this problem than to add a national code like in the following
> example
>
> :Address_1_Code:  01169
> would lead to "1169" in the propview table.
>
> so I replaced it with
> :Address_1_Code:  DE-01169

What is `org-collector' and when does it happen?

I've done a quick test and the 0 appears in `org-contacts-db'.

Best,

-- 
Daimrod/Greg

Re: org-contacts development

[Michael Strey]

[-- Attachment #1: Type: text/plain, Size: 3708 bytes --]

Hi Daimrod,

On 2014-05-29, Daimrod wrote:

> Hmm, I kinda like this. It seems a bit verbose but it's better than
> having multiple values per properties (IMHO).
>
> Though, if we adopt this scheme, we would need to add some helper
> bindings/functions so that we don't have to fill this by hands.

I'm using yasnippets and have snippets for organizations, job-related
contacts and private contacts.

I have attached them.

C-c C-x p helps to fill in optional properties.

I have all my contacts in one buffer with the following settings

#+BEGIN_SRC org
* Buffer settings
#+STARTUP: overview
#+STARTUP: hidestars
#+STARTUP: indent
#+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s) 
#+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFÄNGER(m) HOCHSCHULE(h) NETZBETREIBER(n) SYSTEM(y) B2B B2C REG
#+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR
#+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN
#+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c)
#+PROPERTY: Contact_Type_ALL individual organization
#+PROPERTY: Language_ALL de en ru
#+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile
#+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile
#+PROPERTY: Address_1_Type_ALL Work Home Post
#+PROPERTY: Address_2_Type_ALL Work Home Post
#+PROPERTY: Address_3_Type_ALL Work Home Post
#+PROPERTY: Website_1_Type_ALL Work Home
#+PROPERTY: Website_2_Type_ALL Work Home
#+END_SRC


>> Other user defined properties can be added and mapped to the appropriate
>> user defined keys during export.
>
> I'm not sure to understand what you mean. Could you give more details
> and maybe an example?

Actually, my statement was trivial.  Orgmode allows to define and add
every kind of additional properties.  What I wanted to say was that it
is possible to export those additional properties to Google Contacts as
well.

I have for instance the property :Language: that is not part of the
Google API.  I use it to store the preferred language of correspondence
for my job-related contacts for mailing actions.

Google Contacts accepts such fields in the CSV file to import and
creates user defined fields from them.


>> Please note that org-collector tries to convert property values from
>> strings into numbers if possible.  For postal codes with leading Zeros
>> this can lead to unexpected results.  I did not find any other way to
>> solve this problem than to add a national code like in the following
>> example
>>
>> :Address_1_Code:  01169
>> would lead to "1169" in the propview table.
>>
>> so I replaced it with
>> :Address_1_Code:  DE-01169
>
> What is `org-collector' and when does it happen?

From the Orgmode manual:

"An alternative way to capture and process property values into a table
is provided by Eric Schulte's org-collector.el which is a contributed
package.  It provides a general API to collect properties from entries
in a certain scope, and arbitrary Lisp expressions to process these
values before inserting them into a table or a dynamic block."

I'm using org-collector to create a table that can be exported to CSV
for import into Google Contacts (and maybe other contact managers).

> I've done a quick test and the 0 appears in `org-contacts-db'.

Yes, everything is fine with org-contacts.  The problem comes only from
org-collector.  The reason is org-collector's feature to allow Lisp
expressions to process property values.  Therefore it uses the function
`org-babel-read' that detects Lisp expressions and converts strings into
numbers.

So this remark is only relevant for those who want to follow my track with the
org-collector export.

-- 
Michael Strey 
www.strey.biz


[-- Attachment #2: Job-related contact --]
[-- Type: text/plain, Size: 1022 bytes --]

#name : Contact Individual
#key : contact
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
**** ${1:surname}, ${2:name}
:LOGBOOK:
- Contact added: [`(org-read-date nil nil "+0d")`]
:END:

:PROPERTIES:
:Contact_Type: individual
:Organization_1_Type: company
:Organization_1_Value: ${3:organisation}
:Organization_1_Department: ${4:devision}
:Organization_1_Title: ${5:title}
:FN: $2 $1
:Given_Name: $2
:Family_Name: $1
:Nickname: $19 $1
:Address_1_Type: Work
:Address_1_Street: ${6:adr1}
:Address_1_Box: ${7:adr2}
:Address_1_Extension: ${8:adr3}
:Address_1_City: ${9:city}
:Address_1_Region: ${10:state} 
:Address_1_Code: ${11:zip_code}
:Address_1_Country: ${12:country}
:Email_1_Type: Work
:Email_1_Value: ${13:company_email}
:Phone_1_Type: Work
:Phone_1_Value: ${14:tel}
:Phone_2_Type: Mobile
:Phone_2_Value: ${15:mobile}
:Phone_3_Type: Fax
:Phone_3_Value: ${16:fax}
:Website_1_Type: Work
:Website_1_Value: http://$17
:Language:     $18
:END:
$0

[-- Attachment #3: Private contact --]
[-- Type: text/plain, Size: 815 bytes --]

#name : Contact Individual (private)
#key : privat
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
**** ${1:surname}, ${2:name}   :NEW:
:LOGBOOK:
- Contact added: [`(org-read-date nil nil "+0d")`]
:END:
:PROPERTIES:
:Contact_Type: individual
:FN: $2 $1
:Family_Name: $1
:Given_Name: $2
:Name_Prefix: 
:Name_Suffix: 
:Nickname: ${3:salutation}
:Address_1_Type: Home
:Address_1_Street: ${4:street}
:Address_1_Box: 
:Address_1_Extension: 
:Address_1_City: ${5:Dresden}
:Address_1_Region: ${6:Sachsen}
:Address_1_Code: DE-${7:zip_code}
:Address_1_Country: ${8:Deutschland}
:Email_1_Type: Home
:Email_1_Value: ${9:email}
:Phone_1_Type: Home
:Phone_1_Value: ${10:tel}
:Phone_2_Type: Mobile
:Phone_2_Value: ${11:tel}
:Language: ${12:de}
:END:
$0

[-- Attachment #4: Organization --]
[-- Type: text/plain, Size: 827 bytes --]

#name : Contact Organisation
#key : org
#contributor : Michael Strey <[EMAIL PROTECTED]>
#expand-env: ((yas/indent-line 'fixed) (yas/wrap-around-region 'nil))
# --
*** ${1:organisation}    :NEW:
:LOGBOOK:
- Organization added: [`(org-read-date nil nil "+0d")`]
:END:
:PROPERTIES:
:Contact_Type: organization
:Organization_1_Name: $1
:Organization_1_Department: ${2:devision}
:Address_1_Type: Work
:Address_1_Street: ${3:adr1}
:Address_1_Box: ${4:adr2}
:Address_1_Extension: ${5:adr3}
:Address_1_City: ${6:city}
:Address_1_Region: ${7:state}
:Address_1_Code: ${8:zip_code}
:Address_1_Country: ${9:country}
:Email_1_Type: Work
:Email_1_Value: ${10:company_email}
:Phone_1_Type: Work
:Phone_1_Value: ${11:tel}
:Phone_2_Type: Fax
:Phone_2_Value: ${12:tel}
:Website_1_Type: Work
:Website_1_Value: http://$13
:Language: $14
:END:
$0

Re: org-contacts development

[Daimrod]

Michael Strey <mstrey@strey.biz> writes:

> Hi Daimrod,
>
> On 2014-05-29, Daimrod wrote:
>
>> Hmm, I kinda like this. It seems a bit verbose but it's better than
>> having multiple values per properties (IMHO).
>>
>> Though, if we adopt this scheme, we would need to add some helper
>> bindings/functions so that we don't have to fill this by hands.
>
> I'm using yasnippets and have snippets for organizations, job-related
> contacts and private contacts.
>
> I have attached them.

Thank you!

> C-c C-x p helps to fill in optional properties.
>
> I have all my contacts in one buffer with the following settings
>
>
> #+BEGIN_SRC org
> * Buffer settings
> #+STARTUP: overview
> #+STARTUP: hidestars
> #+STARTUP: indent
> #+TAGS: ADMIN(i) CHEF(f) EINKAUF(k) PRIVAT(t) SEKRETARIAT(s) 
> #+TAGS: AUTO(u) BROADCASTER(b) DAB(d) DVB(v) EMPFNGER(m) HOCHSCHULE(h) NETZBETREIBER(n) SYSTEM(y) B2B B2C REG
> #+TAGS: MAIL(l) PRESSE(e) KUNDE COMPETITOR
> #+TAGS: ABI CI FAMILIE FREUNDE SCHULE TAICHI TURNEN
> #+SEQ_TODO: TODO(t) NEXT(n) WAITING(w) | DONE(d) CANCELLED(c)
> #+PROPERTY: Contact_Type_ALL individual organization
> #+PROPERTY: Language_ALL de en ru
> #+PROPERTY: Phone_1_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Phone_2_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Phone_3_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Phone_4_Type_ALL Work Home Fax Mobile
> #+PROPERTY: Address_1_Type_ALL Work Home Post
> #+PROPERTY: Address_2_Type_ALL Work Home Post
> #+PROPERTY: Address_3_Type_ALL Work Home Post
> #+PROPERTY: Website_1_Type_ALL Work Home
> #+PROPERTY: Website_2_Type_ALL Work Home
> #+END_SRC
>
>
>
>>> Other user defined properties can be added and mapped to the appropriate
>>> user defined keys during export.
>>
>> I'm not sure to understand what you mean. Could you give more details
>> and maybe an example?
>
> Actually, my statement was trivial.  Orgmode allows to define and add
> every kind of additional properties.  What I wanted to say was that it
> is possible to export those additional properties to Google Contacts as
> well.

Ok.

> I have for instance the property :Language: that is not part of the
> Google API.  I use it to store the preferred language of correspondence
> for my job-related contacts for mailing actions.
>
> Google Contacts accepts such fields in the CSV file to import and
> creates user defined fields from them.
>
>
>>> Please note that org-collector tries to convert property values from
>>> strings into numbers if possible.  For postal codes with leading Zeros
>>> this can lead to unexpected results.  I did not find any other way to
>>> solve this problem than to add a national code like in the following
>>> example
>>>
>>> :Address_1_Code:  01169
>>> would lead to "1169" in the propview table.
>>>
>>> so I replaced it with
>>> :Address_1_Code:  DE-01169
>>
>> What is `org-collector' and when does it happen?
>
> From the Orgmode manual:
>
> "An alternative way to capture and process property values into a table
> is provided by Eric Schulte's org-collector.el which is a contributed
> package.  It provides a general API to collect properties from entries
> in a certain scope, and arbitrary Lisp expressions to process these
> values before inserting them into a table or a dynamic block."
>
> I'm using org-collector to create a table that can be exported to CSV
> for import into Google Contacts (and maybe other contact managers).

Ok, I wasn't aware of this.

>> I've done a quick test and the 0 appears in `org-contacts-db'.
>
> Yes, everything is fine with org-contacts.  The problem comes only from
> org-collector.  The reason is org-collector's feature to allow Lisp
> expressions to process property values.  Therefore it uses the function
> `org-babel-read' that detects Lisp expressions and converts strings into
> numbers.
>
> So this remark is only relevant for those who want to follow my track with the
> org-collector export.

I see.

Thanks for you detailed explanation, I'll look at it more carefully this
weekend (hopefully).

Best,

-- 
Daimrod/Greg

Re: org-contacts development

[Karl Voit]

* Alexis <flexibeast@gmail.com> wrote:
>
> Hi all,

Hi!

> What would be useful would be an 'official', fleshed-out spec for
> org-contacts data, which handles a greater range of contact-related
> info. At the moment, for example, my org-contacts file makes use of the
> properties:
>
> #+PROPERTY: LANDLINE
> #+PROPERTY: MOBILE
> #+PROPERTY: POST
> #+PROPERTY: RESIDENCE
>
> A search of this list's archives for references to 'org-contacts':
>
> https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-contacts&submit=Search!&idxname=emacs-orgmode&max=20&result=normal&sort=date%3Alate
>
> suggests that org-contacts is something people are using heavily enough
> that they're writing code, ad-hoc, to provide functionality they
> require, e.g.
>
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-11/msg00869.html

My current solution:
http://article.gmane.org/gmane.emacs.orgmode/57231/ and
http://article.gmane.org/gmane.emacs.orgmode/75346/

> i'm wondering if it might now be appropriate for org-contacts to become
> part of org-mode proper, rather than simply a contrib, to reduce
> unnecessary duplication of efforts. 

Absolutely.

Lacking any standard here, I created my own and meanwhile I do even
generate spam-filters and whitelist items out of my org-contacts
file. Also handy: when I filled out :ITOLDTHEM_EMAIL: my mail client
is using the specified "from"-email-address instead of my normal one
whenever I compose an email to this contact :-)

> Fleshing out an extended spec for org-contacts data could be part of the
> process of making org-contacts a first-class citizen of org-mode, and
> provide a more solid foundation on which people can build (and share)
> the org-contacts functionality they're after. And in my own particular
> case, it would greatly facilitate my work in org-contacts / Android
> Contacts integration. :-)
>
> What do people think?

Absolutely! I copy that.

My current yasnippet for a contact:

,----
| # name : Org-contacts template for a person
| # --
| ** $1 $2  :$1$2:
| :PROPERTIES:
| :TYPE: ${3:$$(yas/choose-value '("person" "company"))}
| :TITLE:
| :EMAIL: $4
| :URL:
| :MOBILE: 0043/
| :HOMEPHONE:
| :WORKPHONE:
| :PHONE:
| :COMPANY:
| :STREET:
| :POSTALCODE:
| :CITY:
| :COUNTRY: Österreich
| :PHOTOGRAPH: [[photo:$1$2.jpg]]
| :BORN:
| :ITOLDTHEM_EMAIL:
| :ITOLDTHEM_ADDRESS:
| :ITOLDTHEM_PHONE:
| :ADDRESS_CHANGE_METHOD:
| :END:
|
| - first met at: $0
`----

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