Lifecycle Support for Networked Ontologies

1. Lifecycle Support for Networked Ontologies The NeOn Team Luxembourg, 25 May 2005

2. Economic and socio-technical background • Closed Applications  Open Applications • Key is the ability to handle large quantities of heterogeneous data in dynamic networked environments • Data integration and maintenance the key barrier to large-scale development of applications on the (open) web • Ontologies – enablers of large scale data integration • Predicted markets: from $2billion now  $63billion in 2010 • Opportunity • build systems exhibiting a level of complexity qualitatively superior to the current generation of semantic systems, by integrating large, reusable semantic resources. • Challenge • current methodologies and technologies are simply not sophisticated enough to support the whole application development lifecycle for the envisaged applications Question 1

3. Concrete contributions • System-level contributions = methodology, architecture, toolkit • for managing the complete lifecycle of networked ontologies, meta-data and contexts associated with them • open, robust, scalable,service-centredreference architecture • the NeOn toolkit for working with networked ontologies • Contributions to foundational research = methods & tools • for managing with dynamic, evolving, possibly inconsistent and contextually grounded networked ontologies • supporting large-scale collaborative development, taking into account consensus, communal trust and group context • Also… • Sector-level contributions: • Three truly innovative testbeds in two sectors • Community-level contributions: • Creation of an active and live community of users and developers Questions 1, 2, 9

4. Worst case: no NeOn project • Missed opportunity to achieve a major competitive advantage over US in scalable, open semantic solutions • We are already ahead of US in this area • …but no major effort on ontology infrastructure • which is the key area… • …also no NeOn implies no major ‘leap forward’ • …and stagnation means losing competitiveness • We are already experiencing a ‘software crisis’ • Systems are isolated, small-scale and closed • …and this will get worse • Key technology push towards “EU to become most competitive knowledge-based economy of the world by 2010” will not take place Question 1

5. Reducing budget = reducing thrust • Very strong track record in implementing concrete solutions • NeOn budget carefully worked out  we believe it provides good value for money • A €15M project, returning 1,640 person-months, for a €10.6M EU investment (request for funding from EC is 69.1% p.65) • Frequent failures of software projects due to budget underestimation • 5% funding reduction: • Across the board hit increases the risk of not achieving quality • 10% funding reduction • Re-focusing effort and shelving some competitive advantages Question 1

6. Ambitions, visions, impact areas • Technology-level • NeOn as a bootstrapping means to foster sustainable innovation • Raise awareness of IT industry of semantic and NeOn technologies …and address the inflated expectations on ‘intelligent’ technologies • Market-level • Improve and scale business in semantic technologies • Transplant lessons learnt from NeOn cases to other sectors • Capture a share of market in ontology engineering tools and in development of large-scale ontology-driven semantic applications • Achieve critical mass of impact ‘catalysers’, esp. among key players • Impact and Measures of Success  see detailed Measures • NeOn Reference Architecture and methodology de facto standard • Research uptake and dissemination • Contribution to knowledge systems markets Questions 2, 3, 5

7. NeOn beyond the NeOn project • “NeOn.org” … a foundation and developers community • overseeing reference architecture, its future developments and co-ordination of the activities of NeOn community (fully supported by all partners) • “NeOn.com” … a spin-off company or partnership • jointly exploiting the core of NeOn technology & infrastructure • “*.com” … individual/private enterprises • mainly existing commercial partners marketing their own products • using specific parts or modules from NeOn infrastructure or architecture • …in short, learn from Apache (esp.), but also Mozilla, Jabber,… • Implications on Licensing Policy: • NeOn toolkit and reference architecture available as Open Source • linkages to commercial back-ends and processes (Software AG’s EII) • support for third-party extensions through compliance to standards • additional (paid-for) functionalities for ontology management Questions 5, 6, 7

