Tom and Ed, et al,
I think you both might find this TED talk informative:
http://www.ted.com/talks/rory_sutherland_life_lessons_from_an_ad_man#t-152860
Sincerely,
Rich Cooper,
Rich Cooper,
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT EnglishLogicKernel DOT com
( 9 4 9 ) 5 2 5-5 7 1 2
http://www.EnglishLogicKernel.com
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Edward
Barkmeyer
Sent: Wednesday, October 28, 2015 11:40 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Prospects made into Customers and Vice
Versa
David,
We apparently read the same text and drew different
interpretations. Tom said that the manager decided to change the
interpretation of Customer for his business unit, nominally in order to align
the interpretation with other business units, for a particular reporting
purpose. He went on to talk about this being an 'ontological' change, in
the interpretation of the term, and in its denotation, within that business
unit. What Tom argued was that the term had an established definition and
an established history of extensions, and then it changed, acquired a new
definition, and a no-longer-consistent set of extensions. And that
situation gives you apples and oranges when you try to compare historical data,
along with communications problems within the business unit during the
"migration phase". But there was an existing communications
problem *across* business units because they *disagreed* on the
meaning of the term Customer in the report in an important way. And that
is why I talked about the "socio-spatial" scope of a term, in
addition to its temporal scope.
How that change was implemented in the applications under
control of that business unit was not a concern that I read, and if that change
was only in the reporting application, it would have no ontological impact at
all. But Tom then started talking about databases, and you understood
that he must have been talking about applications from the outset. I
don’t think Tom ever considered whether an O-O Class was the implementation of
the concept Customer, or that the report in question blindly reported only
members of that Class. I think this is rather yet another
confirmation of an observation by the late Brian Meek (of Kings College London
and the BSI):
"People in the information industry seem to
have a great deal of difficulty keeping a conversation at a common level of
abstraction for any length of time."
Yes, it is bad practice to
change the meaning of an O-O Class that is used by multiple applications.
But the thing is an implementation object, and when you are changing an
implementation to deal with the changes in your world of interest, you make
engineering choices. When the meaning of the term has changed in the
business, is it better to restructure the software object, or keep the software
name for what is no longer the business concept? Rock, hard place, or
Scylla, Charybdis, if you prefer. And of course, my ever present harp is
that the software class *is not* the business concept; so you do have a
choice.
-Ed
Edward J. Barkmeyer
Thematix Partners
Email: ebarkmeyer@xxxxxxxxxxxx
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Price
Sent: Wednesday, October 28, 2015 6:26 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Prospects made into Customers and Vice
Versa
Hi Ed,
Seems to me the problem as described is not about different
apps with different views of Customer, that’s well understood and things like
namespaces handle it sufficiently.
The problem was that the Customer was changed in an existing
single app to change its membership in that app. Therefore, any processing
(e.g. monthly report) of Customer that depended on then “correct” definition
was now invalid (e.g. comparing monthly reports is now meaningless). That’s
what is objectionable about this scenario - changing the definition and
membership of an already defined class in an operational app.
David
I would like to take this discussion back two steps to where it
started, i.e., with Tom’s example of a manager electing to redefine the term
“customer”, either to align the usage in his division with that of other
divisions (a good practice), or to achieve some deception for upper management
(a dubious practice).*
The fact of the matter is that in large business organizations
and partnerships, the same term has multiple meanings with a large overlap in
the referents. So the “socio-spatial” scope of a term is just as
important as the temporal scope. (I recently argued in another forum
that) business partners often agree on the referents of a term as it relates to
their partnership, without agreeing on the definition of the term at all.
In effect, there are two or more different predicates that are expected to have
a common extension in the partnership space.
The second problem is that the intensions (definitions) of
business terms DO change over time, precisely because the business environment
and the business practices change. The underlying intent of the term does
not usually change (much), but any kind of formal operating definition gets
modified to deal with the new and evolving elements of the actual business
world. Even biological taxonomy changed significantly in 1970; the
definitions of the “second” and the “inch” changed in 1972; and no one had to
protect the data on his phone in 1995. So, changing the meaning of the
term ‘customer’ to match a change in business practice is a common occurrence.
*Back in my youth, the McDonald’s restaurant practice was to
“make to stock” the dozen menu items. When you stepped up to the counter,
the clerk opened the transaction on his “register”, took the order, and went to
the hot table, pulled the order items, returned with the filled order, took the
payment and closed the transaction. But when (c. 1975) management
installed new “point of sale” machines that clocked elapsed time per
transaction per station, the clerk opened the transaction, took the order,
accepted payment, closed the transaction, and then went about fulfilling the
order. The point-of-sale terminal reported “serving time: 26 seconds”,
but the customer did not experience the performance that the management
statistics indicated. The meaning of “serving time” – that which the
management intended to measure -- had been changed by changing the business
practice.
I'm
ok with <Class> being defined as a set whose set membership criterion
does not change -- which is how you have defined it.
But
I'm not ok with the membership of a <Class> never changing, and with your
claim that apparent change is simply a matter of our discovering a new member
that we hadn't recognized as a member before. My reason is that even if set
membership criteria do not change, those things which make up the universe of
discourse for a <Class>/set do change. For example, if a customer of a
tobacco company has to be eighteen years old, then every year there will be a
new crop of people (the universe of discourse) who are eligible to become
customers; and probably some of them will. This isn't a merely apparent change;
it is a change in what you called "true membership”.
The way this issue is addressed in ISO
15926/4-dimensionalism is that there is considered to me an all-knowing system
which does know all members of a class for all all time and that’s how one
identifies the class by its extension in all of space/time. In your local
application, you can often only record a specific subset of that full
membership at any point in time, but that lack of data locally does not change
the fact that the all-knowing system is what is used to identify the class.
Any
software engineer/Semantic Web expert would not allow “So the A boss has the
distinction changed so that people who have NEVER bought, but who are known by
A, are now treated as customers just like the B division mgrs do it.” to occur.
In any serious organisation, the change management of the software system
containing Customer would reject this proposal. The actual requirement would be
analysed and a reasonable change made the application.
For
many Semantic Web developers, a key characteristic of a “Class” is that their
definition does not change. If a change is required with different membership
is the desired outcome, then another Class is created that is a superclass of
Customer, subclass of Customer or overlaps with Customer. Philosophy and
technology cannot actually stop people from doing dumb things, but they do
provide guidelines and rules that if followed result in fewer dumb things
happening.
In
an engineering standard ISO 15926 used as OWL in Oil and Gas, classes are
defined as follows:
<class>
is a <thing> that is an understanding of the nature of things and that
divides things into those which are members of the class and those which
are not according to one or more criteria.
The
identity of a <class> is ultimately defined by its members. No two
classes have the same membership. However, a distinction must be made
between a <class> having members, and those members being
known, so within an information system the members recorded may change over
time, even though the true membership does not change.
NOTE
1 The membership of a
<class> is unchanging as a result of the spatio-temporal
paradigm upon which this schema is based.
and
as you can see it specifically stated that classes are unchanging. 4D is hard
so not that many modellers follow it rigorously, but the idea that you cannot
change the definition of a class is pretty typical.
The
OWL 2 specification says “Classes can be understood as sets of
individuals” and “Class expressions represent sets of individuals by formally
specifying conditions on the individuals' properties; individuals
satisfying these conditions are said to be instances of the respective
class expressions.”, which if used properly would lead to rejecting
the change proposed by this “boss”.
In
Semantic Web languages, the concept of namespace is used to disambiguate cases
where people use the same term to mean different things, where Tank (military) vs.Tank
(storage) is the example people often provide. As it happens, we use Customer
as the example in our training material although the people in our example are
more responsible than the “boss” in your example.
I agree, Rich. So since so-called Customer
tables will represent different collections of things, albeit all called customers,
what are we to do when trying to compare different Customer tables from
different databases? Give up? Appeal to Mirriam-Webster?
I take it that the whole idea of a
Semantic Web is that software can recognize in what respects similar tables are
similar but not identical, or by virtue of what identical set of criteria
identical tables are identical (whether or not their names are). If this can't
be done by software, it has to be done by people, interpreting definitions
written down in data dictionaries. Definitions, I will add, that in thirty
years plus of IT database modeling and design in the world of commercial IT, I
have never found to be anything more than vague glosses on a statement of the
criteria that define those tables and that account for their similarities and
differences.
In this forum, I believe Pat Hayes to be
the most informed expert on the Semantic Web that we have. Perhaps we need to
hear from an expert like him, or others, rather than additional comments from
an opinionated ersatz academic like myself.
This is what we need a
true Semantic Web for. We can't just look for tables in different databases
that have the same name, to know we will be accessing tables that represent the
same things.
While that statement is
true, the name of the table is not as
important as its functionality,
which is more a conceptual thing about who pays the DB users money, versus who
gets paid by the DB users. When I talk to a developer of systems using
different tools and equipment than I use, that developer will immediately know
what I mean by the "Customer" table. So it's more about inflow,
outflow and accumulations within categories.
Two tables represent the
"same things" if and only if (i) they share a universe of discourse,
and (ii) they use identical set membership criteria to partition that universe
of discourse into things that aren't represented in those tables and things
that are.
It's perhaps more
philosophically correct to go that way. But in real situations (as you
probably know), the software does what the software customer wants it to. It
doesn't follow some one-size-fits-all conceptual structure, but it is custom
tailored to the owner, the business, the products and services, financing, and
all kinds of constraints like that. So a simple, consistent set of
definitions would likely cause disaster in many applications.
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT
EnglishLogicKernel DOT com
For naming database
tables, what the English language says is irrelevant or, at best, nothing more
than suggestive. The table Customer for division A is whatever division A says
it is, and so too for division B.
"Customer" is a
name that each division gives to a table it has. If they wanted to call the
table "XYZ", there is no reason why they can't. The table, and its
set membership criteria, are one thing; the name given to it is something else.
The tables -- the one for
A and the one for B -- if they are relational tables, are sets. As sets, they
have set membership criteria which say which, for all the possible persons who
might be or become customers, what criteria they have to meet to become customers,
and to remain customers. And as I said, across a couple of dozen clients, I
have never found any two of them who had Customer tables with exactly the same
set membership criteria.
And, to look at it from
the opposite end of things, suppose A and B did define their tables, in set
membership terms, identically, but that A called its table a
"Customer" table and B called its table an "Obligated
Party" table. The different names wouldn't matter. The two tables would
still be identical.
This is an example of one
of the important things ontologies can do. They can tell us when two identical
names are homonyms and, conversely, when two different names are synonyms.
If you are worried about
the "customer" vs. "prospect" distinction in ordinary
English, let me change the example. Let's say that for division A, someone
stops being a customer if they haven't purchased anything in the last three
years; but for division B, someone stops being a customer if they haven't
purchased anything in the last two years. Surely no English dictionary would
say that either or both of these rules created an "untruth".
And note the most
important point. These are differences which make a difference. Even though
both tables are given the name "Customer", they mean different
things. A SQL Count statement against the two tables, to decide which division
had the most customers, could not provide an answer, because the statement will
be counting different definitions of "customer". The statement will
be counting apples and oranges.
Reading up on dictionaries
will not solve this problem. First, as I said, dictionaries are irrelevant.
Secondly, no ordinary language dictionary would ever provide a definition
accurate enough to tell us what rules have to be satisfied for somebody to be
represented in any Customer table.
This is what we need a
true Semantic Web for. We can't just look for tables in different databases
that have the same name, to know we will be accessing tables that represent the
same things. Two tables represent the "same things" if and only if
(i) they share a universe of discourse, and (ii) they use identical set
membership criteria to partition that universe of discourse into things that
aren't represented in those tables and things that are.
I would like to
recapitulate your example of the company that has two divisions A and B.
B treats all prospects as customers while A distinguishes customers as those
who have actually bought something in the past.
The boss tells A division
mgrs to up the customer count. So the A boss has the distinction changed so
that people who have NEVER bought, but who are known by A, are now treated as
customers just like the B division mgrs do it.
While that change seems
very normal and natural for a business to do that in trying to wrap its
processes around the tax and risk constraints it has to deal with, it also
seems like an untruth,
since the English language says Prospects are not the same as Customers.
How do you philosophers in
the crowd deal with that kind of change of definition into something every
business knows is just plain incorrect?
Chief Technology Officer,
MetaSemantics Corporation
MetaSemantics AT
EnglishLogicKernel DOT com
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
|
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|