ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Constructs, primitives, terms

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Fri, 02 Mar 2012 11:07:42 -0500
Message-id: <4F50F04E.9020404@xxxxxxxxxxx>
Pat and Amanda,    (01)

PC
> I am curious to know what kinds of inconsistency you are referring to:    (02)

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.    (03)

Let me restate my previous discussion in more concrete terms:    (04)

  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.    (05)

  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.    (06)

  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.    (07)

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?    (08)

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.    (09)

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.    (010)

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.    (011)

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.    (012)

Yes, but those terms have a common subset of meaning that can be
exchanged with the common URIs for many operations, such as EFT.    (013)

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.    (014)

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.    (015)

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.    (016)

Any belief that URIs and closed form definitions can magically solve
all these problems is an illusion.    (017)

John    (018)

_________________________________________________________________
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    (019)

<Prev in Thread] Current Thread [Next in Thread>