Undefined 1 (2009) 1–5 1IOS Press

Future Internet Ontologies:The NOVI ExperienceWibisono Adianto a,∗, Cees de Laat a and Paola Grosso a

a System Network and Engineering, Informatics Institute, University of Amsterdam E-mail:{a.wibisono,delaat,p.grosso}@uva.nl

Abstract.Semantic web technologies have been applied in the last years to an area where they were rarely used before: the Future

Internet (FI) research field. In this context OWL ontologies are used to describe resources and services provided by FI platforms.Few distinguishing factors set application of Semantic Web in this area apart. First, the ontologies and the corresponding data

models are integral part of the software development process. Second, the definition of (new) operations and services in theseinfrastructures forces the FI ontologies to continually evolve. These features make the mapping of the information model intothe data model a crucial aspect, furthermore changes in the information model need to be automatically propagated.

In this paper we present the ontologies developed in the NOVI EU-funded project, their use to provide the required functional-ities, and we will in particular focus on the benefits and drawbacks of using direct and indirect mapping, and discuss the lessonslearned from this experience, and how they can benefit the FI community at large.

1. Future Internet and Semantic Web

Future Internet (FI) research defines novel architec-ture for the internet; in recent years lots of effort in thisarea has tried to implement a core and essential feature,namely federation of infrastructures.

Several projects attempted and are attempting toachieve federation by adopting semantic web tech-niques, ontologies.

Federation of heterogeneous internet resources be-longing to different providers is in fact crucial in thesenew internet models. The motivation for this is clear:services will be more easily offered by using a plethoraof devices, and only in very few cases a single domainwill have all the types of resources needed by an end-user. All of these envisioned FI federations share sev-eral crucial features: common authorisation policies,coordinated monitoring of available resources, and in-telligent selection of available computing and network-ing resources.

*Corresponding author. E-mail: a.wibisono@uva.nl

The adoption of semantic web ontologies as under-lying information model for resources and services hasalso a clear motivation: ontologies allow deduction ofservice and infrastructure behaviours. Assuming thatall resources in an FI platform are modelled in anontology, assuming that there are ontologies for pol-icy and monitoring data, we can intelligently deducewhich resources are available and which services canbe provided. The application of semantic web tech-nologies for integrating heterogeneous data enablesadvance analysis.

An example of this is the recently ended NOVIproject, sponsored by the EU under the FP7 program.We participated in NOVI where we used OWL ontolo-gies as formalization of the information models andwe developed the corresponding data models to en-able the communication among the various compo-nents in NOVI software architecture. The NOVI in-formation model describes resources at a conceptuallevel, including all the components required to supportthe operation of the NOVI software. The data modeldescribes implementation details based on representa-tion of concepts and their relations provided by the in-

0000-0000/09/$00.00 c© 2009 – IOS Press and the authors. All rights reserved

2

formation model. The NOVI ontologies captured therequirements at the design and analysis phase of theservices that were being built.

In Section 3 and Section 4 we report on the ontolo-gies that have been developed in NOVI and on theiruse in the software architecture.

We derived useful lessons from our experience inNOVI; our work proved us that the advantages of se-mantic modelling are counterweighted by several chal-lenges:

1. the mapping of concepts in the ontology to theobject oriented structures and processes used inthe projects is an important decision, which re-quires careful consideration depending on theinitial state of the software.

2. there is mismatch in timelines between the defi-nitions of the information model made during de-sign and requirement phase and the developmentof services and component at the implementationphase; this situation creates challenges in adap-tation of service development to changes in in-formation model. The chosen mapping will influ-ence the ease of making changes.

We will elaborate on these problems in Section 5, Sec-tion 6 and will provide our answers and recommenda-tion in Section 7 and Section 8.

Several other initiatives, such as the GENI [2] andthe Fed4FIRE [1] projects, are following suit and in-troducing ontologies as their base information model.The conclusions we provide in this article are of impor-tance for them and for all other FI projects intendingto adopt semantic web modelling. In particular the twoproblems we identified will require particular atten-tion and they constitute a valuable legacy of the NOVIwork.

2. Existing models

