One of the reasons why SQL succeeded as a database was that you can write an API to grab a metadata record out of a database. And if you change the structure of that metadata record, the API still works. That's a design issue, it strikes me, so that changing the structure of metadata should, other than the fact that we now have an additional element. And that… usually the way that's handled in an API is that you have you pass to the API, some mnemonic that indicates the data element you want to grab. So you pass a key to make sure you get to the right place in the database. And then you say, I want this… we used four character mnemonics. I want this nemonic. And then if you have a new one that gets added, then you make an update to documentation because then there's an additional thing you can do with the API. But the restructuring of the database behind it, or the file behind the API doesn't impact the functioning of the API. And that type of that type of separation of functions is one of the key aspects of structuring the system.
There was a function that you called, an API function. And that function was, I want this organization. So maybe you pass it the name of the PDF, or whatever we decide is the key, right? And then I want you to return the “LNG,” where that's the mnemonic for “language”. So the API routine says, ah, LNG, that's now in column six, or whatever. So that API can continue to evolve. But everything, that's written that's accessing the API still works. [From 3/18/22 D4G Meeting notes] |