1. Making Sense of Design Patterns Rinke Hoekstrahoekstra@few.vu.nl, hoekstra@uva.nlJoostBreukerbreuker@science.uva.nl There must be a reason why certain patterns are more useful than others + BONUS DP!!!
2. How to build a “Good Ontology” Design principles Distinguish accidental from intrinsic properties Abstract, difficult to apply Reuse of existing ontologies Nice bootstrap, but problematic Large, heavyweight, hard to extend Design patterns Middle ground Principles as concrete building blocks
3. What’s a good Design Pattern? Categorise Logical, content, lexico-syntactic, ... Submit and Review http://ontologydesignpatterns.org Incentive to share? ... preliminary evaluation results (Blomqvist et al., 2009) Criteria Mix required metadata, with quality criteria Pros and cons, competency questions “cognitively relevant” and “best practices”
4. Linguistics “Give a muffin to a moose” vs. “Give a moose a muffin” “Biff drove the car to Chicago” vs. “Biff drove Chicago the car” Linguistic expressions follow cognitive rules (Pinker, 2007) Recurring structures in language Can be reapplied to create new meaning Signal fundamental concepts of thought “We gather our ideas, put them into words, and if our verbiage is not empty or hollow, we might get these ideas across to a listener, who can unpack our words to extract their content”
5. Design Decisions Conceptual Model Two Sides to a Coin Ontology DPs ... KADS, CommonKADS “Knowledge modelling” (van Heijst et al., ‘97) Design patterns bridge the gap they are specific to a KR language ... but commit to a conceptual model that exists independently of it
6. Fundamental Design Decision Design patterns commit to a conceptualisation express a structure in a language thereby exclude other solutions Well known commitments... Binary vs. n-ary relations (action) Relative vs. absolute (time, place) Reification vs. abstraction (roles) Are roles classes or relations?
7. Roles BONUS DP!!! Are roles classes or relations? Searle, The Structure of Social Reality, 1995 Rinke Hoekstra. Representing Social Reality in OWL 2. In EvrenSirinand Kendall Clark, ed., Proceedings of OWLED 2010, June 2010
9. Discussion Message: move beyond best practices Design patterns Capture fundamental design decisions, Recurrent structures that reflect cognitive notions Bridge the gap between conceptualization and implementation. Give insight in expert knowledge What next? Domain theories, but also linguistics and cognition Harvest recurring patterns in existing ontologies Assess tradeoffs, i.e. discover design decisions Design patterns as index to a library of ontologies
10. There’s more in the paper... Five requirements for design patterns Structure patterns ... much more detail Rinke Hoekstrahoekstra@few.vu.nl / hoekstra@uva.nl There’s also a book Rinke Hoekstra.Ontology Representation – Design Patterns and Ontologies that Make Sense. IOS Press, 2009
