Hi Ron,
Comments below,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ron Wheeler
Sent: Friday, January 07, 2011
11:12 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum]
Modeling a money transferring scenario
On 07/01/2011 1:56 PM,
Rich Cooper wrote:
Hi Ron,
I got this snippet from
GoodRelations at the URL you gave:
GoodRelations is a language that can be used to describe very precisely what your business is offering. Some people call
GoodRelations a "data dictionary", others prefer "schema"
or "ontology". The name, however, is not important. Important is that
you can use GoodRelations to create a small data package that describes your products and their features and prices, your stores
and opening hours, payment options
and the like.
You simply paste this data package into
your Web page using W3C's RDFa format. That's all!
That sounds like good
news in itself! However, the point I was trying to raise is that, AFTER
formalizing each column on the form, new thoughts, products, requests,
opportunities, special purchases, and a zillion other unplanned things can and
ALWAYS do happen to a business. Every business is a moving target, adapting
shifting and changing to the economic variances they cannot control but can
manage through better records.
The problem is that the
standards (Good Relations as well as others) cant possibly predefine every
contingency that a business finds itself in. The business with a fixed
offering and a fixed customer base has a fixed lifetime before new methods,
technologies and players enter the same market. The change is rapid and
intense.
Summary: every business
IT system changes faster than the database modeling crew can anticipate.
Therefore there are always loose text fields for comments, descriptions,
CRM relationships, delivery methods and dates, and all kinds of other
uncontrollable, changing situations in the environment.
Some
of these will migrate into more tightly defined objects as their true nature
becomes clearer and the desire to apply automated rules exceeds the desire for
flexibility.
Sometimes the list of allowed values (say for delivery method) will include
"other" which will trigger a manual process and human intervention in
an otherwise automated process.
Businesses have lots of
text in their databases. What can be done with that text?
Nothing
wrong with text fields except that they can not be processed automatically (or
sometimes even manually). People got fevers and doctors treated them long
before we had thermometers but no one is going to want to replace "Patient
temp =103.2" with "patient was noticeably warm".
Actually, text fields CAN be processed and
used to discover concepts in the database that were not anticipated in the data
model. The data model is at best an abstraction of what goes on in the
business, meaning it generalizes (leaves out) a lot of important information
about how the business and its employees perceive and do relevant tasks.
For more on how to process those text
strings, getting information from them through analysis and discovery
processes, see the document at
www.Englishlogickernel.com/patent-7-209-923-B1.PDF
You can also download the Elk for Patents
software on that web site and use it to show yourself how claim language
elements can be correlated with the specifications for each patent.
Text is often very recoverable, and it
need not even be correct or clear English to contain valuable information about
the business.
JMHO,
-Rich
Ron
-Rich
Sincerely,
Rich
Cooper
EnglishLogicKernel.com
Rich
AT EnglishLogicKernel DOT com
9
4 9 \ 5 2 5 - 5 7 1 2
Does this answer any of
the questions about invoices, customers, etc.
http://www.heppnetz.de/projects/goodrelations/
Ron
On 07/01/2011 9:44 AM, Zhuk, Yefim wrote:
Rich,
Most
of these items are pre-defined types that have type ID or abbreviated names in
the data records.
Unstructured
text fields in our data records are more exceptions than the rule.
I
think we’ve switched from the main subject of the forum and maybe at this
point can communicate directly.
With
my greatest respect,
Yefim
(Jeff)
Yefim,
How do you handle line
item descriptions on invoices, discounts for specified customers, special price
events, labor tracking by product-customer-activity, or other
unstructured text fields?
Curiously,
-Rich
Sincerely,
Rich
Cooper
EnglishLogicKernel.com
Rich
AT EnglishLogicKernel DOT com
9
4 9 \ 5 2 5 - 5 7 1 2
Rich,
In
our world most of actual data records are filled in with the numbers (very little
if not zero semantic value) but this can be different for other companies where
your methodology would make a lot of sense.
Thank
you for clarifications,
Yefim
(Jeff)
Hi Yefim,
I wasn't suggesting the data model
be analyzed and reused - though fragments of that model could be clustered and
usefully employed.
Instead, look at the actual data
itself, the zillions of rows that got actually stored in each column by people
who were trying to designate some aspect of reality to the
<computer/reader/analysts>. Look for ways to leverage the domains
as actually experienced.
The data model describes
the programmers' view, but the actual data comprise the users' views. Not
what was asked for, but what was given in response to each domain as presented
to the users during the lifetime of the old database.
Most system data models
in need of a major upgrade are old, and need to be reworked, split, enhanced or
even scrapped completely. But the experience of the people who used the
system, and the experience of those that <managed/used/analyzed> the
system, is to some extent preserved in their language as used in the actual data.
People responded to the
old system by attempting to record and designate things that, while not
requested specifically, were important enough for them to record. Those
concepts are in the unstructured text columns from the database, and even from
some of the structured columns where multiple interpretations were rife.
The collection of those
experienced concepts should be at least considered for the next generation of
system development, which will likely have some semantic content, even if
limited by the short steps we know how to take into semantics.
One useful thing to do is
to list the concepts you recognize in the database, and use it to guide writing
the requirements document so you can test for completeness or conformance with
known experiences.
HTH,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT
EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
-----Original
Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Zhuk, Yefim
Sent: Thursday, January 06, 2011 2:26 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Modeling a money transferring scenario
Rich,
Thank you so much for
your response and very interesting recommendations.
When we just started, we
thought about using data models as an initial point for ontology development.
It didn't work exactly as we planned. One of the reasons was that data models
only represent some pieces of information, while some other pieces and
relationships are captured by business logics in the applications.
Only after we've built
some initial ontology skeleton, we were able to benefit from the
synchronization between the data and ontology models. This is two-directional
process. It's a manual process so far, as initial data design didn't have in
mind to bring up semantic values.
I think that to elevate
information to the knowledge level, we not only need better algorithms,
standards and tools. One of the first steps is to improve the culture of
capturing data in the first place. If we want computers to understand
information, we need to be more precise and semantically rich in expressing
this information.
Then, your methodology
and algorithms would work much more efficiently on databases created by a new school of DBAs.
Thank you again,
Yefim (Jeff)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Rich Cooper
Sent: Thursday, January
06, 2011 4:05 PM
To: '[ontolog-forum] '
Subject: Re:
[ontolog-forum] Modeling a money transferring scenario
Hi Yefim,
Do you have history
databases (preferably large ones) with the data
available for
examination? You can detect relationships among the columns
by partitioning the
column data values into groups with similarities in
syntax and/or semantics.
One way to do this is just to sort the column
values, then group the
ones that are identical. That reduces the variety by
the incidence factor.
Then find groups with identical signatures, using
various templates to
generalize or specialize each template from each group
of values.
Iterate until the classes
and relationships are known better. THEN develop
an ontology that covers
at LEAST those explicit examples, handling each one
in a responsive way.
Take a look at
www.Englishlogickernel.com/patent-7-209-923-B1.PDF
(copy and paste into your
browser URL slot)
The specification
describes a way to discover the existing classes and
relationships among the
transactions you know are really being performed.
At least that way your
ontology will start with conformance to actual needs,
and you can add lots of
ornaments as you wish. You can theorize about the
data, experiment to see
if your theories are valid, classify more deeply
based on the column value
differences within each class, and observe the way
data was entered by the
very people who will enter data into your new
ontology.
To discover classes and
relationships among patent documents as an example,
use the free downloadable
Elk for Patents program suite.
HTH,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT
EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Zhuk, Yefim
Sent: Thursday, January
06, 2011 12:33 PM
To: [ontolog-forum]
Subject: Re:
[ontolog-forum] Modeling a money transferring scenario
I can share some initial
steps of working on the Loan ontology at Sallie Mae
and participating in the
collaborative work on financial ontology together
with EDMC and some other
institutions.
1. Start with the main
classes and subclasses like:
Actor (Customer,
Borrower, etc.)
Event
(FinancialTransaction, etc.)
Account (CheckingAccount,
CreditAccount, etc.)
Currency (USD, etc.)
2. Start establishing
relationships between the classes:
Customer transfers
Currency to CheckingAccount
3. Create the rules to
determine anomalies, fraud issues, etc.
If ....
-------------------
While creating the rules,
you realize that you need to add and to change
your ontology.
Do this.
Remember, that you create
your ontology for a specific purpose, so make the
closest loop to check if
this purpose is met.
Hope, this helps you
started,
Yefim (Jeff)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Selcuk Bozdag
Sent: Thursday, January
06, 2011 7:29 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: [ontolog-forum]
Modeling a money transferring scenario
Hi ontologs,
I would like to get your
ideas about modeling a financial
organization's (e.g. a
bank) money transaction ontology using OWL
(1). Suppose that a bank
wants to track the accounts of the customers
in order to determine
anomalies, fraud issues or just to ensure that
everything is OK at the
end of the day. I have come up with a solution
which caused a discussion
among my colleagues mostly ended with a
disagreement. Right below
I am giving only a clipped portion of the
draft ontology at a
glance.
The absolute classes(i.e.
concepts) are Bank, Money, Customer and
Account. When it comes to
represent a money transfer between two
accounts, I suggested to
create another class named "MoneyTransfer" on
which one can create
object properties such as transferDate, amount
etc. On the flip side,
others put the MoneyTransfer class aside and
preferred to create an
object property named "transfersMoney" which
has a domain and range of
Account. However it is obvious that
transfersMoney property
is just a relation between to individuals
representing none of the
date and amount information.
I would greatly
appreciate if you could explain your point of view and
show me what the
alternatives could possibly be. I also would be
thankful if you refer any
other ontology regarding that issue.
Cheers,
Selcuk
________________________________________