8. ‘Competitive’ environment (Protégé) • NeOn – replacement for Protégé • Appropriate a share of Protégé 3.5k developers and 11k users • More psychological decision than technical, but… • Protégé is the preferred tool only for ontology & KB population • Users prefer other tools to design ontologies, collaborate and infer rules • First-hand experience from various mailing lists: • Protégé’s support for large (e.g. NCI) or detailed ontologies (e.g. DOLCE) and reasoning is insufficient (See extracts from mailing lists in the notes) • Steep learning curve and many practical features missing • Basically, an editing environment that is continuously extended • NeOn – a one-stop shop for ontology design, mapping & contextual adaptation • Plug-in reference architecture to enable wider uptake • What is at the core of NeOn  see "beyond feature comparison" Questions 8, 9

9. ‘Competitive’ environment (*Cyc, IBM) • Cyc’s SKSI aims at similar market segment • Enable Cyc KB-s to integrate external knowledge sources • Focus on mapping of schemas (incl. translation, dependency,…) • Draw on multiple sources to answer queries (‘middleware’) • Contextual inconsistencies in integrated KB-s, evolving mappings… • OpenCyc vs. ResearchCyc vs. [Full]Cyc = different niches: • Usability / user friendliness of *Cyc… • Halo competition provides some insights: • OntoStudio more efficient than Cyc without sophisticated model • Cyc focuses on large number of instances  is this the issue for industrial-strength support for ontology design and use? • IBM’s SnoBase, Ontology Managing Tool, etc. • Different playing field, very simple functionality, basic user needs • Shows the need for usable, user-friendly systems • Usability IS the key strategic need for NeOn! Question 10

10. Existing ‘collaborative’ environment • Reuse not reinvent – learn from SEKT, KnowledgeWeb (but also Dot.KoM, AKT, DIP, etc….) • NeOn starts where these projects plan to stop • …adding the networked and contextual dimensions • …tackling integration and infrastructure seriously • Specific results we will build on are included in the notes • For example, ontology construction/extraction Re: Ontology learning, acquisition, population • NeOn is not primarily about learning or extracting ontologies • Pragmatic stance: put existing methods in practice …however, learning relates to context building, e.g. • in terms of predicting structural evolutionary changes (WP1) • in terms of generalizing from user level to communities (WP2) Questions 4, 11, 13

11. How NeOn works… (technical clarifications) Re: Modularity and plug-ins • NeOn focusing on “design” end of app lifecycle • Complements foci of “use” oriented projects (X-Media, MIAKT) • NeOn’s offering orthogonal to others  they may both use NeOn as reference platform and contribute with special purpose plug-in modules Re: Representation formalisms • OWL and F-logic + open to lightweight DL languages that have log-space worst case complexity  query instances & model relations! • Service-oriented architecture  translation between languages Re: Context and its representation schemas • Logic-based approaches [Guha & McCarthy, C-OWL] vs. probabilistic approaches • Hybridization might be a way to achieve ‘good enough’ yet scalable solutions • Deliver flexibility and handle inconsistencies (in networked ontologies and in perspectives of different communities) Questions 12, 13, 14

12. Stress-testing & use cases • System- rather than component-level complexity • Issues not with ontology size but with richness of mappings, contextual interpretations and continuous evolution • Millions of concepts vs. millions of instances (learn from KWeb) • Variety of tests needed: • Acquire and validate application requirements (mock-ups, user focus groups) • Validate and test software design (early and rapid prototyping) • Validate and test ontology (incl. expressivity, usability, complexity) • Validate and test software deployment (incl. usability) • Size matters – we aim to do things smarter rather than bigger • Human factors are more essential to apps with ‘000 editors (incl. view filtering, adaptation, simple visualization, navigation, wrapping,…) • For further details of tests see fisheries example in the notes Questions 15, 16

