Ontology Best Practices for Data-driven Applications: Part 1
Structured Dynamics is plowing virgin ground in how linked, structured data — powered by the flexible RDF data model — can establish new approaches useful to the enterprise. These approaches range from how applications are architected, to how data is shared and interoperated, and to how we even design and deploy applications and the data themselves.
At the core of this mindset is the concept of ‘data-driven apps‘, with their underlying structure based on ontologies. Over the coming weeks, I will be posting a series of best practices for how these ontologies can be designed, constructed and employed, and how they can shift the paradigm from static and inflexible applications to ones that are driven by the underlying data.
So, as the introduction to this occasional series, it is thus useful to define our terms and viewpoints. Clearly the two key concepts are:
- Data-driven applications — this concept means the use of generic tools, applications and services that shape themselves and expose capabilities based on the structure of their underlying data. Generic means reusable. Unlike inflexible report writers or static tools of the past, these applications present functionality and are contextual based on the structure of the underlying data they serve. The data-driven aspects results from proper construction of the ontologies that describe this underlying data
- Ontologies — ontologies have been something of a teeth-grinding concept for a couple of years, having been appropriated from their historical meaning of the nature of being (“ontos”) in philosophy to describe “shared conceptualizations” in computer science and knowledge engineering [1]. For its purposes, Structured Dynamics more precisely defines ontologies as the relationships of the concepts and domains embodied in the underlying things or instances described by the data. Under this approach, ontologies based on RDF become a structural representation of the data relationships in graph form. But, in addition, we also define ontologies to mean the proper description of these concepts, so as to supply the context, synonyms and aliases, and labels useful to human use and understanding.
We therefore put a fairly high threshold of construction and design on our ontologies. These imperatives provide the rationale for this series.
One complementary aspect to our design is the importance to get data in any form or serialization converted to the canonical RDF data model upon which the ontologies define and describe the data structure. Though crucial, this aspect is not discussed further in this series.
Now, of course, when someone (me) has the chutzpah to posit “best practices” it should also be clear as to what end. Ontologies may be used for many things. Others may have as the aim completeness of domain capture, wealth of predicates, reasoning or inference. In our sense, we define “best practices” within our focus of data interoperability and data-driven apps. Your own mileage may vary.
In no particular order and with likely new topics to emerge, here is the current listing of what some of the other parts in this occasional series will contain:
- Intro (concepts)
- ABox – TBox split
- Architecting (modularizing) ontologies into categories (e.g., UI/display of information; domains/instances; admin/internal apps)
- Definition of a standard instance record vocabulary (ABox)
- Role of an instance record vocabulary for universal struct ingest
- Selection of core external ontologies and re-use
- A deeper exploration of the data-driven application
- Initial ontology building and techniques
- Specific UI items suitable to be driven by ontologies (a listing of 20 or so items)
- Techniques for mapping to external ontologies
- Dataset interoperability and the myth that OWL is only useful for real-time reasoning, and
- OWL mapping predicates, importance of class mappings, and OWL 2.
The idea throughout this series is to document best practices as encountered. We certainly do not claim completeness on these matters, but we also assert that good upfront design can deliver many free backend benefits.
If there is a particular topic missing from above that you would like us to discuss, please fire away! In any event, we will be giving you our best thinking on these topics over the coming weeks and how they might be important to you.
