Hans,
One of the differences between the military intelligence world.
as compared to the business world, is that intersystem connections and
functions are fairly interoperable.
The military has so much money to spend on intelligence that the
very best designs, no matter how high the cost in labor or equipment, are
justified by the extreme risk that the military takes. So yes, the scope
of each military project is thought out down to the seams, toilet cover, and coffee
pot. The Scope is what the military calls the project elements.
Businesses are far less methodical about their IT stuff.
Business is far more financially efficient in terms of resource
usage because very few businesses have to worry about losing customers or
employees to violent acts. But 80% of new businesses fail, and get wiped
off the Earth, all without hurting anyone in any physical way - just losing all
their money.
So yes, with a very large budget, or in the future with really
good technology tool ware, businesses might adopt the military methods as
well. But for now, the military is the best example of organizing
software development and deployment using the SCOPE plans.
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 Hans Polzer
Sent: Saturday, October 24, 2015 5:55 PM
To: 'Thomas Johnston'; '[ontolog-forum] '
Subject: Re: [ontolog-forum] Prospects made into Customers and Vice
Versa
Tom, Rich:
This example isn’t just about aligning or comparing
definitions of what a customer is or about data definitions for particular
columns in the database schema. It’s also about the scope of these
different databases and how those scopes relate to each other (e.g., are they
disjoint or do they overlap – and, if so, to what degree or based on what
attribute sets and associated value ranges), as well as how the scope of the
set of databases being accessed relate to the overall intended scope of the
query.
One of the purposes of the NCOIC SCOPE model is to help people
explore, enumerate, and understand these scope differences among data bases and
systems, and develop any scope representations that will be used to resolve
these questions in operational software. I’ll note that it is a rare
database name that includes any scope parameter values at all, much less scope
attributes and value sets that allow reasoning about the completeness of a set
of databases for the intended purpose of the query.
Hans
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Thomas
Johnston
Sent: Saturday, October 24, 2015 8:34 PM
To: Rich Cooper <metasemantics@xxxxxxxxxxxxxxxxxxxxxx>;
'[ontolog-forum] ' <ontolog-forum@xxxxxxxxxxxxxxxx>
Subject: Re: [ontolog-forum] Prospects made into Customers and Vice
Versa
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 (01)
|