Towards a Glossary of Activities in the Ontology Engineering Field

The Semantic Web of the future will be characterized by using a very large number of ontologies embedded in ontology networks. It is important to provide strong methodological support for collaborative and context-sensitive development of networks of ontologies. This methodological support includes the identification and definition of which activities should be carried out when ontology networks are collaboratively built. In this paper we present the consensus reaching process followed within the NeOn consortium for the identification and definition of the activities involved in the ontology network development process. The consensus reaching process here presented produces as a result the NeOn Glossary of Activities. This work was conceived due to the lack of standardization in the Ontology Engineering terminology, which clearly contrasts with the Software Engineering field. Our future aim is to standardize the NeOn Glossary of Activities

AOSD Ontology 1.0 - Public Ontology of Aspect-Orientation

This report presents a Common Foundation for Aspect-Oriented Software Development. A Common Foundation is required to enable effective communication and to enable integration of activities within the Network of Excellence. This Common Foundation is realized by developing an ontology, i.e. the shared meaning of terms and concepts in the domain of AOSD. In the first part of this report, we describe the definitions of an initial set of common AOSD terms. There is general agreement on these definitions. In the second part, we describe the Common Foundation task in detail

A Pattern Based Approach for Re-engineering Non-Ontological Resources into Ontologies

With the goal of speeding up the ontology development process, ontology engineers are starting to reuse as much as possible available ontologies and non-ontological resources such as classification schemes, thesauri, lexicons and folksonomies, that already have some degree of consensus. The reuse of such non-ontological resources necessarily involves their re-engineering into ontologies. Non-ontological resources are highly heterogeneous in their data model and contents: they encode different types of knowledge, and they can be modeled and implemented in different ways. In this paper we present (1) a typology for non-ontological resources, (2) a pattern based approach for re-engineering non-ontological resources into ontologies, and (3) a use case of the proposed approach

First Attempt towards a Standard Glossary of Ontology Engineering Terminology

In this paper we present the consensus reaching process followed within the NeOn consortium for the identification and definition of the activities involved in the ontology network development process. This work was conceived due to the lack of standardization in the Ontology Engineering terminology, which clearly contrasts with the Software Engineering field that boasts the IEEE Standard Glossary of Software Engineering Terminology. The paper also includes the NeOn Glossary of Activities, which is the result of the consensus reaching process here explained. Our future aim is to standardize the NeOn Glossary of Activities

Marinas and other ports and facilities for the recreational craft sector: an ontology domain to support spatial planning.

Marinas and other ports and facilities for the recreational craft sector in Sardinia (Italy) can host more than 19,000 pleasure boats and yachts, according to a recent estimate (Osservatorio Nautico Nazionale, 2010); this capacity, at the national level, is second only to that of the Liguria region. However, Sardinian infrastructures and facilities are not part of a coherent network. Moreover, they are unevenly scattered along the coastline and are very diverse, in terms of type, dimension, and endowment of facilities for sailors. A key issue to be taken into account in the early stages of the preparation of a plan for the pleasure craft sector, which might create the conditions for the setting up of a coherent network, is the lack of a proper, detailed knowledge of the system of Sardinian marinas and other facilities. To this end, this paper begins with an analysis of current information (both spatial and non-spatial) and attempts to build a spatial database that integrates available data. The analysis identifies differences in structure and semantics, together with differences in purpose and date of production/update of the data, as the roots of inconsistencies among existing data produced by different sources. Such differences in structure and semantics risk, if not properly identified, considered and handled, to cause an incorrect integration of data. Following the methodology provided by the guidelines produced by the Ordnance Survey with regards to domain ontologies (Hart et al., 2007; Hart e Goodwin, 2007; Kovacs et al., 2006), the construction of an ontology of the domain of infrastructure and facilities for the recreational craft sector is therefore proposed as a possible solution to the problem. By applying this methodology, a ‘knowledge glossary,’ consisting of a shared vocabulary of core and secondary concepts and of relationships (some of which spatial) among concepts is developed, leading to the construction of a conceptual model of the domain, later formalized by means of the software Protégé.

An Ontology for Product-Service Systems

Industries are transforming their business strategy from a product-centric to a more service-centric nature by bundling products and services into integrated solutions to enhance the relationship between their customers. Since Product- Service Systems design research is currently at a rudimentary stage, the development of a robust ontology for this area would be helpful. The advantages of a standardized ontology are that it could help researchers and practitioners to communicate their views without ambiguity and thus encourage the conception and implementation of useful methods and tools. In this paper, an initial structure of a PSS ontology from the design perspective is proposed and evaluated

Building Ontology Networks: How to Obtain a Particular Ontology Network Life Cycle?

To build an ontology, ontology developers should devise first a concrete plan for the ontology development, that is, they should establish the ontology life cycle. To do this, ontology developers should answer two key questions: a) which ontology life cycle model is the most appropriate for their ontology project? and b) which particular activities should be carried out in their ontology life cycle? In this paper we present a set of guidelines to help ontology developers and also naïve users answer such questions

Improving automation standards via semantic modelling: Application to ISA88

Standardization is essential for automation. Extensibility, scalability, and reusability are important features for automation software that rely in the efficient modelling of the addressed systems. The work presented here is from the ongoing development of a methodology for semi-automatic ontology construction methodology from technical documents. The main aim of this work is to systematically check the consistency of technical documents and support the improvement of technical document consistency. The formalization of conceptual models and the subsequent writing of technical standards are simultaneously analyzed, and guidelines proposed for application to future technical standards. Three paradigms are discussed for the development of domain ontologies from technical documents, starting from the current state of the art, continuing with the intermediate method presented and used in this paper, and ending with the suggested paradigm for the future. The ISA88 Standard is taken as a representative case study. Linguistic techniques from the semi-automatic ontology construction methodology is applied to the ISA88 Standard and different modelling and standardization aspects that are worth sharing with the automation community is addressed. This study discusses different paradigms for developing and sharing conceptual models for the subsequent development of automation software, along with presenting the systematic consistency checking methodPeer ReviewedPostprint (author's final draft