Hello David, (01)
so we have a legacy system using a field M0760 and another using a field
MENSA-FL for essentially the same thing. The meaning of the fields is either
unclear or distributed in the heads of two experts for one or the other system. (02)
If the meaning is unclear, reasoning will not be useful. I also cannot think
of an example how reasoning could uncover the association if both experts try
to formalize some of the meaning of M0760 and MENSA-FL separately. (03)
You can convert the data to RDF in a quick and dirty way - mapping the M0760
field to a M0760 property and the MENSA-FL field to a MENSA-FL property. Now
you have the data of both systems in one queryable DB and can look for
correlations. That M0760 and MENSA-FL often or always have the same value for
the same data elements would be quite striking (this assumes that the data
elements have been mapped before). IMO, the core SW software stack does not
offer the tools to search for such correlations. But once you have discovered
that M0760 and MENSA-FL are the same, you can easily state it in RDF and let
the system generate all entailments so that regardless if you query for
M0760 or for MENSA-FL, you get the same results. (04)
The other approach would be for the experts to try to convert the knowledge
into RDF using existing vocabularies. With some luck, both experts would use
the same terms so M0760 and MENSA-FL would end as the same term from a third
vocabulary. (05)
The advantages of RDF/SW in this case are: (06)
-The ability to throw everything together and query it ad hoc (07)
-The ability to add mappings later (08)
-Shared vocabularies (09)
But of course nothing of this beats both experts getting together and having
a long talk :-) (010)
Regards, (011)
Michael Brunnbauer (012)
On Fri, Jul 26, 2013 at 08:14:05AM -0400, David Eddy wrote:
> Michael -
>
> On Jul 26, 2013, at 3:01 AM, Michael Brunnbauer wrote:
>
> > Are you refering to a specific example with those labels or are M0760 and
> > MENSA-FL just arbitrary ?
>
>
> John Sowa opened the door to the issue/opportunity/challenge of legacy
>systems & I running with it.
>
>
> One of the major challenges with legacy systems is the semantics of what
>cryptic labels actually mean. These are systems that have typically been in
>active use & modification for multiple decades.
>
> The fact that the name of something does not have to be related to the actual
>contents of the field/column/data element is another topic altogether. In an
>ideal world the name/label & the contents would be highly congruent, but often
>they're not. Separate topic.
>
>
>
> Yes... these labels (names) are 100% real.
>
> The M0760 was heritage from what I assume to have been a Fortran based system
>(this was a life insurance company where the actuarial process was the first
>to be automated with Fortran, a usage that remains to this day). In the early
>days of Fortran I believe variable names were restricted to 6 characters.
>
> This field (field = column = data element, etc.) M0760 was "obviously" from
>the Masterfile (remember those?), in the 7th segment, 60th field.
>
> I do not know if they went all the way to M9999, but the print-out of the
>file layout was 64 pages long, approximately 1700 fields.
>
>
> Decades pass, technology advances, COBOL arrives & stabilizes & now they have
>an identical master file, but with a different naming convention. Now the
>data represented by M0760 has been relabeled to MENSA-FL. (Actually it was
>MSTR-MENSA-FL, but we're going to ignore the MSTR part.) MENSA is not the
>word for smart people, but rather an acronym meaning MEssage Notify Stop
>Action FLag... a collection of dunning flags.
>
>
> In actual practice M0760 and MENSA-FL were exact equals (think base &
>displacement in a file structure), except newer programs could use the COBOL
>names, while older programs (still the same masterfile) used the M0760 style.
>
>
>
> Now... if you've gotten this far... that was just the administrivia,
>background.
>
> Now we inject the human element. I spent 6 months of my life futzing with
>this stuff. Since I was working on the new side of the system, I learned
>about MENSA-FL. A little opaque, but not too hard to memorize.
>
> But at one point I needed to consult with the SME, the expert. I chattered
>away about MENSA this & MENSA that until I noticed he was not following me.
>There was a pause. Then he offered: "Oh! You mean M0760. Now I understand
>what you're talking about."
>
> He'd been working at this firm his entire life & essentially memorized most
>of the M0101 to M9999 meanings. MENSA-FL was simply not something he
>understood.
>
>
>
> Welcome to the world of legacy systems.
>
> Now how does SW help with that sort of opaque, ugly labels issue? People
>working with legacy systems wrestle with this issue every single day. How
>does SW help?
>
> The ugly labels are not going away. On balance you cannot change them since
>people have memorized them?particularly the SMEs. These are systems that have
>decades of life under their belt & likely will survive for decades more.
>
> Is there a SW mechanism or process that speeds up the DISCOVERY process for
>newbies?
>
> - David
> (013)
>
> _________________________________________________________________
> 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
> (014)
--
++ Michael Brunnbauer
++ netEstate GmbH
++ Geisenhausener Straße 11a
++ 81379 München
++ Tel +49 89 32 19 77 80
++ Fax +49 89 32 19 77 89
++ E-Mail brunni@xxxxxxxxxxxx
++ http://www.netestate.de/
++
++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
++ USt-IdNr. DE221033342
++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel (015)
pgpO6hTSG7bYU.pgp
Description: PGP signature
_________________________________________________________________
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)
|