The NOVI project participants identified severalfeatures that needed to be supported by the NOVI on-tologies: support for virtualization concepts, context-awareness, support for monitoring and measurementconcepts, support for management policies. The ob-vious question was to determine if existing modelsin other Future Internet related projects could alreadyprovide (some of) these features. A thorough reviewof existing models focused on the following models:CIM[6], DEN-NG[13], MOMENT[3], NDL[14].

The existing model’s evaluation lead NOVI to con-clude that only minimal part of some of the existingontologies could be reused; in fact:

– CIM models infrastructure resources using UML.It did not provide support for semantic and con-text awareness, neither for monitoring and mea-surements concepts and for this reason it was notfurther considered.

– DEN-NG and MOMENT were complementaryworks with respect to NOVI, since the first isfocusing on policy management while the lat-ter if focused on monitoring resources. DEN-NGstarted with UML based approach which thenlater realized to be lacking in ability to repre-sent behavioral semantics. They complementedthe original approach with the use of ontologyside by side with the original ontology.

– The main innovation of the MOMENT was theuse of a measurement-specific ontology, allowingsemantic representation and retrieval of measure-ment and monitoring information, as well as pro-viding the flexibility of a service oriented archi-tecture for future Internet applications.

– NDL did not support virtualization concepts andmonitoring/measurement data, however, its sup-port for describing network topologies and deviceconfiguration was ultimately used as a buildingblock for the NOVI information model.

More information on the relation of the emergingNOVI model and the existing models can be found in[16] and [17].

3. The NOVI ontologies

Fig. 1. The three NOVI ontologies: the resource ontology providesthe basic concepts that are used in the monitoring ontologies and inthe policy ontology.

The OWL ontology used in the NOVI projects con-sists of three modular components [15], which are de-picted in Fig. 1. There is resource ontology, and twoontologies that are based on it: the monitoring ontol-ogy and a policy ontology.

3

3.1. NOVI Resource Ontology

The main elements of the NOVI Resource informa-tion model can be seen in Fig. 2. The classes Node,Network Element, Node Component and Service areall subclasses of the generic Resource object.

– Node is used to represent physical nodes, while asubclass VirtualNode is used to represent virtual-ized nodes;

– Network Element is an abstract class with threespecific subclasses: Interface, Link and Path;

– NodeComponent is also an abstract class that de-scribes essential components of nodes that are ofinterest to the user, such as CPU, Memory, Stor-age, SwitchingMatrix and LoginComponent;

– Service class allows the user to express the ser-vice level desired and to decouple the desired ser-vice from the actual physical implementation.

Fig. 2. The NOVI Resource Ontology

Besides the resource description classes there arealso other classes to describe properties of resources:

– Location provides a way to describe location ofresources.

– Lifetime describes the time dimension of otherobjects, such as reservations, or availability ofnodes.

– Group is an abstract class to describe groups ofresources which provides support for essentialconcepts within the NOVI federation, namely thePlatform and Topology subclasses. A Platformdescribes a particular testbed in the NOVI fed-eration. Resources can be linked to the class to

denote membership of that platform, and it canprovide pointers to other information such as themanagement service of that platform. A Topol-ogy can define a group of resources that a user re-quests, or the implementation of a usersâAZ re-quest.

3.2. NOVI Monitoring Ontology

For its operation the Monitoring Service present inthe NOVI software architecture requires formal de-scriptions of different groups of concepts, their rela-tionships and properties:

1. Resources: to describe the resources to be moni-tored. These concepts are defined in the resourcemodel as described in the previous section;

2. Monitoring Tools: to describe monitoring toolsand their parametrization. The main goal of thispart of the model is to enable the Monitoring Ser-vice to translate incoming monitoring queries toplatform-specific commands;

3. Monitoring Data: to describe the monitoredproperties. This part of the model helps the uni-fied, platform-independent and unit-aware han-dling of monitoring results;

4. Data manipulation: to describe the flow of trans-formation steps, which can be applied to the data,such as re-sampling and aggregation.

The Monitoring ontology is also built in a modularmanner and provides support for all the above. Fig.3shows the classes that are defined in the feature part ofthe model.

Fig. 3. The Feature component of the NOVI Monitoring Ontology

3.3. NOVI Policy ontology

The NOVI policy ontology provides the concep-tual support to the operation of the Policy Service.

4

