De-geeking Data-model Descriptions
Creating an ontological model invariably involves a subject-matter-expert (SME) who has an in-depth knowledge of the domain to be modelled working together with a data modeler or ontologist who will translate the domain into an ontological model.
When a subject-matter-expert (SME) is in discussion with a data modeler, they will be describing their information using English language:
“I have customers who are assigned to regions, and they create orders with a salesperson who prepares the order-details and assigns a shipper that operates in that region”
In response a data modeler will offer the subject-matter-expert (SME) an E-R diagram or an ontology graph!
No wonder we are regarded as geeks! Although visually appealing, they are difficult for an untrained user to verify the model that the diagram is describing.
Instead we could document the model in a more easily consumed way with a ‘word-model’. This captures the same details of the model that are present in the various diagrams, but uses structured English and careful formatting as shown below.
The basic principle is that we start at any entity, in this case ‘Customer’ and traverse the edges of the graph that describe that entity. At each new node we indent. Each line is a combination of the predicate and range class. No rules regarding order in which we visit the nodes and edges. No rules regarding depth. The only rule should be that, if we want a complete word-model, the description traverses all edges in one direction or the other.
These word-models are useful in the model design phase, as they are easy to document using any editor. Since the word-model is in ‘plain English’, it is easy for a SME to verify the accuracy of the model, and mark up with comments and edits. However word-models are also easy to generate from an RDF/OWL model.
Full details of how word-models are used and how they can be autogenerated can be found here: De-geeking Data-model Descriptions
Hi Peter. What goes around, comes around. This is pretty much the Gellish (General Engineering Language) concept applied on top of the original STEP generic models, which morphed into Template Mappings with business-user friendly names. The simplifying de-geeking aims tended to get trampled in the latest implementation technology "churn" by each new wave of geeks ;-) A natural language pseudo-code. Good to see.
A simple example which I have seen is exemplified by "and that is managed by employee" when the business wanted to outsource the management of orders and suddenly had to rebuild the model because employees were "shared" and integrated in a way that did not work when it was no longer an employee. You end with some very strange results.
I have used this model in the past. And I have sort of left it behind because it is still not understood by most of my customers. It sounds all English-like, and one would think it would be helpful. But I have found it is not so. I even used it to provide models to development teams so they could encode the results. The end is never quite exactly what is desired. The end result has so much "encoded structure" that the systems become brittle and fracture when change is requested. I still find use for it in specific scenarios, but this kind of description has been available in tools for over 15 years. It is still too "geeky" for the customer, who often does not even understand why you need to define these things in a system.
You can also take the reverse tack and create requirements that describe this as standard requirements documenting practice, either verbally or activity diagram or both. Ontologies can then check for noun/adjective coverage across the requirements
Good catch. These are an unfortunate side effect of the generator which will traverse arcs again if they are in different branches. They should be pruned. However in the blog the examples do not include such repetition.