Rich -On Feb 26, 2012, at 12:19 PM, Rich Cooper wrote: All financial justification is from the application up, not from the philosophy down.
We're a choir... probably of two.
I suspect it would be quite easy to prove the financial benefit.
Take the same difficult-to-understand code & have two similarly experienced programmers, with no knowledge of this code, make changes.
Only difference is that Programmer A has to figure out the language themselves, while Programmer B has a language list/lexicon/ontology/cheat sheet/dictionary/glossary that explains what the cryptic language means.
Without even doing the experiment you know Programmer B has a huge advantage.
Let's see... neither you nor I read French. We're both given a document to translate. You do not have a dictionary. I do. Who wins?
The only difference is the cost of providing the language list in an accessible form... but amortized over 20-30 years, that cost goes close to zero. Besides, we're only dealing with at the outside maybe 1000 terms for a large application.
The interesting challenge is how to discover the core application language as expressed in COBOL, EasyTrieve, Focus, BAL, etc. & make it available to the Java, JSON, Objective-C, PHP, Perl, etc. generation of programmers. I would argue that the new generation of programmers is juggling new labels, not new data. May come as a revelation that soc_sec_no and socialSecurityNumber just might possibly represent the same thing?
That is why Dublin Core succeeded. It is small, very simple, well documented, and matched by large hunks of examples that describe document provenance within its limits. In that sense, Dublin Core is a new legacy just as the software which interfaces with it might be a legacy database.
One thing that distresses me about Dublin Core is that to the best of what I've been able to find (it is a big world), Dublin Core does not regard software source code as a document. Best I've been able to find is that if the source code were printed out—huh? WHY would you do that?—then it would be a document. I haven't been able to figure that out. If on paper its a document, if just electrons then not. If useless, then document. If useful, not document.
Yes, software does have its odd/unique/strange properties, but it's not that unique. Author(s), Date created, Date last maintained. Most of the 15 DCMI attributes look directly useful for keeping track of software. The trick, of course, is what values actually go into the attributes. How can that be automated?
___________________ David Eddy
781-455-0949 |