Lisbon, 30 th March 2016 Gianluca Luraschi Gonçalo Cadete “Towards a Methodology for Building.

Slides:



Advertisements
Similar presentations
Integration of MBSE and Virtual Engineering for Detailed Design
Advertisements

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering September 12, 2001 Capturing.
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
OASIS Reference Model for Service Oriented Architecture 1.0
Software Testing and Quality Assurance
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
PDDL: A Language with a Purpose? Lee McCluskey Department of Computing and Mathematical Sciences, The University of Huddersfield.
Overview of Software Requirements
1 Software Requirements Specification Lecture 14.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Requirements Engineering Process – 1
Software Life Cycle Model
Semantic Web Technologies Lecture # 2 Faculty of Computer Science, IBA.
SYSTEM ANALYSIS AND DESIGN
On Roles of Models in Information Systems (Arne Sølvberg) Gustavo Carvalho 26 de Agosto de 2010.
S/W Project Management
FP OntoGrid: Paving the way for Knowledgeable Grid Services and Systems WP8: Use case 1: Quality Analysis for Satellite Missions.
Managing Software Quality
Software Engineering 2003 Jyrki Nummenmaa 1 REQUIREMENT SPECIFICATION Today: Requirements Specification Requirements tell us what the system should.
Requirements Analysis
SE-02 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it. Requirements.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
ITEC224 Database Programming
School of Computing FACULTY OF ENGINEERING Developing a methodology for building small scale domain ontologies: HISO case study Ilaria Corda PhD student.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
Eurostat Expression language (EL) in Eurostat SDMX - TWG Luxembourg, 5 Jun 2013 Adam Wroński.
Lecture 7: Requirements Engineering
Historical Aspects Origin of software engineering –NATO study group coined the term in 1967 Software crisis –Low quality, schedule delay, and cost overrun.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
, - - HarmoniQuA MoST1 HarmoniQuA Knowledge Base and modelling guidelines Presenter affiliation name - country.
OHTO -01 SOFTWARE ENGINEERING LECTURE 3 Today: Requirements Analysis Requirements tell us what the system should do - not how it should do it.
Volgograd State Technical University Applied Computational Linguistic Society Undergraduate and post-graduate scientific researches under the direction.
The Use of Ontology Design Patterns for Metadata Semantics: Methods, Chances, and Limitations Gary Berg-Cross SOCoP Executive Secretary US RDA Advisory.
Science and Technology Norwegian University of NTNU Rolv Bræk, January Introduction to Systems Engineering by Rolv Bræk NTNU.
RE-ENGINEERING AND DOMAIN ANALYSIS BY- NISHANTH TIRUVAIPATI.
Software Reuse Course: # The Johns-Hopkins University Montgomery County Campus Fall 2000 Session 4 Lecture # 3 - September 28, 2004.
Approach to building ontologies A high-level view Chris Wroe.
Requirements Analysis
Chapter 7 K NOWLEDGE R EPRESENTATION, O NTOLOGICAL E NGINEERING, AND T OPIC M APS L EO O BRST AND H OWARD L IU.
1 CleanSeaNet DREAM PRESENTATION. Content Short introduction to EMSA EMSA Objectives and expected main results from DREAM EMSA Activity/Processes to which.
Information Technology Project Management, Seventh Edition.
 System Requirement Specification and System Planning.
The Software Lifecycle Stuart Faulk. Definition Software Life Cycle: evolution of a software development effort from concept to retirement Life Cycle.
Advanced Software Engineering Dr. Cheng
Chapter 1 The Systems Development Environment
Chapter 4 Requirements Engineering (2/3)
Chapter 4 – Requirements Engineering
Chapter (12) – Old Version
An Overview of Requirements Engineering Tools and Methodologies*
Chapter 1 The Systems Development Environment
School of Business Administration
Chapter 1 The Systems Development Environment
IEEE Std 1074: Standard for Software Lifecycle
Chapter 1 The Systems Development Environment
By Dr. Abdulrahman H. Altalhi
Level - 3 Process Areas (CMMI-DEV)
Goal, Question, and Metrics
Lecture Software Process Definition and Management Chapter 3: Descriptive Process Models Dr. Jürgen Münch Fall
Methontology: From Ontological art to Ontological Engineering
Logical information model LIM Geneva june
Software Requirements Specification Document
2. An overview of SDMX (What is SDMX? Part I)
Ontology-Based Approaches to Data Integration
Introduction to Engineering Design II (IE 202)
ESS VIP ICT Project Task Force Meeting 5-6 March 2013.
Requirements Engineering Process – 1
Engineering Processes
Chapter 1 The Systems Development Environment
Practical Database Design and Tuning Objectives
Presentation transcript:

Lisbon, 30 th March 2016 Gianluca Luraschi Gonçalo Cadete “Towards a Methodology for Building Ontologies” Mike Uschold and Martin King Ontology Engineering “The Enterprise Ontology” Mike Uschold, Martin King, Stuart Moralee and Yannis Zorgios

