Detlev, One small correction; in the report, you said:
"Some newer standards with an address component such as the widely adopted vCard data format [3] do not even attempt to distinguish between address elements." This is not entirely true; although vCard doesn't *require* addresses to be parsed to this level of detail, it does provide the mechanism to do so, in the form of subelements for the Address element: Extended Address Extadd Street Address Street Locality Locality Region Region Postal Code Pcode Country Country See section 3.4: http://www.w3.org/TR/vcard-rdf#3 Cheers, T. ====================================================================== Tony Gill ArtSTOR Director of Metadata, The Andrew W. Mellon Foundation, 140 East 62nd Street, New York, NY, 10021, USA t1 (direct): +1 (646) 274-2265, t2: +1 (212) 838-8400 w: http://www.mellon.org, f: +1 (212) 223-2778 > -----Original Message----- > From: Detlev Balzer [mailto:[email protected]] > Sent: Friday, 13 December, 2002 5:13 PM > To: [email protected] > Subject: [crm-sig] Implementation guideline: Addresses > > > Dear SIG, > > attached is a first draft of a guideline for dealing with addresses > as CRM instances (see issue 65: Implementation guidelines for > compounds). > > Martin noted that a person, corporation, etc., can have many > addresses over time. Should we include some remarks on how to deal > with the volatility (temporality) of addresses? > > Any comments, suggestions, corrections are welcome. > > Detlev > > > > *** eSafe scanned this email for malicious content *** > *** IMPORTANT: Do not open attachments from unrecognized senders *** >