The Policy service provides support for authorizationpolicies that specify which subjects may access vir-tual resources within the federation; it enables event-condition-action policies that enforce control and man-agement actions upon certain events. Figure 4 showsthe class hierarchy in this ontology.

Fig. 4. The NOVI Policy Ontology

4. The NOVI architecture and its use of theontologies

The NOVI ontologies provide support for the op-eration of the software components in the NOVI ar-chitecture. Figure 5 shows a federation consisting of atestbed A and a testbed B.

Each platform has its local set of NOVI softwareinstances. The ultimate goal of NOVI is to allow thecreation and management of the virtual layer slices byfinding, gathering and configuring the proper serviceson the underlying physical resources. On each plat-form the various services are only responsible for thelocal resources; in case of cross-platform resource dis-covery or monitoring, the local instances communicatewith each other via their neighbour services. All com-munication between components in the NOVI layer ismediated by the NOVI ontology.

Fig. 5. The NOVI Architecture supporting the federation of two plat-forms: testbed A and testbed B. Source: [7]

The NOVI layer defines the following services: theIRM (Intelligent Resource Mapping), the PS (PolicyService), the RIS (Resource Information Service), theMS (Monitoring Service) and the API. The best wayto understand the relations and the operations of thesecomponents is to follow a user request for a slice as ittravels through the system.

A user will submit requests for standalone virtualresources, topologies of virtual resources and specificservices regarding virtual resources/topologies. Re-quests can be of two types: bound and unbound. Abound request contains the mapping between the vir-tual and physical resources that the users wishes tohave; an unbound request will leave the NOVI sys-tem free to perform mapping within the specified con-straints. To compose this request NOVI users relyon the graphical editor that has been adopted in theproject[18]. The NOVI editor helps the platform userto assemble and identify the resources they need with-out having to write the OWL topology.

Figure 6 shows an unbound request for one virtualnode with storage 10GB storage and 4-core CPU witha 2 GHz processor. In Listing 1 we highlight part ofthe request (expressed in Turtle) corresponding to thedefinition of the Virtual Node vnode1, the CPU and thestorage characteristics.

5

Listing 1: Unbound request

: requestTopology NS5: type : Topology ,owl : NamedIndividual ;: autoUpdateOnfa i lure " f a l s e "^^ xsd : boolean ;: conta ins : vNode1 .

### h t t p : / / fp7−nov i . eu / im . owl#vNode1

: vNode1 NS5: type : V i r tua lNode ,owl : NamedIndividual ;

: hasVendor " " ^ ^ xsd : s t r i n g ;: hasV i r t ua l i za t i onEnv i ronmen t " " ^ ^ xsd : s t r i n g ;: hrn " " ^ ^ xsd : s t r i n g ;: v i r t u a l R o l e " " ^ ^ xsd : s t r i n g ;: hostname " " ^ ^ xsd : s t r i n g ;: hasOS " " ^ ^ xsd : s t r i n g ;: diskImage "0 "^^ xsd : anyURI ;: hasAva i lab leLog ica lRouters "0 "^^ xsd : i n t ;: hasLogicalRouters "0 "^^ xsd : i n t ;: exc lus i ve " f a l s e "^^ xsd : boolean ;: hardwareType " x86_64 "^^ xsd : s t r i n g ;: hasComponent : vn1−cpu ,

: vn1−sto .

### h t t p : / / fp7−nov i . eu / im . owl#vn1−cpu

: vn1−cpu NS5: type :CPU ,owl : NamedIndividual ;: hasAvai lableCores 0 ;: hasCPUSpeed " 2 . 0 " ^ ^ xsd : f l o a t ;: hasCores 4 ;: exc lus i ve " f a l s e "^^ xsd : boolean .

### h t t p : / / fp7−nov i . eu / im . owl#vn1−sto

: vn1−s to NS5: type : Storage ,owl : NamedIndividual ;: hasAvai lab leStorageSize " 0 . 0 " ^ ^ xsd : f l o a t ;: hasStorageSize "10 .0 " ^^ xsd : f l o a t ;: exc lus i ve " f a l s e "^^ xsd : boolean .

The NOVI API is the users main entry point to theNOVI layer; it delivers this request to the appropriateNOVI services such as the IRM or Policy Manager ser-vice. The Policy Service validates the credential of theuser, while the IRM service will ultimately embed theuser requests for virtual topologies / resources (VirtualNetworks - VNs) to the federated physical substratenetwork. To perform the embedding the IRM first gath-ers information from the RIS/ and the MS regardingavailable resources.