13. NeOn – critical mass of brainpower • Right mix of expertise, market focus and track record • Build synergies to sustain leadership in ontology engineering • Partners selected to fill in identified gaps in the state-of-the-art • USFD – one of reliable bridges to precursor projects • Unique expertise, practical experience, proven track record (Dr. Cunningham) • Representation, storage and evolution of meta-data (WP1) • Large-scale meta-data collection management & evolution • The Networked Annotation and Mining Environment (WP2 ) • SEKT, KnowledgeWeb, AKT • Supporting meta-data creation & resource annotation in the case studies  reuse of well-known USFD’s core competence • Implication of consortium composition on budgets • Travel/equipment budgets conservative & reflect NeOn ambitions • Travel comprises 6.52%, equipment 2.07% of total €15mil budget • See details on travel/equipment budget Questions 17, 20

14. NeOn at the frontline • Core individuals at the frontline • Prof. Motta (OU) … co-ordinator • 20-yrs experience in large collaborative projects (AKT, KWeb, Vital,…) • Prof. Motta (OU) & Prof. Studer (UKARL) … joint scientific directors • Combined 50-yrs experience in leading edge research • Ms. Whild (OU) … project manager • 15-yrs experience in managing large, high-profile projects • First at Ernst & Young and then at The Open University • Streamlined project management  Executive PMB • Core individuals + equitable representation from core partners • Total effort: 81 PM  incl. Ms.Whild (48 months) + admin. assistant (P/T) • EPMB includes liaisons to Technical, Scientific & Exploitation Boards • Efficient delegation and acting on decisions and issues • See further details on sharing responsibilities in the notes Questions 18, 19

15. Different risks  distributed risk mgt. • Consortium Agreement – basis for risk and quality mgt. • Risk impact categorization … high, medium, low • Guidance for risk resolution … monitoring and contingencies • WP12 includes periodic deliverables to maintain transparency Human resources (PMB) Technological (TMB) • Tool interoperability • Technology change & re-design • Limited functionality of module • Partner leaving • Multi-disciplinary nature • Staffing, recruitment Risk management (EPMB) Market (PEDB) Scientific (PSB) • Change in market needs • User acceptance • Method/technique robustness over-estimated Question 19

16. Risk of stretching thin? • Definitely not, limit of projects participated in was enforced in early stages of bid writing • Max. 2 substantial & justifiable involvements + 1 minor involvement • Parallel funding to institutions vs. research groups • Parallelism on the institutional level (university, corporation) • Well-defined key responsible persons on the unit/group level • Minimal or no overlaps among groups in one institution • Senior leader + min. 1 established researcher/manager with track record dedicated to the NeOn project • Individuals named in section B.5 will participate, no ‘dead souls’ • Partners successfully concluded FP5 projects  free capacity • The cross-fertilization with other initiatives is a potentially unique and non-imitable competitive advantage Question 21

17. right This is the agenda right the time and the right team

18. The End Here the presentation ends. The subsequent slides were included in Notes…

19. Impact and Measures of Success • NeOn Reference Architecture and methodology de facto standard • Size of developers community (both downloads and active developers) • Sales of NeOn handbook • Major companies – ‘gatekeepers’ adopting NeOn technology • Research uptake and dissemination • Publications, dissemination events, etc. • Number, timeliness and quality of published outcomes • Contribution to knowledge systems markets • Increased efficiency of work in distributed environments • Small businesses using NeOn technology to create competitive networks faster and more efficiently • Ontologies in the mainstream software development • Organizations reusing best practices from NeOn case studies GO BACK TO AMBITIONS, etc. SLIDE Questions 2, 3, 5

20. NeOn vs. Protégé timing, costs, motivation • User group  specific focus  different speeds of adoption • Where NeOn is likely to win: • Tight coupling with powerful reasoners with track record • NeOn starts with native support for service-oriented architecture • First-class support for collaboration & contextualization • Scalability is a big issue for Protégé • NeOn – a one-stop shop for ontology design, reuse, mapping, contextual & communal adaptation • What is at the core of NeOn  see "beyond feature comparison" • Plug-in paradigm of NeOn reference architecture • Enables third-party extensions and wider uptake • Flexibility  popularity (‘my first ontology design tool’) Question 8, 9

