John,
I think we agree that local usage of data *may* affect the local logical
interpretation, and therefore its intended meaning, but where that occurs, I
would say that the local conditions should be logically specified and made
part of the ontology that is used in common (i. e., a merger of local
ontologies) for interoperability. (01)
(I try to avoid the word 'definition' so as not to imply that only
necessary and sufficient conditions are intended, but in my previous post I
did add qualifiers which, for brevity, I hoped would be understood as also
applying. In the below when I say 'define' or 'definition' it means only
the kind of logical specification (usually with necessary conditions) that
is in an ontology, but which may include some necessary and sufficient
specifications for some classes.) (02)
[PC]
>> Does this refer to cases where two communicating systems define (or
>> otherwise logically specify the intended meaning) of the *same* term
>> (e.g. 'widget'), but use different definitions?
>
> That depends on what you mean by "definition". You can say that the
> official definition of a term is the statement designated by its URI.
> But each bank uses each term in its own context. Each use in each bank
> may be consistent with the common definition, but other relationships
> in each context may be different.
>
> As a result, a customer who switches to a different bank may get
> unpleasant surprises about the fees or constraints that one bank
> imposes that the other one didn't. Humans can adjust to such
> "surprises", but computer systems usually cannot.
>
> Are you going to call that additional context-dependent information
> part of the definition? . . . .
Not necessarily, though it might be in some cases. Take the case of a
check for which sufficient funds are not available: for some accounts it
might merely generate an "overdraft" fee, for others, the check might be
returned. I think people and intelligent machines can be aware of what it
means to be a "check for which there are insufficient funds" (and thereby
have a common understanding) without having a clue as to the policy of any
given bank for any given account in such circumstances. It would be a
mistake of a system to assume that one bank's policy is the same as
another's without explicit information. This would be a case where, even
with a common perfect understanding of the terms used, one still cannot
predict the actions of agents. PIFO-based Interoperability can provide a
common language and allow all systems to understand the common logical
specifications of terms, but cannot predict the actions of any given agent
in a given set of circumstances unless the policies governing those actions
are also coded in the same language and shared. (03)
So for the case of how an, e.g. overdraft, is handled I would say those
policies are *not* part of the logical specification of the term
'insufficient funds in a checking account', or loosely using the term
'definition', not part of the definition. They are part of the logical
specification of bank policies, which must be understood in order to predict
bank actions. If properly drafted, I think that an ontology that includes a
specification of 'checking account' would include provision for specifying
bank policies for specific subtypes of 'checking account', in which case
those policy specifications *would* become part of the specifications of
those account subtypes, as necessary conditions for certain contingencies.
(i.e. '*Each* checking account must have *some* policy for acting when a
check exceeds remaining funds'). (04)
We can't expect systems with perfect interoperability to be able to
predict events that a person could not predict with the same information.
The problem in the above scenario isn't the inadequacy of the common
ontological language, it is the inadequacy of the knowledge about bank
policy, whether it is a person or an automaton that is trying to predict the
result. (05)
This is a topic of great interest to me, and I would be interested to see
any kind of detailed example of how an attempt at interoperability failed in
spite of accurate common terminology, because of local usage that changed
the meanings of terms. That can be useful in learning what needs to be
included to adequately specify the meanings of certain terms. (06)
Pat (07)
Patrick Cassidy
MICRA Inc.
cassidy@xxxxxxxxx
908-561-3416 (08)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Friday, March 02, 2012 11:08 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Constructs, primitives, terms (09)
Pat and Amanda, (010)
PC
> I am curious to know what kinds of inconsistency you are referring to: (011)
JFS
>> So far, so good. But a problem arises when systems A and B
>> exchange messages that use only the "common" vocabulary defined
>> by the shared URIs. They may use the same terms, but their
>> specialized "senses" of the terms may be inconsistent. (012)
Let me restate my previous discussion in more concrete terms: (013)
1. Suppose A and B are both banks. They use many common terms that
are defined precisely, but without much detail -- for example,
a checking account with a globally unique routing number for
electronic funds transfer. (014)
2. But every bank adds more detail about the options for their
accounts, and they differ from the options at other banks. Each
word for describing those options can also be precisely defined
with its own URI, but each bank might combine those terms in
patterns that are unique to that bank. (015)
3. As a result, banks can "interoperate" only on a narrowly defined
set of EFT message types. Messages that use the common terms in
any combination that has not been standardized may be interpreted
in inconsistent ways by bank A and bank B. (016)
PC
> Does this refer to cases where two communicating systems define (or
> otherwise logically specify the intended meaning) of the *same* term
> (e.g. 'widget'), but use different definitions? (017)
That depends on what you mean by "definition". You can say that the
official definition of a term is the statement designated by its URI.
But each bank uses each term in its own context. Each use in each bank
may be consistent with the common definition, but other relationships
in each context may be different. (018)
As a result, a customer who switches to a different bank may get
unpleasant surprises about the fees or constraints that one bank
imposes that the other one didn't. Humans can adjust to such
"surprises", but computer systems usually cannot. (019)
Are you going to call that additional context-dependent information
part of the definition? Most people don't say that explicitly, but
it is just as much a part of the broader "meaning" as any definition.
Unfortunately, that contextual information may be difficult or
impossible to state in a "closed form" definition. It may be
scattered in database formats, procedures, or implicit conventions. (020)
AV
> Systems A and B may use the same "term" where "term" = lexical item,
> to express different concepts. That's not a logical inconsistency.
> It's an ordinary difference in language (natural or artificial),
> and can be handled well by mapping those lexical expressions to
> different concepts. (021)
Yes, but those terms have a common subset of meaning that can be
exchanged with the common URIs for many operations, such as EFT. (022)
But when that additional contextual "meaning" is significant, you
need further conventions. One option is to rename every term X that
was supposed to be "common" to both banks by a qualified name such
as X.A or X.B. But then you need to determine when you can use the
generic name X for some operations or the more specific names such
as X.A and X.B for others. (023)
Furthermore, each bank has many business policies, systems analysts
who interpret those policies, and programmers who implement them.
Each change to any program can change some of that contextual meaning.
Therefore, we need to have version numbers for all our systems. (024)
That means we need unique URIs of the form X.A.v1.0, X.B.v2.7, etc.
Then we need to know when it's possible to interchange data according
to name X and what to do with data that uses names like X.A or worse. (025)
Any belief that URIs and closed form definitions can magically solve
all these problems is an illusion. (026)
John (027)
_________________________________________________________________
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 (028)
_________________________________________________________________
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 (029)
|