The RIS acts as a single point of contact for otherNOVI services to acquire information about resources’status. One of the functionalities of the RIS is to reg-ister and discover resources. Resource discovery en-compasses locating and retrieving information acrossthe federated virtualized substrate network. After re-trieving this information, the RIS must provide accu-rate current status of resources to other services.

The MS collects information about specific re-sources and metrics. The monitoring can be performedfrom slices (virtualized resources) or from hosts (phys-

Fig. 6. Unbound request for one Virtual node with cpu/storage re-quirement

ical devices). In addition, it is possible to obtain pas-sive monitoring information from resources or fromrepositories, and active monitoring information, whereit is needed for the operation of the network elements.

Only resources that satisfy the requirements im-posed by the VN request are selected. If resourcesare required across testbeds, then the IRM will solvethe so called inter-domain Virtual Network Embeddingproblem[10].

5. Model mapping methodologies

An important lessons learned during the NOVIproject has been the need to decide on the proper map-ping techniques. In this section we will discuss differ-ent approaches on how to use ontologies and semanticweb technology to develop software components forFuture Internet platforms. In NOVI this approach con-

6

siders the conceptual relationships captured by the in-formation model formalized as ontology described insection 3, to derive an object model that can supportthe operations and behaviour of the NOVI softwareservices described in section 4.

Using ontology to drive software development isseen as a natural next step in the Model Driven Devel-opment [9]. In [4] domain models are used as a bridgebetween underlying relational persistence model andthe object model. It is also possible to develop a com-ponent that fully corresponds to an ontology. Differentdomains and ontologies can share components fromrepositories. This is obviously very interesting for Fu-ture Internet project who faces similar challanges withregard to platform federations and network embeddingand are keen to reuse software when available.

Ontologies should be, in a sense, a basis for design-ing and developing interoperable software componentsin practice, since they can precisely define the seman-tics of components and their parts, as well as the typesof relations and communication between software [5].

Generalizing from our experiences, we identify twomain mapping approaches:

– direct object model mapping, where objectmodel is derived directly from the underlyinginformation model, maintaining exact concep-tual relationship. These model is then used be-tween components using this type of mapping andwithin the same component. We call the compo-nents using this approach direct-mapping compo-nents;

– indirect object model mapping, where objectmodel are indirectly derived, and taking more intoconsideration on how the conceptual relationshipcan be adapted to suite existing software compo-nents/software services. This approach performsthe necessary mapping only to extract the relevantinformation from the information model into theinternal representation of a possibly existing soft-ware services. Components adopting this type ofapproach will be called indirect components.

In Fig. 7 we illustrate the difference between thesetwo types of mapping. In the direct approach, the ob-ject model in the software artifact corresponds directlyto the conceptual structure of underlying domain on-tology; the software’s internal representation of the ob-jects is structurally similar to the original domain on-tology, i.e. the red, blue and green classes have thesame relation in both the ontology and the artifact.

Meanwhile in the indirect approach, the software ar-tifact has its own internal representation, and the rela-tions between classes and objects can be different thanin the original ontology. Objects and classes will bemapped into the structure identified by the domain on-tology only when the information is consumed outsidethe system.

Fig. 7. Direct and indirect mapping of ontology concepts: we seethe relation between the three objects in the ontology (upper left),the direct representation (upper right) and the indirect representation(lower left)

5.1. Direct model mapping

In this approach, concepts in an ontologies are au-tomatically converted into object model counterparts.This approach is exemplified for example through au-tomated generation of Java objects that represents theunderlying ontology. The motivation for choosing thismapping is to isolate the object oriented programmerfrom knowledge of ontologies, or having to be famil-iar with knowledge engineering methods. One of theadvantage of direct object mapping is that it well suitsdomain aware application, where the mapping makesense.

Example of a direct mapping can be seen in figure 8.Here three concepts in the ontology, namely the Node,Interface and IP address, are related to each other bypredefined properties: hasInterface and hasIPAddress.The mapping creates three Java objects with the samename and with the same relations.

5.2. Indirect model mapping

