The document discusses design patterns for ontologies. It notes that certain patterns are more useful than others and that design patterns can capture fundamental design decisions and recurrent structures that reflect cognitive notions. Design patterns can bridge the gap between conceptual models and implementation and provide insights into expert knowledge. The document advocates moving beyond best practices to analyze design decisions in existing ontologies and assessing tradeoffs to discover more patterns.

1. Making Sense of Design PatternsRinke Hoekstrahoekstra@few.vu.nl, hoekstra@uva.nlJoostBreukerbreuker@science.uva.nlThere must be a reason why certain patterns are more useful than others+ BONUS DP!!!

2. How to build a “Good Ontology”Design principlesDistinguish accidental from intrinsic propertiesAbstract, difficult to applyReuse of existing ontologiesNice bootstrap, but problematicLarge, heavyweight, hard to extendDesign patternsMiddle groundPrinciples as concrete building blocks

3. What’s a good Design Pattern?CategoriseLogical, content, lexico-syntactic, ...Submit and Reviewhttp://ontologydesignpatterns.orgIncentive to share?... preliminary evaluation results (Blomqvist et al., 2009)CriteriaMix required metadata, with quality criteriaPros 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 languageCan be reapplied to create new meaningSignal 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 DecisionsConceptual ModelTwo Sides to a CoinOntologyDPs... KADS, CommonKADS“Knowledge modelling” (van Heijst et al., ‘97)Design patterns bridge the gapthey are specific to a KR language... but commit to a conceptual model that exists independently of it

6. Fundamental Design DecisionDesign patternscommit to a conceptualisationexpress a structure in a languagethereby exclude other solutionsWell known commitments...Binary vs. n-ary relations (action)Relative vs. absolute (time, place)Reification vs. abstraction (roles)Are roles classes or relations?

7. RolesBONUS DP!!!Are roles classes or relations?Searle, The Structure of Social Reality, 1995Rinke Hoekstra. Representing Social Reality in OWL 2. In EvrenSirinand Kendall Clark, ed., Proceedings of OWLED 2010, June 2010

8. It’s like Legotm!

9. DiscussionMessage: move beyond best practicesDesign patternsCapture fundamental design decisions, Recurrent structures that reflect cognitive notionsBridge the gap between conceptualization and implementation.Give insight in expert knowledgeWhat next?Domain theories, but also linguistics and cognitionHarvest recurring patterns in existing ontologiesAssess tradeoffs, i.e. discover design decisionsDesign patterns as index to a library of ontologies

10. There’s more in the paper...Five requirements for design patternsStructure patterns... much more detailRinke Hoekstrahoekstra@few.vu.nl / hoekstra@uva.nlThere’s also a book Rinke Hoekstra.Ontology Representation – Design Patterns and Ontologies that Make Sense. IOS Press, 2009