Contact Information and Communication Prefereneces

This is a log of an email conversation between Michael and Dave McComb (Unlicensed). This topic came up in Loans, but belongs in a more general place, probably FND or BE. The provisional solution may be found in the December 3, 2015 version of the loan ontology in owl.

I used an example of digital assets because I did not have an easy to understand example from finance.

Michael to Dave:

Lynn and I were talking about how to model contact information for HMDA reports sent from lending institutions to regularotry bodies about loans.  Lots of things can have a need to point to contact information in for various reasons. e.g. the HMDA report wants a contact person and a contact organization.  Contact information is a generic concept across many industries and contexts.  It came up in recent work on digital assets, there needs to be a way to contact someone to license the asset.  There are different ways to model contact information.

1.       Just point to a contact individual person, or organization and the contact information that is associated with that person or organization is available from there.  This works in the simple case.  In more complex cases an indiv or org has multiple emails or phone numbers, each for a specific role. Then you need another approach.

2.       Have an email or phone number that is associated with e.g. the report.  It can directly hang off of the report, if it is only an email or a phone number, so you could have a property individualContactTelNo pointing to a phone number, and a property orgContactTelNo pointing to a phone number.   This is ok if there is a very small number of links like this.  But it could get unwieldy, in which case a more robust and more general approach would be more appropriate.

3.       The most robust way to do this (with a cost of being more complicated) is to capture the different reasons for the contact info (e.g. person to call about admin matters, person to call about legal matters, person to call about other matters, then it may be best to create a class called  ContactInformation and its meaning is “a way to make contact with a person for a particular reason regarding something (e.g. a report or a digital asset).   Hanging of that ContactInfo is whatever is needed, phone, email, postal address etc.  This can be done in two ways

a.       Have multiple properties pointing to instances of ContactInfo, one for each reason. E.g. legalContactInfo, adminContactInfo, etc.

b.      Have a single property pointing to ContactInfo, and have a field in ContactInfo indicating what this contact information is for.

The latter approach is analogous to ThingInRole.  Elisa would have us call it ResponsibleParty, but that misses the point. Sometimes it would be just a single email (analogous to officemanager@foo-company.com).  This email exists by itself and may be managed by any number of individuals that change over time. So there is no responsible party being pointed to, it is an email, that one or more persons are responsible for.  And anyway, ResponsibleParty is an unnecessary class. It is not a different kind of party, it is a party playing a role.

Does any of this make sense? Probably will be easier with triples and examples.  

None of this seems to exist anywhere in FIBO.

 Dave Reply

Yeah makes sense.  What I generally advocate, and I was starting to model in fibolite, is pretty much 3b.

The main important things, in my mind:

1) Address needs to be a first class object, and not a property or attribute of anything else.  This is the single biggest problem with most existing systems.

2) There are five legitimate subtypes of Address, as they each have different properties, structures and behaviors: postal addresses, building addresses, telephone numbers, fax numbers and electronic address (which include emails, but also any thing you can send an electronic message to) ( many addresses will be in more than one category, such as a building address that the post office will deliver to, which is most of them)

3) I do advocate creating a object in-between Address and what it’s being attached to.  I don’t see this as a “thing in role” (and least not only) because it is real and carries information.  I like to make the connection from Person or Organization to Address “CommunicationPreference” which allows any implementer to organize their own taxonomy of preference types (like outlook does with “home” “business” etc, but instead of being that lame it could be based on a small taxonomy of message types (send my appointment reminders here, my invoices here, fails over there and subpoena’s way over there)

4) in your case I think instead of the preference from the person side you might have some thing analogous from the agreement side.

Michael Followup

Ah yes, “CommunicationPreference”, which is the other side of what I’m talking about. What I am calling ContactInfo is precisely what you refer to in your fourth point.

Communication Preference hangs of a person (or maybe an organization?) and says how that particular person wants to be reached in what specific circumstances (e.g. for licensing digital assets in general).

ContactInfo hangs off of something and it means: “one or more ways to make contact with a person for a particular reason regarding the something.  Hangs off of a digital asset and is about licensing.

From the point of view of say a digital asset, “ContactInfo for licensing” might be nothing other than an email address. Using the 3b approach, I would have a property linking the asset to an instance of ContactInfo that had an email address on it and also a tag meaning ‘for licensing’.  It might also have a phone number alternative or even postal address (rare these days),  so it really is one or more ways to contact a party about something (as opposed to being a single communication preference of any party).

That email (or tel no etc) hanging off the digital asset might be associated with a group of people who are authorized to handling incoming communications  about licensing. To repeat, it is not the CommunicationPreference of any one or more persons. There are one or more persons attached to the email address just as our Melissa is attached to officemanager@semanticarts.com. In a large company, there could be several people responding to that email.

On the CommunicationPreference side, there might be several parties that handle licensing of digital assets, and each of those parties might specify a preference to be reached at a specific email (which could be the same or different from any email associated with a particular asset).  This is the party’s saying that, independent from any particular digital asset, they prefer to be contacted in a particular way for licensing of any digital asset.

A Communication preference is not at all like a thing in role. ContactInformation is a bit like it in so far as it really is pointing to a person or organization and saying how to reach that person in the role of handling licensing a particular asset.  It could be that a different asset (owned by someone else) points to a different email that that same person handles.  This would enable them to track billing, say.  That person in that role could have different email or tel no for each such role that they played, so it is not obvious how that information could be conveniently hanging off of either the digital asset or off of the person.

I don’t particularly like doing it this way, but the obvious alternatives are not so nice either. It seems like one of those rare cases when the property does not belong on either the digital asset, nor on the person, it is on the person in a particular role regarding that asset.