Object structures in the indirect mapping can be dif-ferent than the one in the original ontology. We can seethis exemplified in Figure 9. Here the original classesNode, Interface and IPAddress are mapped into a sin-gle Java object. The relation/properties between them

7

Fig. 8. Direct mapping of ontologies: the relation between the con-cepts Node, Interface and IP address in the ontology (left) aremapped to Java objects in the software artifact (right)

are also not necessarily conserved. The mapping intothe underlying ontology representation is still neededto communicate with external software componentsusing the same basic information model.

Fig. 9. Indirect mapping of ontologies: the relation between theconcepts Node, Interface and IP address in the ontology (left) aremapped into a single Java object in the software artifact withoutmaintaining the original structure (right)

Semantic web technology libraries such as Jena orSesame provide a generic object model mapping thatcan be used by developers. In this mapping, the javaobjects that developer have to work with will not bedomain specific, but will be only primitives from theunderlying ontologycal terminologies. Developer willhave to use for example OntologyClass, or NamedIn-dividual without dealing directly with domain specificobjects.

5.3. Hybrid model mapping

There is a third possible way to perform mapping:an hybrid approach. As proposed in [11], the hy-brid mapping approach combines the direct and in-direct mapping. There are some core sections wherethe object model corresponds directly to the informa-

tion model, while for some other sections the objectmodel is indirectly derived from the underlying infor-mation model. The reason for keeping some section ofthe object model indirectly mapped is scalability: fordomains where the underlying original ontology thatneeds to be represented is very large it is no longerfeasible and efficient to perform direct mapping.

6. Mapping in NOVI

We applied the two approaches we described in Sec-tion 5 in the NOVI project. Direct mapping of coreNOVI Information Model was used for all softwarecomponents, except for the Monitoring Service whichadopted the indirect mapping.

6.1. NOVI direct mapping with Alibaba

The NOVI Information model is directly mappedusing the Alibaba tools[8]. Alibaba is intended to com-bine the flexibility and adaptivity of RDF with an pow-erful Object Oriented programming model. Amongseveral features provided by this library, we are focus-ing on the Object Repository which allows us to per-form direct mapping of OWL/RDF into objects model.

AliBaba’s object repository provides programmerswith increased expressivity and a simplified subject-oriented programming environment. The Object Repos-itory is an extension to the Sesame RDF Repositorythat allows an RDF store to function as an object store.It maps Java objects to and from RDF resources andOWL classes to Java classes in a non-intrusive mannerthat enables developers to work with resources storedin an RDF Repository as objects. The Object Reposi-tory may also optionally be configured with a BLOBstore, to store information-resources.

In an ontology concepts are a hierarchical modelof resource classes, that include a description of sup-ported operations on a type, including syntax and se-mantics. A concept defines the properties and methodsavailable to objects retrieved from the store. Alibabaallows to manually perform the concept mapping be-tween existing Java classes and the concepts in an on-tology; it also allows to automatically perform conceptgeneration of Java classes and interfaces based on ex-isting ontology. Mapping and generation have the fol-lowing characteristics:

1. Concept MappingWith Alibaba concepts are mapped to Java classesor interfaces annotated using IRI (Internation-

8

alized Resource Identifier). The IRI can be as-signed explicitly during definition of classes, orat runtime. RDF objects retrieved from the storeimplement all the concepts that map to one ofthe URI/IRI rdf:type values of the RDF resource.Any Java field, getter method, or setter method,on a concept, that includes an @Iri annotationwill be mapped to an RDF property using thegiven predicate.

2. Concept GenerationThe process of mapping concepts in the originalOWL/RDF file to the Java object classes can beperformed in two manners: either manually byannotating the classes that are going to be storedin the object repository, or by using owl compilerprovided by Alibaba. In our implementation inNOVI we use the existing OWL compiler scriptas a base and perform our own customization,where we did a small modification on the waypackages are generated.

6.2. Indirect mapping of NOVI Monitoring IM

In this mapping we used the ontology to allow theMonitoring services to handle heterogeneous federa-tion platform. Part of the monitoring software buildingblocks had been developed prior to the NOVI projectand existed before the NOVI Monitoring ontology wasfully defined. These services already had their own in-ternal representation of concepts with relationship.

