Skip to end of metadata
Go to start of metadata

The Services Team met on December 3, 2009, with Michael T. Black, Information Systems Manager of the Phoebe A. Hearst Museum of Anthropology (PAHMA) at the University of California, Berkeley. For background on these meetings, please see the Services Team Design Meeting of May 7, 2009.

Key Topics: Feedback on Contact Information Schema

One of the primary topics of this meeting was a discussion of the Contact Information Schema.

Feedback on Contact Information Schema

[PLS]: I added my comments inline below. We need to be very careful to scope this in such a way as to be reasonable for the first release. E.g., we could allow a single unvalidated string for each type of info, and then later go to multiple, with more type/media/use info. We also need to carefully work with the design and UI folks to figure out what can be done when.

Feedback on the Contact Information Schema during this meeting, much of it from Michael Black and Susan Stone, included:

  1. The value of maintaining contact information in a CMS. Michael noted that if CollectionSpace offered sufficiently capable contact information management features, this might literally double the usage of the system at PAHMA. The museum currently has a number of separate, auxiliary contact management systems, whose purposes range from tracking donors to identifying persons who "have an interest in the museum store," some of which might potentially be candidates for migration to CollectionSpace.
  2. Confusion over naming of Person- and Organization-related schemas. There was confusion over how the Contact Information Schema appears to bring together three related schemas, only one of which - the Address Information schema - directly pertains to "contact information" in the most commonly used sense of that term. It might be more conventional and widely-used nomenclature to refer to the Organization Contact Information" schema as simply an "Organization Information" schema, and to the "Person Contact Information" schema as a "Person Information" schema, unless these might need to be differentiated from alternate uses of Person or Organization elsewhere within CollectionSpace schema.
  3. Organizations should be typed. Michael requested the ability to type organizations, such as "tribe", "ethnic arts dealer", "museum", or "library".
    [PLS]: We should investigate whether the context tagging we have proposed will suffice. This should do what they want, and more, since it allows multiple "types" in the sense they seem to want.
  4. Should Address Information be added to the Person Information schema? Adding to the confusion is the fact that, while the Organization Contact Information appears on its face to be composed of repeatable "Organization's address" and "Organization's contact name" information units, the Person Contact Information schema is not correspondingly composed of a repeatable "Person's address" information unit. Perhaps it should be, for consistency?
    [PLS]: It will be possible to have multiple contact info associations, although we should figure out the UI for this before we go too far. Ditto for Orgs. Finally, we porposed to allow for a Person to have contact into in the context of a given association to an Org (their work address, versus some board-membership address, versus a museum-organization email, etc.).
  5. Will contacts be associated via composition or relation? More broadly, is composition actually intended as the means of association, or will Organizations instead be associated with Persons and Addresses through related records (e.g. through the Relation service or otherwise), and similarly, will Persons be associated with Addresses through related records? A reader might infer from the current schemas that this will be carried out through composition - for instance, that Person Information and Address Information Groups - their fields and data - might literally reside within Organization Information.
    [PLS]: Contact is separate; the current schemas are just confusing.

  6. Contacts are contextual and temporal. Michael noted that contacts are "contextual and temporal," with these implications:
    1. Add context to contact associations. It may be useful to add "types" (controlled text), "notes" (free text), or both to describe the contexts of associations between Organizations and their People and Addresses, as well as the contexts between People and their Addresses.
      [PLS]: See above, and also note that when we relate one thing to another, we can add notes or comments on that relationship. As before, we need to consider UX/UI on all this.
    2. Add a temporal aspect to contact associations. Associations (whether through relation or composition) of an Organization with Addresses and Persons, and of Persons with Addresses, need to have a temporal aspect, such as an end date. In that way, information about past associations can be retained, but current associations - such as an organization's current Addresses and currently associated Persons - could be distinguished from past associations, perhaps by their lack of an end date or by similar means. Note that the temporal qualifier is on the association, not on the contact information. (E.g. When an organization moves away from a physical address, or switches to use different phone numbers, that doesn't usually mean its previous address or phone numbers disappear off the face of the Earth.)
      [PLS]: I think that valid dates must be a part of a whole host of relations, so that should be part of that service.
  7. Electronic contact mechanisms are not tied to physical addresses. It is a mismatch to include phone number(s) and email address(es), within the same information group as a physical address. Instead, there appear to be two major information groups within the Address Information schema, rather than one as currently shown:
    [PLS]: We can use multiple contact relations for this, but some modelin. Note that the KSS spec calls for almost every item to be repeatable and independent: address, phone, fax, email, IM, etc. They also allow setting preferred for each.
    1. Physical addresses, which includes such current information units as:
      • Address - place
      • Address - postcode
      • Address - text
    2. Electronic (or "other") addresses, which are not necessarily tied to any physical addresses.

      Email addresses and mobile (cell) phone numbers are not tied to physical addresses. Even landline and fax phone numbers are increasingly becoming virtual - as is evidenced by services like Google Voice and cloud-based fax services - and that trend is likely to grow over time.
      [PLS]: Nice points. Good to remember.
  8. Two proposed schemas for electronic addresses. To reflect the potential split-off of electronic (or "virtual") addresses from physical addresses, we might conceive of one of the following schemas for electronic addresses:
    1. Designating specific electronic address types; e.g.:
      • Address - e-mail
      • Address - fax number
      • Address - telephone number
      • Address - URL (a potential addition to the schema)

        Each of these could be separately - and repeatedly - associated with an Organization or Person, much as one or more physical address information groups might be associated with an Organization or Person. Each of these would also need to be typed, with controlled text.
        [PLS]: Heh - this is what KSS did. More complex, since we have obj types for each of the associated address types (they cannot just be strings, or we cannot sort/filter by locale, etc.).
    2. As an alternative, there might be only a single electronic address information unit, which would necessarily be typed by an associated "Address type" information unit; e.g. with "e-mail", "fax number", "telephone number", "URL" or the like. This would permit arbitrary extensibility - adding address types such as "Skype address" or "amateur (HAM) radio call sign", for example - without resorting to schema changes or extensions. However, such a use of the "Address type" might in turn hinder the ability ability to apply museum-specific 'types' such as "registrar", "billing contact", "personal" and so on, to these electronic addresses.
      [PLS]: I think KSS has/had the notion of 'media' for individual items that models something like this.
  9. Physical addresses need to be typed. It is highly useful to be able to type addresses; for instance, as "shipping", "mailing" (e.g. via a postal service), or "billing" addresses. This likely means that an "Address type" information unit should be included within each (repeating) instance of a physical address information group.
    [PLS]: Good idea. KSS 'use' models this.
  10. More structure is potentially desirable for physical addresses. Michael noted that he'd like to have City and State/Province fields for physical addresses. This request may be met by the "Address - place" information unit, but is noted here for completeness.
    [PLS]: Agreed. We should be able to query by state, etc.

  11. Templating of physical addresses. Michael noted that PAHMA currently uses at least three somewhat standardized address formats:
    • USA
    • UK
    • Europe and Africa (possibly standardized within Europe, at least for European Union member countries)

      This may lend itself at some point to the use of standard templates for data entry, and for reporting and label printing.
      [PLS]: Ummm. I think the schema must handle the general case: county may be province or canton, and postal code goes in various places in formatted addresses and has different validation schemes, but the address should be fixed with something like Number, Street, City, State/Province (with abbreviation - perhaps an enum), postal code, country.
  12. Notes fields for addresses. There may be utility in having a "Notes" field associated with any particular address - physical or electronic. For instance, this might be used to enter a brief notation about directions to or access to a physical address, or to record that one's last message to an email address 'bounced.' Notes fields might either be included in the schemas for physical and electronic addresses, or associated (or related) to those schemas.
    [PLS]: Nice. Would also be nice to have a formal link that is typed for mapping. Perhaps we can figure out how to suggest this for them, but allow override. This would support a link straight to something like
  13. Ranking of contact information. Where there is limited display space, as in some UIs, there will likely need to be some mechanism for determining which limited subset of contact information (e.g. Persons and Addresses for Organizations, or Addresses for Persons) is displayed by default. This may be handled by ordering (see next item, below) or some other means.
    [PLS]: Again, KSS allows them to mark a preferred item for each type, which could be used to provide a short view.
  14. Ordering of contact information Similarly, there may need to be some ordering of contact information when returned in a list, or at least some ordering hints provided for display purposes, so that items which are marked as higher priority, or perhaps have been accessed most recently, are returned earlier in the list. Michael noted that, in TMS, the first-entered address for an organization, for example, is automatically marked as "preferred," although this designation can be manually moved to another record.
    [PLS]: See above, but I would not bother with full ordering support - just a boolean preferred/not, with date entered/modified as a secondary sort.
  15. Ranking may need to be by type. In TMS, preferences for addresses can be designated by type, so that the preferred billing address, for example, can be distinguished from the preferred shipping address.
    [PLS]: Perhaps this should be a filter? If the type/use is shown, then the UI should allow (local) sorting or filtering on that.


  1. Interesting screenshot/wireframe for physical address data entry?

    The Ooma service, which markets devices that provide VOIP replacements for landline phone service, has some responsibility for associating '911' emergency calls by its customers in the USA with their physical addresses.

    Perhaps due to the gravity of this requirement, they offer an extremely structured data entry screen for physical addresses, which might be interesting to consider in the design of wireframes for entering physical addresses. For instance, nearly every component of street addresses is entered into a separate field, and many of these feature extensive controlled vocabularies.

  2. Address standardization efforts

    Standardization of addresses - such as shipping/mailing addresses - across any significant portion of the world, will be a long time coming, if it ever happens. However, for the record, the following are examples of efforts in that direction, toward standardization or "interoperability" of addresses:

  3. Aron,

    A few points:

    1. What is the structure for Address -place in schema? (see below one suggested by USPS).
    2. Should there be a type for telephone? (landline, mobile, etc.)
    3. Should there be a web site address for organization and person? For person, this could be more than one, e.g. LinkedIn/Plaxo/Facebook/Google profiles, link to blog, etc.
    4. For storage purpose, should we keep space to optionally store geocode? Also, it should be possible to store URL of the mapped address (GMap or YahooMap or MapQuest).
    5. Good points about electronic addresses. I agree there should be one or more fields to insert free form electronic addresses for SIP phones (skype, jajah, etc.), twitter, IM ids, etc.

    See the following USPS guidelines from APIs at



    Required Tag/
    Optional Value

    Maximum characters allowed: 38
    For example:  <FirmName>XYZ Corp.</FirmName>


    Required Tag/
    Optional Value

    Address Line 1 is used to provide an apartment or suite number, if applicable. Maximum characters allowed: 38
    For example:<Address1></Address1>


    Required Tag/
    Required Value

    Street address.
    Maximum characters allowed: 38
    For example:<Address2>6406 Ivy </Address2>


    Required Tag/
    Optional Value
    (see box at right)

    Maximum characters allowed: 15.  Either <City> and <State> or <Zip5> are required.
    For example:<City>Greenbelt</City>


    Required Tag/
    Optional Value
    (see box at right)

    Maximum characters allowed: 2. Either <City> and <State> or <Zip5> are required.
    For example:<State>MD</State>


    Required Tag/
    Optional Value
    (see box at right)

    Input tagexactly as presented, not all caps.  Maximum characters allowed: 5. Either <City> and <State> or<Zip5> are required.
    For example:  <Zip5></Zip5>


    Required Tag/
    Optional Value

    Input tagexactly as presented, not all caps.  Maximum characters allowed: 4
    For example: <Zip4></Zip4>