On Aug 30, 2012, at 9:55 PM, Paul Tyson wrote:
I guess that bit of intelligence hasn't reached those who are busy
putting semantic facades on all sorts of old data:
I should have been semantically precise (I thought you could read my intentions)... I'm not concerned with the DATA, since obviously plenty of people have their eyes on that ball. I'm talking about the systems themselves... the software that makes up the systems.
Software (with all sorts of hopefully useful "business rules") + data = "" useful (hopefully).
Not interested in the sexy sheet metal... interested in the snorting V12, 48 DOHC engine hidden under the hood.
Not interested in the delicious sausage... interested in the messy process that makes the sausage.
This is a yin & yang, heads & tails sort of thing... you really can't have one without the other.
The "data" I'm interested in is something like WEEKLY-PAY = HOURS-WKD * PAY-RATE (or weeklyPay = hoursWorked * payRate if you're from the camelCase generation). Don't I wish code were that readable.
I'm thinking of the semantic challenge of an insurance company that has 70+ different names for the core concept "policy number" in its schemas. Virtually all companies depend on the wet ware SMEs (subject matter experts) to make sense of such chaos. What happens when these SMEs are not available?
Depending on your age... were you aware that 500 (50%) of Social Security Administration's COBOL programmers will be eligible to retire by 2015.
How's the semantic stack going to help with that sort of brain drain?