Indirect mapping used an intermediate semanticstorage between the monitoring services and the otherservice components. All information that is going tobe consumed by the monitoring services componentsis first loaded into a temporary (in memory) semanticstore using RDFLib python library.

Transformation into internal representation is thenperformed through SPARQL Query into this tempo-rary semantic store. The results of these query is con-verted into internal python object/representation.

6.3. Communication between NOVI components

In Figure 10 we illustrate how components usingdirect mapping and indirect mapping communicate.RIS and IRM are both direct mapping componentsand communicate directly using the common objectmodel that is derived from NOVI information model.The communication between RIS and MS is insteadindirect, therefore it is intermediated with an RDFstore as explained in the previous subsection. The RIS

Fig. 10. Communication between NOVI components

communicates between federated platforms throughdirect mapping communication. An intermediate Al-ibaba triple store between platforms can also be used,in case the available communication protocol does notallow to direct transfers of object among platform.

6.4. Mapping issues in NOVI

During the course of the NOVI project we encoun-tered a number of problems related to the mappingchoices made. We will introduce a couple of these sit-uations and in the next section we will generalize ourfindings from NOVI to any Future Internet platformconsidering mapping.

1. At a certain point in the project the Path conceptcaptured in the base ontology needed to be re-modelled. Originally all Path objects were rep-resented as unidirectional collections of Links.During the development of the NOVI Serviceswe found out that we need to have bidirectionalrepresentation of the Path, for convenience sincethese are the types of Path that is mostly neededin our testbeds. This change introduced new con-cepts, i.e the Bidirectional Path and the Bidirec-tional Links. The creation of Bidirectional Pathsand Links reflected in new triples in the RDFstore. This change had different effects depend-ing on the mapping adopted:

– the Object model from the direct mappingneeded to be regenerated, and all existing codewhich used the unidirectional model of Pathhad to be adapted to this newly introduced

9

concept. Existing pairs of unidirectional Pathobjects which were already stored in the sys-tem required to create a corresponding Bidi-rectional link.

– in the indirect approach this changed how thePath objects coming from the triple store weremapped into the internal representation (of themonitoring service components). The changesrequired are only in the interpretation of thequery results related to the Path.

This in a concrete example of what we will callgenerically ontology changes scenario in Sec. 7.

2. In the project we gave attention to scalabilityissues. In particular we identified those aspectsof scalability that are crucial for adding new re-sources and testbeds. Fig. 11 and Fig. 12 show re-spectively the response time of the NOVI systemfor the creation of a slice when the number of re-sources in the testbed and the number of nodes inthe request increase. These results provide infor-mation on the behaviour of the whole system; theeffect of the mapping choice made by the com-ponents on the scalability cannot be easily disen-tangled.

Fig. 11. Scalability result: time needed for slice creation versus num-ber of nodes in the testbed Source: [7]

Fig. 12. Topology scalability result: time needed for slice creationversus number of nodes in the request Source: [7]

This in an example of software scalability sce-nario that involves both direct and indirect map-ping components.

7. Evaluation

Thanks to the experience gained in NOVI we iden-tify a set of challenges and propose solutions of inter-est to any other Future Internet project adopting on-tologies.

We identify three major challenges all projects faceduring the development and further maintenance oftheir software. Here we are going to focus on how weare coping with these issues, with respect to the map-ping approaches that we have outlined in the previoussections. We consider:

– Ontology Changes, i.e. changes in the underlyingontology maintaining software components be-haviour;

– Software Scalability, i.e. how the software com-ponents behave when the ontology grows in size;

– Domain Changes, i.e. domain changes where weare trying to generically apply the same softwareservices to different domains;

. For each one we indicate the implications of theadopted mapping strategy, and we try to determine ifone approach is preferable to the other.

7.1. Ontology Changes Adaptation

For changes in underlying ontology where new re-lationships or concepts are introduced or existing re-lationships are changed, direct mapping and indirectmapping will need similar adaptation at the level ofobject model. The newly introduced concepts and re-lationships would need to be included in the auto-matic generation of the object model for direct map-ping, meanwhile for indirect mapping a new conver-sion to internal structure of the indirect mapping wouldbe necessary.

There will be a different implications at the levelof software components and services using the gener-ated object model. Direct software component wouldneed to adapt to the newly introduced components andstructure, while indirect component will require lessmodification as long as all the conversion to internalrepresentation in the indirect mapping approach al-ready cover the new changes.

