Contrary to popular belief in some circles, formal semantics are not a silver bullet. Just because a construct in a knowledge representation language is prescribed a behavior using formal semantics does not necessarily mean that people will follow those semantics when actually using that language “in the wild.” This can be laid down to a wide variety of reasons. In particular, the language may not provide the facilities needed by people as they actually try to encode knowledge, so they may use a construct that seems close enough to their desired one. A combination of not reading specifications - especially formal semantics, which even most software developers and engineers lack training in - and the labeling of constructs with “English-like” mnemonics naturally will lead to the use of a knowledge representation language by actual users that varies from what its designers intended.A variant of this subject also came up in the opening keynote address (From Artwork to Cyber Attacks) at the US. Semantics Symposium 2018 held last week at Wright State University. Craig Knoblock (USC Information Sciences Institute) gave the keynote and said that the mapping of information in the American Art Collaborative Project (slides 32-38) was difficult due to the various interpretations that different students applied to the backing ontology. Although the students who mapped the data all used the CIDOC CRM cultural heritage ontology, at the end of the day, there was much clean-up and coordination required. On slide 35, the statistics are reviewed - although only 76 files were mapped, there were 4636 commits required to get consistency!
So, clearly there is a problem. To solve it, I have started applying Ontology Design Patterns (ODPs) to define a consistent interpretation and usage of one or more ontologies for an application. I have found that ODPs are not just for ontology development and reuse!
The list below shows the information that I include in an ODP to inform people/teams that are using ontologies to define consistent semantics for their data:
- Description of why the pattern is needed and what problems are being solved - This includes:
- A short statement describing what the pattern is used for and/or what is being mapped
- The considerations that influenced the pattern or required the pattern to be created - for example:
- When defining whole-part relationships, how deeply should the mereology hierarchy go?
- What is needed to identify "the same" individuals?
- How to determine the most appropriate type(s) for an individual?
- What meta-data is needed?
- Design sources for the ODP (this is not be needed if the source is a single ontology)
- High level (block) diagram of the main concepts and relationships in the ODP
- Overview of each of the concepts/classes and relationships shown in the block diagram, as well as important sub-classes and sub-properties
- Include in the overview or in another section of the ODP any differences in approaches - for example, why a detailed class hierarchy might be used in one place but not in another
- Class and property diagrams related to the overview-ed classes and properties (such as can be generated by OntoGraph)
- Information on using the ODP
- One or more examples illustrating the use of the ODP, along with instance/individual diagrams
- A list of competency questions with SPARQL queries representing the questions
- The results of applying the queries to the examples generated above (this step then also provides a set of test cases to gauge conformance)
P.S. If you aren't sure what competency questions are, please see the blog post, Breaking Down the "Documents and Policies" Project.
Andrea
Posts
