Impedance Mismatch 2.0


Published on

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

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Impedance Mismatch 2.0

  1. 1. Impedance mismatch 2.0<br />BouvetOne 2010-01-28<br />Lars Marius Garshol, &lt;;<br />
  2. 2. Impedance mismatch 1.0<br />Java objects<br />Tables<br />?<br />Objects and relations have different structures<br />causes lots of extra development work<br />a well-understood problem today<br />
  3. 3. Impedance mismatch 2.0<br />?<br />Objects and semantic technologies have the same issue<br />this is not well understood, however...<br />
  4. 4. And the solution is...?<br />I don’t suggest that I have it<br />what I am suggesting is that we need to think more seriously about this problem<br />This talk sketches some approaches<br />I would be very interested in feedback on them<br />
  5. 5. Some important concerns<br />Whipuptitude<br />how easy it is to get something up and running<br />Manipulexity<br />how complicated data/interface you can handle<br />Knowledge of TMs<br />is it possible to shield some developers from TMs?<br />Testability<br />how easy is it to do automated testing?<br />Flexibility<br />how hard is it to change the application?<br />
  6. 6. The one-layer approach<br />JSP<br />JSP<br />JSP<br />Write lots of JSPs<br />put your queries in the JSPs<br />off you go<br />Messy, but effective<br />high whipuptitude, but brittle<br />limited manipulexity<br />usually lots of boilerplate code<br />Difficult to test<br />
  7. 7. Write a domain model<br />JSP<br />Domain model<br />JSP<br />JSP<br />Write a domain model<br />put as much business logic as possible inside<br />hide all Topic Maps queries in it<br />then build JSPs as a thin layer on top<br />Scales to higher manipulexity<br />much easier to test<br />public class Person {<br /> public String getName();<br /> public String getEmail();<br /> public Date getDateOfBirth();<br /> // ...<br />}<br />
  8. 8. But...<br />Very low whipuptitude<br />takes a while to figure out how to approach writing this code<br />lots of scaffolding to do before you get started<br />Wasn’t one of the benefits of TMs flexibility?<br />now any ontology change has to be followed by an update to the domain model<br />this is slow and a lot of work<br />compared to an RDBMS and an OR-mapper, is this really any faster?<br />
  9. 9. Generate a domain model<br />JSP<br />Generated domain model<br />JSP<br />Custom code<br />JSP<br />Use a tool that generates the model<br />obviously, it must allow custom extensions<br />saves effort by avoiding most of the routine work<br />business logic still has to be written manually<br />Scales to even higher manipulexity<br />whipuptitude no longer quite so bad<br /><br />
  10. 10. To make this work...<br />Use schema + annotations as input<br />also conventions instead of config, where possible<br />allow ontology annotations to provide additional generated business logic, where possible<br />(.NET allows partial classes, avoiding subclassing)<br />Generated code not to be edited<br />all custom logic in separate subclasses<br />Might be able to use tolog rules to implement some of the business logic without Java<br />
  11. 11. A portlet approach<br />JSP<br />TreePortlet<br />JSP<br />RelatedTopics<br />JSP<br />TopicList<br />Use generic components for display<br />at least as far as possible<br />these rely on configuration and ontology annotation<br />note: components reflect interface, not the domain<br />Enormous whipuptitude<br />manipulexity probably limited<br />
  12. 12. Ontology changes<br />All applications have some ontology expectations<br />however, using a generic approach these can be minimized<br />sometimes to the point where no code changes are required for certain ontology changes<br />However, this requires the use of generic components<br />usually also requires some forethought<br />with a traditional domain model this is not really possible<br />
  13. 13. Evaluation<br />whipuptitude<br />Generic<br />portlets<br />One-layer<br />approach<br />Generated domain model<br />Self-written domain model<br />manipulexity<br />
  14. 14. But what do you think?<br />Would any of these approaches really solve the problem?<br />Do we need more?<br />Do we need something entirely different?<br />