21. Beyond feature by feature comparison… • NeOn is going to provide a qualitatively different, radically more advanced technology than Protégé • Networked ontologies • Contexts • Collaboration • Trust • Open to services • Reference Architecture • LifeCycle • Etc.. GO BACK TO COMPETITIVE ENVIRONMENT SLIDE Questions 8, 9

22. Lifecycle and Evolution Multiple Users Multiple Contexts Collaborative Service-based Infrastructure From ‘one-size-for-all’ to contextual awareness Application adaptability Managing inconsistencies Open Reference Architecture NeOn Ontology Design Toolkit NeOn is about… Scalability and Usability of Networked Ontologies

23. Stress-testing & use cases • Cases cover technology- and user-centred aspects • Each case will appoint Case Study Test Board • Different views (technologists, users, methodologists, independents) • Defines/refines test plan, liaises with users & testers, feeds back • Key types of tests  checkpoints (see fisheries example) • Acquire and validate application requirements • Mock-ups, requirement acquisition in user focus groups • Validate and test software design • Test plan for entire software lifecycle, early and rapid prototyping • Validate and test ontology (incl. expressivity, usability, complexity) • Cross-testing on application requirements, cognitive walkthroughs • Validate and test software deployment (incl. usability) • Unitary tests, integration tests, systems tests, acceptance tests Questions 15, 16

24. Example tests in Agriculture sector • Validate and test ontology (incl. expressivity, usability, complexity) • Construction and updates of networked ontologies • Staff involved in fishery resource management widely distributed • Frequency and geographic clustering of manual edits • Number of contextually relevant updates triggered by NeOn system • Use and maintenance of networked ontologies • Study use of networked ontologies in searching FIGIS and FAO web • Relevance of search results for current/single vs. networked ontologies • Validate and test software deployment (incl. usability) • Integrating and mapping networked ontologies • Number of overlaps among current ontologies • Context emergence – similar topics, different coverage and granularity • Number of editors – before/after training, coaching sessions,… GO BACK TO STRESS TESTING SLIDE

25. How NeOn works… (technical clarifications) …however, learning relates to context building, e.g. • in terms of predicting structural evolutionary changes (WP1) • in terms of generalizing from user level to communities (WP2) • Support geographically distributed communities • Annotate using networks of ontologies and networked ontologies • Client-server enables customization, adaptation to diff. GUI-s • in terms of acquiring information on contexts (WP3) • In terms of choosing appropriate/typical presentations (WP4) Questions 11, 13

26. NeOn – sharing responsibilities • Shallow, accessible management structure – 2 lines • Co-ordinator  Administrator  Partner Leaders  Members • Scientific directors  Executive PMB  Other Boards  Members • Equitability, transparency, fairness, efficiency • Formally incorporated into Consortium Agreement • Fair representation on EPMB (not on size nor on funding) • 3 academic, 1 SME & 1 large partner; incl. min 1 female member; no nationality/country prevails • EPMB includes liaisons to Technical, Scientific & Exploitation Boards • Two ‘All Hands’ meetings a year + frequent virtual meetings • Foster interaction, prevent rather than solve conflicts • Utilize modern ICT to create a sense of joint enterprise and presence (BuddySpace, FlashMeeting, Hexagon) • Org. chart available in Figure 10, page 58 of the proposal Questions 18, 19 GO BACK TO FRONTLINE SLIDE

27. Implications on travel/equipment budget • Both budgets are conservative & reflect NeOn ambitions • Travel comprises 6.52%, equipment 2.07% of total €15mil budget • NeOn – a joint enterprise of distributed stakeholders • Ambitions to become the de-facto standard  dissemination • Life beyond NeOn funding  live & educated community • We must be pro-active in approaching key users  ‘gatekeepers’ • Leading on quality & differentiation • We are conscious of ‘value for money’ • Low-cost electronic media  virtual presence (OU is the leader) • Open Source or specially negotiated free commercial technologies • Re-use not re-invent • e.g. Atos’ mgt. portal, • UPM’s semantic portal, • OU’s virtual meetings GO BACK TO CONSORTIUM COMPOSITION SLIDE Question 20