John Sowa wrote:
> Pat C
>> I am curious to know what kinds of inconsistency you are referring to: (01)
> 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. (02)
> Let me restate my previous discussion in more concrete terms: (03)
> 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. (04)
EFT messages have a large standardized vocabulary used in millions of
messages each work day. This vocabulary & its meaning work. (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)
If it applies only within the bank, it affects nothing outside the bank. (07)
> 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. (08)
They are limited by their shared vocabulary and standardized message
types. In Electronic Data Interchange (EDI) systems, the standardization
allows format to dictate the interpretation of content -- just as it does
in databases. A two character code in one part of a message may have
a meaning with nothing to do with a two character code having the same
two characters in another part of the message -- the same as the presence
of same value in two different columns of a database may be unrelated. (09)
EDI systems, including SWIFT and other EFT messages, have fixed
formats and vocabularies, but are not based on ontologies. (010)
If you are proposing new message types (ones that have "not
been standardized"), then their meaning would not be clear until
the message type is standardized. (011)
I would suggest that instead of "[m]essages 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" that
such messages would not be interpretable by the bank that did
not originate such a message. (012)
There have been proposals for EDI systems to move from syntax-based
systems to XML-based systems with standardized tags. It would be
possible with such systems to generate and transmit non-standard
messages. Such messages would have the problems you state.
However, with XML messages dozens of times longer than regular
EDI messages, conversion to such systems is unlikely in the near
future. (013)
> 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? (014)
> 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. (015)
By "other relations", do you mean relations signified by terms which
are not in the common ontology? (016)
> 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. (017)
A computer system trying to convert a document from Bank A's
system to Bank B's system would easily determine if some of the
URIs that Bank A uses are not in Bank B's ontology. It would not
confuse A:StandardOverdraftProvision with B:StandardOverdraftProvision
even in the event that the two banks chose the same local name
for their local concepts. (018)
> Are you going to call that additional context-dependent information
> part of the definition? (019)
Such context information might be properties of knowledge base
instances of common ontological classes such as SavingsAccount.
I'm not sure you need to define it as definitional. Properties of
SavingsAccounts at Bank A may be different from properties of
SavingsAccounts at Bank B, but such properties may be specified
by rules -- neither need be part of the definition of SavingsAccount. (020)
> 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. (021)
I'm not sure why it need be "difficult or impossible" to state
contextual information. If the objection is to "closed form",
meaning that the meaning of the definition must be intrinsic
to the system, and not refer to the "real world", then i agree,
but question what that has to do with the rest of this discussion. (022)
> 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. (023)
> Yes, but those terms have a common subset of meaning that can be
> exchanged with the common URIs for many operations, such as EFT. (024)
Once you move to URIs, you need no longer consider the NL "terms".
If two systems share a meaning, it is useful for them to use the same
URI. If they have different meanings, they should use different URIs. (025)
> 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. (026)
Once you are referring to two different URIs, there is no reason to
consider that there is any similarity between their meanings. (027)
Standard practice for qualified names would be to specify the ontology
first, then the name within the ontology. Thus you would have (in
the abbreviated URI syntax you are using) A.X and B.X . (028)
> 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. (029)
I guess you mean:
X a owl:Class .
B.X a owl:Class ; rdfs:subClassOf X .
A.X a owl:Class ; rdfs:subClassOf X . (030)
Each bank would create instances of its own subclass of X, which
would transitively be instances of X. Internally, they would use
the information about A.X (or B.X), but messages outside would
have to only use X. (031)
> 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. (032)
Why not make versions of the policies, and define the properties of
the various properties? This would not necessitate new URIs for each
existing URI, if the policy had different treatment for instances of the
class represented by that URI. (033)
> 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. (034)
Data with a local URI is useless to a system without a definition of
that URI. A message to another system would only provide the
data that that message is designed to transmit. If the message has
optional fields that describe properties that default for the subclasses,
then those fields should be filled with the appropriate data. (035)
If this is not what you are referring to, please clarify. It seems that
you are discussing two systems which communicate & use a standard
vocabulary for that communication, but which have different policies,
which restrict properties for various instruments which they both
control and communicate about. (036)
> Any belief that URIs and closed form definitions can magically solve
> all these problems is an illusion. (037)
Certainly, you will have definitional cycles. You can not achieve
closed-form definitions if that is your meaning here. (038)
-- doug foxvog (039)
> John (040)
_________________________________________________________________
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 (041)
|