About the impedance mismatch between object-oriented languages and semantic technologies.

1. Impedance mismatch 2.0 BouvetOne 2010-01-28 Lars Marius Garshol, <larsga@bouvet.no>

2. Impedance mismatch 1.0 Java objects Tables ? Objects and relations have different structures causes lots of extra development work a well-understood problem today

3. Impedance mismatch 2.0 ? Objects and semantic technologies have the same issue this is not well understood, however...

4. And the solution is...? I don’t suggest that I have it what I am suggesting is that we need to think more seriously about this problem This talk sketches some approaches I would be very interested in feedback on them

5. Some important concerns Whipuptitude how easy it is to get something up and running Manipulexity how complicated data/interface you can handle Knowledge of TMs is it possible to shield some developers from TMs? Testability how easy is it to do automated testing? Flexibility how hard is it to change the application?

6. The one-layer approach JSP JSP JSP Write lots of JSPs put your queries in the JSPs off you go Messy, but effective high whipuptitude, but brittle limited manipulexity usually lots of boilerplate code Difficult to test

7. Write a domain model JSP Domain model JSP JSP Write a domain model put as much business logic as possible inside hide all Topic Maps queries in it then build JSPs as a thin layer on top Scales to higher manipulexity much easier to test public class Person { public String getName(); public String getEmail(); public Date getDateOfBirth(); // ... }

8. But... Very low whipuptitude takes a while to figure out how to approach writing this code lots of scaffolding to do before you get started Wasn’t one of the benefits of TMs flexibility? now any ontology change has to be followed by an update to the domain model this is slow and a lot of work compared to an RDBMS and an OR-mapper, is this really any faster?

9. Generate a domain model JSP Generated domain model JSP Custom code JSP Use a tool that generates the model obviously, it must allow custom extensions saves effort by avoiding most of the routine work business logic still has to be written manually Scales to even higher manipulexity whipuptitude no longer quite so bad http://www.networkedplanet.com/ontopic/2007/07/topic_map_objects_research_pap.html

10. To make this work... Use schema + annotations as input also conventions instead of config, where possible allow ontology annotations to provide additional generated business logic, where possible (.NET allows partial classes, avoiding subclassing) Generated code not to be edited all custom logic in separate subclasses Might be able to use tolog rules to implement some of the business logic without Java

11. A portlet approach JSP TreePortlet JSP RelatedTopics JSP TopicList Use generic components for display at least as far as possible these rely on configuration and ontology annotation note: components reflect interface, not the domain Enormous whipuptitude manipulexity probably limited

12. Ontology changes All applications have some ontology expectations however, using a generic approach these can be minimized sometimes to the point where no code changes are required for certain ontology changes However, this requires the use of generic components usually also requires some forethought with a traditional domain model this is not really possible

13. Evaluation whipuptitude Generic portlets One-layer approach Generated domain model Self-written domain model manipulexity

14. But what do you think? Would any of these approaches really solve the problem? Do we need more? Do we need something entirely different?