Presentation 1.Introduce the skeleton methodology for building an Ontology. 2.Apply the methodology to a specific case study. 2

A Skeletal Methodology - stages 3 Integrating existing Ontologies Integrating existing Ontologies 3.Evaluation How to build an Ontology 1.Identify Purpose 2.Building the Ontology Ontology capture Ontology coding 4.Documentation What is an Ontology? “an explicit specification of a conceptualization” (by Gruber)

Purpose stage 4 scope: 1.Why the Ontology is being built. 2.What its intended uses are. 3.Identify and characterize the users. Case Study – EMSA’s Earth Observation Ontology WHY/WHAT - The main aim of this project is to agree about set of terms and their definitions among all the EMSA’s EO stakeholders in order to avoid ambiguities in using the EO concepts (inter-lingua). WHO – The users of this ontology are the EMSA’s EO stakeholders: EMSA’s EO suppliers (ICT and EO services providers), EO business and technical teams, EMSA’s EO clients (Frontex and EFCA, DG Move).

Building the Ontology - Capture Step 5 Scope: 1.Identify the key concepts and relationship in the domain of interest; 2.Production of precise unambiguous text definition for such concepts and relationship; 3.Identification of terms to refer such concepts and relationship; 4.Agreeing on all the above. -> Issue: Intermediate representation of a conceptualization -> more/less formal/structured Approach: brainstorming; grouping -> Case Study (EMSA’s EO Ontology) Extraction of concepts, terms and definition for EODC business requirements, EODC contracts, EO tender specifications and procured Requests For Change. Tips: Initially do not formally commit to any particular meta-ontology. Definition effort/degree agreement. Handling ambiguities. Guidelines to follow. Wording. Reviewing How: “If we view the real world as a set of objects in a universe of discourse then identify aspects of interest can be seen as choosing and defining categories of objects found in the universe” - > issue: granularity of the categories

Building the Ontology - Coding 6 Methodology’s stage scope: Explicit representation of the conceptualization captured Issue: Choosing language and a methods -> see the scope of the Ontology Note: sometimes capture and coding are merged into a single step -> Tips: do not do that Case Study – EMSA’s EO Ontology Criteria to be addressed for language: perspicuity (clarity); conceptual distance (how complex is using the primitive to translate the concepts); expressive power (will it represent the concepts we need?); standards compliancy; translability/transportability; support by any methods/guidelines; does it have any formal semantics? (consistency checks); easiness; what kind of user base does it have?; flexibility. Criteria to be addressed for methods: coverage/completeness (how many stages does it cover?); granularity (does it address things at the right level?); learning curve (is it easy to learn?)

Building an Ontology - Integrating 7 Methodology’s stage scope: how and whether to use ontologies that already exist Issue: Much work must be done to achieve agreement -> tips: make explicit all assumptions underlying the ontology Case Study – EMSA’s EO Ontology Actions: 1.survey of EO ontology already existing 2.Benchmark the terms extracted and the EO ontology

Evaluation - Documentation 8 Evaluation scope: to make a technical judgment of the ontology Documentation scope: to use an ontology Issue: 1. One of the main barriers to effective knowledge sharing is the inadequate documentation -> tips: all the important assumptions shall be documented for the concepts as well as the primitives

Findings 9 TermsAcronymsDefinitionDefinition's source Acquisition The tasking of satellite acquisitions is done directly by the CleanSeaNet service with the Service Providers (SPs). The SP’s offer a service chain to EMSA including (i) satellite data acquisition at Ground Station(s), (ii) NRT processing of the SAR data, (iii) value adding image analysis services and (iv) delivery of products and associated metadata to EMSA, which all have to be performed according to satellite overpass at any time of the day. Alerting component Graphical User Interface ALERTING GUI It will be a separate component not part of the SEG. The business requirements should cover the needs for all EO based maritime services e.g. CSN, Frontex. Accordingly, the business requirements are not covered in this document. allocation The tasking of satellite acquisition is done directly by the CleanSeaNet service. The tasking is sent to the operational contact points within the Coastal States for confirmation. This process is called “image allocation”, and is used by Coastal States when planning the aerial and/or vessel verification. When a Coastal State has confirmed the tasking, EMSA issues the Tasking Forms for the scenes to the Satellite Operators and Service Providers. API In computer programming, an application programming interface (API) is a set of routines, protocols, and tools for building software applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types Earth Observation Processing – Technical Specification Version 2.0 Next Steps: 1. EO ontology survey; 2. agree among the stakeholders about the definition; 3. handling the ambiguities; 4. review the terms; 5. devise a meta-ontology

Conclusion 10 1.Interesting starting point but it looks like very old paper (1995) and it is not providing a systematic approach. 2.based on the exercise the paper’s tips are still valid.