>On Sun, 2009-10-11 at 23:52 -0430, Patrick O'Callaghan wrote: >> On Sun, 2009-10-11 at 20:46 +0200, Lars Schade wrote: >> > To illustrate the issue I start with a local addressbook and add a new >> > contact using the evolution GUI say for the Berlin Office of a company >> > called "The Big Wheel", and I fill in the name dialog as given name >> > "Berlin Office" and as family name "The Big Wheel". It is displayed as >> > "The Big Wheel, Berlin Office" exactly what I want. I can use the this >> > information to automatically generate address labels with openoffice, >> > everything perfect. >> I'm not very knowledgable about LDAP, but it looks to me like you're >> using it incorrectly. Using the Name subfields (First, Middle, Last, >> Suffix) to stand for Office/Company is bound to lead to trouble, if not >> within Evo then elsewhere you might want to use LDAP records. The field >> names are there for a reason and some apps attach semantic meaning to >> them. For example a Name with a space in it can legitimately be >> interpreted as two names, where the second one can be represented by an >> initial. This makes perfect sense for given names and makes no sense for >> the name of a company. >> You should reconsider how you're using LDAP. The key thing to remember >> is that a "contact" is meant to represent a person, not a company. > > All this is true - as a user you are over a barrel however. I spend a > ot of time working with vCard data - to be blunt: the vCard (RFC2426) > spec is lame. But it is everywhere and what we [sadly] have to live > with. A vCard represents a *PERSON*, there isn't any good [or > standard] way to represent an Enterprise (company, organization, ....). > The "FN" is the name of the vCard and corresponds to the "CN" (common > name) attribute in LDAP. That is OK. *BUT* the spec also *requires* > "N" which is a composite value of "Family Name, Given Name, Additional > Names, Honorific Prefixes, and Honorific Suffixes" Of course that makes > no sense for a vCard that isn't a contact - but the client *must* shove > something in at least on of those fields. This isn't Evolution's fault > - the spec is retarded. [The required attributes for a vCard are: FN, > N, and VERSION. Many implementations have a tacit requirement for UID > as well]. Evolution's internal data model is [reasonably] based on the > vCard spec as is that of Thunderous Crap, KDE's PIM (is it still called > Kontact?) , as well as most other PIMs. Outlook has the same problem. > You need to use a "real" groupware client to avoid this lameness.
Thanks for the answers, I was afraid the problem was a bit more basic. On the practical side: Is there a workaround you know of? Or how do you handle contacts that are not real persons? On the theoretical side: The problem really only arises, once I switch from a local addressbook to LDAP. There is a basic mismatch between the data model in Evolution and the way data is stored in LDAP. But the problem could be solved by adapting the evolution schema for LDAP in such a way that the different name parts are stored separately rather than being reconstructed from the CN entry in the LDAP database. Or is there any reason not to use separate attributes for all the vCard name components? -lars _______________________________________________ Evolution-list mailing list Evolution-list@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-list