In face of this type of changes, to determine whetherdirect mapping or indirect mapping is easier dependson the existing internal representation of concepts andrelationships existing in the indirect mapping. If thereare no new concepts introduced, but only the ontol-ogy structure changes, then it is simpler to adapt for

10

a project using indirect mapping. In essence a FutureInternet project will cope better with changes of thistype if there is a stable interface between the softwareand the ontology so as to allow each to evolve inde-pendently [12].

7.2. Software Scalability

The direct and indirect mapping approaches differin how the developed software scales with respect tothe underlying ontology. Indirect mapping componentsand applications are loosely coupled to the underlyingontology. Scaling the underlying ontology to incorpo-rate larger concepts or relationships will not requireoverall changes in the indirect mapping components.As long as the main functionality of software compo-nents developed remains the same, changes in under-lying ontology would only affect the relevant parts ofthe software.

Meanwhile, direct mapping and automatic genera-tions of the object model are tightly coupled with theunderlying information model (size). Changes in un-derlying ontology to incorporate larger number of con-cepts and relationship would have an immediate im-pact with the software components developed using di-rect mapping of ontology into object model.

7.3. Domain Changes Adaptation

A direct model is more suitable for a programmerwriting domain-aware code; this is due to the fact thatthe object model generated in direct mapping retainsthe exact concepts and relationship as the original do-main. In fact, software developers using the resultingobject model are manipulating directly concepts andrelationships in the original domain. Requests to applythe resulting direct software components into anotherdomain will require major rewriting in the case of di-rect mapping approach.

An indirect model is instead more suitable for driv-ing generic software that can be adopted in other do-mains. The indirect mapping might be more flexiblein adapting to domain changes, as long as the newlyadopted domains are compatible at the informationmodel level, and a suitable conversion to internal rep-resentation of indirect mapping can easily be gener-ated.

8. Recommendations for FI adopting ontologies

The results and observations made before in this ar-ticle allow us to distill a set of recommendations for

other projects in the Future Internet area that want tostart with ontologies adoption. We do not have enoughdata to say if there is a clear advantage of using OWLontologies in FI description and management. Thischoice is left to the Future Internet architects. But if,like in NOVI, the ontology adoption has already beenchosen we can provide an answer to is what should bethe mapping adopted in the FI software.

If we consider generically projects and softwarecomponents our recommendations are:

1. Projects that start software and service develop-ment from scratch should chose direct mapping;

2. Projects whose software already exists (in part)will benefit more from indirect mapping;

3. Components providing services not exposed toexternal users can opt for indirect mapping;

4. Components that expose services to the outsideshould instead use direct mapping, in order toavoid continuos conversions.

These recommendations are in summarized in Ta-ble 1.

Project Scenarios Indirect Mapping Direct Mapping

Start from scratch x

Existing services x

Internal communications x

External communications xTable 1

Recommendation Table

We can also provide recommendations consideringthe desired features of the software services, and theimpact the mapping has on them. In the introductionwe identified the main features of Future internet thatinformation models need to support, namely commonauthorization policies, coordinated monitoring of re-sources, intelligent resource selection.

1. From the perspective of federating FI platformsdirect mapping should be preferred. This is clearof we think of intelligent resource selection anddiscovery where there are heterogeneous re-source providers. Direct mapping to the underly-ing ontology will simplify the information ma-nipulation required to perform the discovery andselection task.

2. For monitoring which operates within a domainand only it is required to stitch information at theboundaries a direct mapping choice is less strin-gent.

11

9. Conclusion

The NOVI project has been one the first project tofully embrace semantic web as underlying mechanismto describe the concepts and elements required for thefederation of Future Internet platforms. The motiva-tion for ontologies is the additional reasoning featurewhich allows intelligent deduction of resource avail-ability, policy and monitoring of infrastructure. In thisarticle we have presented the ontologies that were de-veloped in NOVI and summarised how they are usedby the various services.

Of course the information model needs to be mappedto suite the needs of the federation services and thesoftware components that will be developed. In this pa-per we have outlined different approach of performingthis mapping. We described the concrete choices madein NOVI, namely direct and indirect mapping, and wegave the reader an insight in the problems encounteredduring the project that challenges the mapping choice.

