observable:firstName currently has the following definition, added in CP-5 (refactoring contacts):
The first name of a person.
It used to have the following definition:
The first name of the contact.
There was no specific rationale given for observable:firstName in the proposal. (This proposal has not been publicly exported, as became practice in a later UCO release.) This is the only focused remark on observable:firstName:
Modify definition comment of observable:firstName to abstract it from only Contacts
Someone reached out to me to ask when observable:firstName would be used instead of something from the identity namespace. I don't have a good answer for them, and I see no documentation to explain why this property moved towards potential confusion with properties in the identity namespace. Rationales for the changes in UCO CP-5 were not included in the proposal, beyond what seems to distill to something like "Reduce confusion between contacts in an address book and point-of-contacts for online services." Unfortunately, the implementation induces some confusion between the observable and identity namespaces now both trying to represent people, rather than observable objects.
Requirements
Requirement 1: The definition of observable:firstName should revert to The first name of the contact.
Requirement 2: observable:firstName should change to observable:contactFirstName, to separate scope of this property clearly away from identity:Person and more towards a contact record.
Requirement 3: Properties semantically close to observable:firstName should receive the same updates as in requirements 2 and 3. These include:
observable:lastName -> observable:contactLastName
observable:middleName -> (etc.)
observable:namePhonetic
observable:namePrefix
observable:nameSuffix
observable:nickname
Non-requirements
The following other properties within observable:ContactFacet that do not match the observable:contact* pattern are not revised by this proposal. Note the namespace prefixes.
identity:birthdate
observable:displayName (due to usage in other facets)
observable:sourceApplication
observable:lastTimeContacted
observable:numberTimesContacted
Potential Requirement 4: An example needs to be created (whether in UCO's unit tests, or among the CASE examples) that relates some observable:ObservableObject subclass, which uses observable:firstName, to an identity:Person.
Benefits
No example exists demonstrating a Relationship object that ties a person to a contact. Potential-requirement 4's necessity is in demonstrating competency of the identity namespace's ability to interact with the observable namespace.
The name pattern of properties within the ContactFacet become more consistent. See e.g. observable:contactAddress, observable:contactPhone.
Risks
Seven existing property names would change. The value from disambiguating from the identity namespace is believed to be worth this development cost.
Competencies demonstrated
Competency 1
If a name "Bruce" is found in a knowledge base that records contacts and person details, they can be semantically distinguished as records of somehow-confirmed personal details, versus a record stored within a contact store somewhere. Take for instance these two objects, using UCO 0.8.0 terminology:
This is compatible with observable:firstName retaining the definition "The first name of a person". However, a contact-record could describe this same person in a way that might render helpfully in the contacts or phone interface but otherwise be a semantic misuse of the fields.
Last, if the firstName field continues to call itself the first name of a person, it introduces a point of confusion of the source of that name. Is the name-association's source a person having the name, or somebody recording what they would want to remember as they were filling their address book in?
There should be no reason UCO assists with confusing those fields with a person's name.
Solution summary
For the properties listed in requirements 2 and 3:
Revise concept name to start with contact.
Revise definition comments to say "contact" instead of "person".
Doing so addresses requirements 1, 2, and 3.
Integrate the above competency into either CASE-Examples or a UCO unit test. Doing so would address potential-requirement 4.
Note the Batman example above stops short of establishing a linking Relationship object, due to a lack of concept support for relating an Identity with a Contact. Decisions needed to define such a kindOfRelationship value might unnecessarily delay the primary proposal goal of disambiguating contact properties.
Background
observable:firstNamecurrently has the following definition, added in CP-5 (refactoring contacts):It used to have the following definition:
There was no specific rationale given for
observable:firstNamein the proposal. (This proposal has not been publicly exported, as became practice in a later UCO release.) This is the only focused remark onobservable:firstName:Someone reached out to me to ask when
observable:firstNamewould be used instead of something from theidentitynamespace. I don't have a good answer for them, and I see no documentation to explain why this property moved towards potential confusion with properties in theidentitynamespace. Rationales for the changes in UCO CP-5 were not included in the proposal, beyond what seems to distill to something like "Reduce confusion between contacts in an address book and point-of-contacts for online services." Unfortunately, the implementation induces some confusion between theobservableandidentitynamespaces now both trying to represent people, rather than observable objects.Requirements
Requirement 1: The definition of
observable:firstNameshould revert toThe first name of the contact.Requirement 2:
observable:firstNameshould change toobservable:contactFirstName, to separate scope of this property clearly away fromidentity:Personand more towards a contact record.Requirement 3: Properties semantically close to
observable:firstNameshould receive the same updates as in requirements 2 and 3. These include:observable:lastName->observable:contactLastNameobservable:middleName-> (etc.)observable:namePhoneticobservable:namePrefixobservable:nameSuffixobservable:nicknameNon-requirements
The following other properties within
observable:ContactFacetthat do not match theobservable:contact*pattern are not revised by this proposal. Note the namespace prefixes.identity:birthdateobservable:displayName(due to usage in other facets)observable:sourceApplicationobservable:lastTimeContactedobservable:numberTimesContactedPotential Requirement 4: An example needs to be created (whether in UCO's unit tests, or among the CASE examples) that relates some
observable:ObservableObjectsubclass, which usesobservable:firstName, to anidentity:Person.Benefits
Relationshipobject that ties a person to a contact. Potential-requirement 4's necessity is in demonstrating competency of theidentitynamespace's ability to interact with theobservablenamespace.ContactFacetbecome more consistent. See e.g.observable:contactAddress,observable:contactPhone.Risks
identitynamespace is believed to be worth this development cost.Competencies demonstrated
Competency 1
If a name "Bruce" is found in a knowledge base that records contacts and person details, they can be semantically distinguished as records of somehow-confirmed personal details, versus a record stored within a contact store somewhere. Take for instance these two objects, using UCO 0.8.0 terminology:
This is compatible with
observable:firstNameretaining the definition "The first name of a person". However, a contact-record could describe this same person in a way that might render helpfully in the contacts or phone interface but otherwise be a semantic misuse of the fields.Last, if the
firstNamefield continues to call itself the first name of a person, it introduces a point of confusion of the source of that name. Is the name-association's source a person having the name, or somebody recording what they would want to remember as they were filling their address book in?There should be no reason UCO assists with confusing those fields with a person's name.
Solution summary
contact.Doing so addresses requirements 1, 2, and 3.
Relationshipobject, due to a lack of concept support for relating anIdentitywith aContact. Decisions needed to define such akindOfRelationshipvalue might unnecessarily delay the primary proposal goal of disambiguating contact properties.Coordination