Subject: Re: Data format integration, was addresses

From: [email-masked] (Fritz Lehmann)
Date: 1 Jul 1995 19:24:47 GMT

I've changed the name of this thread since the issue is universal
for all data types and not just a matter of names and addresses.

     Bernard Peek wrote in comp.databases.theory:
---begin quote---
For the name of individuals I hold:
Title
Firstname
SecondName(s)
Prefix
Lastname
Succession
There's other information I could, even should, hold. I don't send
personalised letters so although I have a field for titles like "Mr.",
"Ms." etc, I have never had to print it. I should also hold data on
academic achievements and honorifics. I don't have a field for "Duke
of xxxxxx" which I should technically include after the name for some
people.
---end quote---

     The key thing for data like this that will have long-term, varied uses
is that this is but one of many legitimate ways of representing the
same (semantic) information.  Other format designers will do it differently.
Even if the syntax is identical, the names and meanings of fields will
not coincide  -- this forever prevents _automated_ integration of
databases, unless the semantics of the fields is represented directly in
the computer.  I've never seen "Succession" in a name field!  I assume it
means (about) what, in my address system, is (with crosslinks in brackets):

   GENERATION-DISTINGUISHER/NUMERATOR (Jr., Sr., III, XI, the Younger)
      [FDEF PLACEHOLDER]
      [EDEF A word or number, occurring immediately after a personal name,
       which indicates which person, among persons of the same name within a
       family, is intended, based on the relative age or temporal order
       of birth of the persons to be distinguished from one another.|FL]
      [USPS.Pub28.92 III C{Suffix Title - Maturity}|FL]
      [X12 1104:10{Generation}|FL]
      [USMARC-B.94 100/400/600/700/800:$b{Numeration}|FL]
      [BrackettB.94 Person Name Extension|FL]
      [WordMenu.92 see: DoFaKiKi312{generation}|FL]
      <values>
      [Laffal.73 SUB YNG, LEAD PAST, NUMR|FL]
      [Roget.4 124.15;1{junior, Jr.}, 127.5;1{senior,Sr.,elder,older}|FL]
      [WordMenu.92 DoFaKiFa313{elder,junior,seniors},
                   DoFaPaNa321{junior,master}|FL] 

     Notice all the different names for this: Generation-distinguisher,
Maturity, Generation, Numeration, Person-Name-Extension, and now
Succession.  These are taken from a US Postal standard, an EDI (Electronic
Data Interchange) standard for commercial transactions, the main library
standard for data on publications, a well-known book on data definition,
two thesauri and one "conceptual dictionary", plus Peek's version.

     There are two distinct issues: 1. What fields to use in
a particular application, and what field names to use.  This will vary, and
properly so.  2. What are all the possible semantic building-blocks which
are likely to be used in an address?  When this is known, and all the
categories are well-defined, then it is possible to _annotate_ any
particular implementation with the semantic classes.  So an application can
note whether "Mr." is included in "name" (some do, some don't include it),
whether the "von" is in a name, whether an Amerindian name like Lone Horse
is to be one surname or two names, etc.  The point here is not to dictate
what to do in an application, but rather to establish the set -- the union --
of all the semantic classes that any application is likely to use.  Then the
syntax specification can specify what classes get mashed together in a field
like "Address2".

    Then, if two applications' formats are properly annotated (their syntax
is specified and the semantics are specified using the "universal" set
of semantic classes), automatic translation from one to the other is
possible, regardless of the field (and code) names used or the syntax
differences.

    Exactly the same problem (and potential solution) exists in the area
of EDI (Electronic Data Interchange) and Electronic Commerce.  For EDI
there is a current effort called the BSR (Basic Semantic Repository)
which is taking the first steps toward the solution in ISO 11179.  In
EDI the "source" application happens to be in a different organization
>from the "target" application, but the principle is the same.  What the
BSR is doing, and what certain groups like CYC, Pangloss, CCAT and others are
doing within Artificial Intelligence, is building an "ontology" of 
commercially relevant concepts in the real world.  That's what is needed
for Semantic Data Integration.

    This is why I have recommended a very detailed breakdown of data
like names, addresses, dates, accounts, etc. -- not to suggest that
anyone will actually want to use all of the detailed categories as fields 
in a particular application.

                               Yours truly,  Fritz Lehmann