We were able to generalise from our experienceand we can conclude with a set of recommendationsfor upcoming projects in the area that are going touse ontologies in regard to the optimal mapping to beadopted.

Acknowledgments

The work presented here has been funded by theDutch national project COMMIT.

Authors would also like to thank all the colleaguesthey worked with in the NOVI project (7th FrameworkProgram, Grant No. 257867), and in particular Jeroenvan der Ham and Chariklis Pittaras.

References

[1] Fed4FIRE. http://www.fed4fire.eu/.[2] GENI - Exploring the Network of the Future. http://www.

geni.net/.[3] MOMENT U Monitoring and Measurement in the Next Gener-

ation Technologies. http://www.salzburgresearch.at/en/projekt/moment_en/.

[4] Guillaume Hillairet and Frédéric Bertrand and Jean YvesLafaye. MDE for publishing Data on the Semantic Web. Pro-ceedings of the of the First Workshop on Transforming and

Weaving Ontologies in Model Driven Engineering (TWOMDE2008) at MoDELS, 2008.

[5] Vladan Devedzic. Understanding ontological engineering.Communications of the ACM, 45(4):136–144, 2002.

[6] DMTF. Common information model. http://dmtf.org/standards/cim.

[7] Sandor Laki and Blazej Pietrzak. NOVI deliverable4.5: Integrated Prototype. http://www.fp7-novi.eu/deliverables/doc_download/71-d24, 2012.

[8] OpenRDF. Alibaba Version 2.0-rc7. http://www.openrdf.org/doc/alibaba/2.0-rc7/.

[9] Jeff Z Pan, Steffen Staab, Uwe ASSmann, Jürgen Ebert,and Yuting Zhao. Ontology-Driven Software Development.Springer Berlin Heidelberg, 2013.

[10] C. Pittaras, Papagianni. C., A. Leivadeas, P. Grosso, J. van derHam, and S. Papavassiliou. Resource discovery and alloca-tion for federated virtualized infrastructures. Future Genera-tion Computer Systems, 2013.

[11] Colin Puleston, Bijan Parsia, James Cunningham, and AlanRector. Integrating object-oriented and ontological represen-tations: A case study in java and owl. In Proceedings of the7th International Conference on The Semantic Web, ISWC ’08,pages 130–145, Berlin, Heidelberg, 2008. Springer-Verlag.

[12] Alan Rector, Sebastian Brandt, Nick Drummond, MatthewHorridge, Colin Pulestin, and Robert Stevens. Engineering usecases for modular development of ontologies in owl. Appl. On-tol., 7(2):113–132, April 2012.

[13] John Strassner, José Neuman Souza, Sven Meer, Steven Davy,Keara Barrett, David Raymer, and Srini Samudrala. The designof a new policy model to support ontology-driven reasoning forautonomic networking. J. Netw. Syst. Manage., 17(1-2):5–32,June 2009.

[14] J. van der Ham, Freek Dijkstra, P. Grosso, R. van der Pol,A. Toonk, and C. de Laat. A distributed topology informationsystem for optical networks based on the semantic web. Opti-cal Switching and Networking, 5(2-3):85–93, 2008.

[15] Jeroen van der Ham. NOVI deliverable 2.4: Final In-formation and Data Model and Report on Prototypes.http://www.fp7-novi.eu/deliverables/doc_download/71-d24, 2011.

[16] Jeroen van der Ham. NOVI deliverable 2.1: Information mod-els for virtualized architectures. http://www.fp7-novi.eu/deliverables/doc_download/25-d21, 2012.

[17] Jeroen van der Ham, Chrysa Papagianni, Jozsef Steger, PeterMatray, Yiannos Kryftis, Paola Grosso, and Leonidas Lym-beropoulosà. Challenges of an information model for federat-ing virtualized infrastructures. 5th International DMTF Aca-demic Alliance Workshop on Systems and Virtualization Man-agement: Standards and the Cloud, 2011.

[18] Adianto Wibisono, Ralph Koning, Paola Grosso, Adam Bel-loum, Marian Bubak, and Cees de Laat. Ointed: Online ontol-ogy instance editor enabling a new approach on ontology de-velopment. Software Practice and Experience, 43:1319–1335,2013.