For many in the traditional applications development community, “semantics” sounds like a perfect candidate for a buzzword tossed at management in an effort to pry fresh funding for what may appear to be academic projects with not much discernible practical payback. Indeed when challenged for examples of “semantic applications” often one hears stumbling litanies about “Linked Open Data”, ubiquitous “URLs” and “statement triples”.
For many in the traditional applications development community, “semantics” sounds like a perfect candidate for a buzzword tossed at management in an effort to pry fresh funding for what may appear to be academic projects with not much discernible practical payback. Indeed when challenged for examples of “semantic applications” often one hears stumbling litanies about “Linked Open Data”, ubiquitous “URLs” and “statement triples”. Traditional database folks might then retort where’s the beef? because URLs in web applications are certainly just as ubiquitous, are stored in database columns which are named just as “semantic properties” are; are in rows with foreign keys as construable as “subjects” in a standard semantic statement; and that’s still not to mention the many, many other SQL tools in which enterprises have heavily, heavily invested over many, many years! So…
It’s a good question – where IS the beef?
The Object Management Group (OMG), a highly respected standards organization with outsized impacts on many enterprises, has recently released a revision of its Semantics of Business Vocabulary and Rules (SBVR) that provides one clear answer to this important question.
Before we go there, let’s stipulate that for relatively straight-forward (but nonetheless closed world) applications, it’s probably not worth the time nor expense to ‘semanticize’ the application and its associated database. These are applications that have few database tables; that change at a low rate; that have fairly simple forms-based user interfaces, if any; and that are often connected through transaction queues with an enterprise’s complex of applications. For these, fine, exclude them from projects migrating an enterprise to a semantic-processing orientation.
Another genre of applications are those said ‘mission critical’. These applications are characterized by a large number of database tables and consequently a large number of columns and datatypes the application needs to juggle. These applications have moderate to high rates of change to accommodate functional requirements due to shifting (and new additions to) of dynamic enterprises — not so much mission creep as it is the normal response to the tempo of the competitive environments in which enterprises exist.
The fact is that the physical schema for a triples-based (or quad-based) semantic database does not change; the physical schema is static. Rather, it’s the ontology, the logical database schema, that changes to meet new requirements of the enterprise. This is an important outcome of a re-engineered applications development process: this eliminates often costly tasks associated with designing, configuring and deploying physical schema.
Traditionalists might view this shift as mere cleverness, one equally accomplished by tools which transform logical database designs into physical database schema. Personally I don’t have the background to debate the effectiveness of these tools. However, let’s take a larger view, one suggested by the OMG specification for Business Vocabularies and Rules.
Business Policies – where it begins, and will end
Classically business management establishes policies which are sent to an Information Technology department for incorporation to new and existing applications. It is then the job of systems analysts to stare at these goats and translate them into coding specifications for development and testing. Agile and other methodologies help speed this process internally to the IT department, however until the fundamental dynamic between management and IT changes, this cycle remains slow, costly and mistake-prone.
Now this is where OMG’s SBVR applies: it is an ontology for capturing rules such as “If A, then thou shalt not do X when Y or Z applies; otherwise thou shalt do B and C” into a machine-processable form (that is, into semantic statements). Initially suitably trained system analysts draft these statements as well as pertinent queries which are to be performed by applications at the proper moment. However at some point tools will appear that permit management themselves to draft and test the impact of new and changed policies against live databases.
This is real business process re-engineering at its brightest. Policy implementation and operational costs are affected as the same language (a somewhat ‘structured English’) is used to state what should and must be as that used to state what is. Without that common language, enterprises can only rely on the skills of systems analysts to adequately communicate business, and regulatory, requirements to others.
Capturing & weaving unstructured lexical information into enterprise applications, has never been possible with traditional databases. This is why ‘semantics’ is such a big deal.
image: vocabularies/shutterstock