bIoTope D5.2 Service Composition Framework final

DELIVERABLE

ThisprojecthasreceivedfinancialsupportfromtheEuropeanUnionHorizon2020Programmeundergrantagreementno.688203.

D5.2ServiceCompositionFramework

ProjectAcronym: bIoTopeProjecttitle: BuildinganIoTOpenInnovationEcosystemforConnectedSmartObjectsGrantAgreementNo. 688203Website: www.bIoTope-project.orgVersion: 1.0Date: 30January2017ResponsiblePartner: FraunhoferContributingPartners: AALTO,EPFL,CSIRO,eccenca,OpenDataSoft,CTDisseminationLevel: Public X

Confidential–onlyconsortiummembersandEuropeanCommissionServices

Ref. Ares(2017)523794 - 31/01/2017


©688203bIoTopeProjectPartners 2 30January2017

RevisionHistory

Revision Date Author Organization Description

0.1 17/11/2016 ChristianMader Fraunhofer Initialdraft

0.2 16/01/2017 ChristianMader,RobertHellbach,SteffenLohmann

Fraunhofer,BIBA AddedRobert’sremarksand

improvements,addedSectionon

visualtools0.3 25/01/2017 ChristianMader,

SteffenLohmannFraunhofer InternalRevision

0.9 26/01/2017 ChristianMader,SteffenLohmann,

Fraunhofer AddressedJeremy’scomments

1.0 30/01/2017 ChristianMader,RobertHellbach

Fraunhofer,BIBA AddressedRobert’scommentsand

preparationoffinalversion

Everyefforthasbeenmadetoensurethatallstatementsandinformationcontainedhereinareaccurate,

howeverthebIoTopeProjectPartnersacceptnoliabilityforanyerrororomissioninthesame.



TableofContents

1. Introduction................................................................................................................................................6

1.1. ObjectivesinWP5...............................................................................................................................6

1.2. ObjectivesinTask5.A..........................................................................................................................6

1.3. ContentofthisDocument...................................................................................................................7

2. ProblemDefinition......................................................................................................................................8

2.1. bIoTopeSoftwareComponentsInteraction........................................................................................8

2.2. ExemplaryIoTObjects.........................................................................................................................9

3. ApproachforIoTServiceIntegrationusingO-MI/O-DFandRDF..............................................................10

3.1. SpecifyingIoTDeviceInteraction–AnExemplarySetting................................................................10

3.2. ExpressingO-DFStructuresusingRDF..............................................................................................12

3.2.1. O-DFStructureofaScheduleIoTObject.......................................................................................12

3.2.2. RDFRepresentationofthisStructure............................................................................................13

3.2.3. O-DFStructureofaTrafficLightIoTObject..................................................................................13

3.2.4. RDFRepresentationofthisStructure............................................................................................13

3.3. RealizingRDF-basedServiceIntegrationusingSPARQL....................................................................14

4. O-DFtoRDFConversionPrototypeArchitecture,IntegrationandImplementation................................15

4.1. Architecture.......................................................................................................................................15

4.2. IntegrationWorkflowwithExistingbIoTopeComponents...............................................................16

4.3. PracticalExample..............................................................................................................................17

5. VisualUserInterfacesforRDFGraphExploration.....................................................................................21

6. ConclusionandFutureWork.....................................................................................................................24

7. References.................................................................................................................................................25

8. Annex1......................................................................................................................................................26

ListofFigures

Figure1:OORIArchitectureandbIoTopecomponentinteractions.................................................................15Figure2:ExampleworkflowforOORIintegrationwithinbIoTope...................................................................16Figure3:O-MInodeprovingdataonbikeparkingspots..................................................................................17Figure4:O-MI/O-DFrequestandresponsemessagesforaccessingparkingspacedata.................................18Figure5:GraphicalrepresentationofSPARQLqueriesinSparqlFilterFlow......................................................22Figure6:GraphicalrepresentationofSPARQLqueryinQueryVOWL...............................................................22Figure7:LD-VOWLvisualizationofschemainformationextractedfromaLinkedDataendpoint...................23Figure8:ScreenshotoftheRelFindervisualizingfoundrelationships.............................................................24



ListofTables

Table1:InterfacesofexemplaryIoTobjects......................................................................................................9

AcronymsandDefinitions

Term DescriptionREST Representationalstatetransfer1,aspecificationforHTTP-based

implementationofWebServices.LinkedData AmethodofpublishingstructureddataontheWebusingURIs2.RDF ResourceDescriptionFramework3.Astandardmodelfordatainterchangeon

theWeb.RDFS RDFSchema4.ExtensionofRDFwithontologymodelingfeatures.OWL WebOntologyLanguage5VOWL VisualNotationforOWLOntologies6SPARQL LanguageandProtocolspecification7forqueryingandmanipulatingRDF

graphs.O-MI/O-DF OpenDataFormat8/OpenMessagingInterface9.Publicationformatand

protocolforIoTdatastandardizedbytheOpenGroup10.

1http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm2https://www.w3.org/DesignIssues/LinkedData.html3https://www.w3.org/RDF/4https://www.w3.org/TR/rdf-schema/5https://www.w3.org/TR/owl2-overview/6http://vowl.visualdataweb.org/v2/7https://www.w3.org/TR/sparql11-overview/8https://www2.opengroup.org/ogsys/catalog/C14A9https://www2.opengroup.org/ogsys/catalog/C14B10http://www.opengroup.org/



ExecutiveSummary

ThebIoTopeprojectlaysthefoundationforcreatingopeninnovationecosystemssupportingtheInternetofThings(IoT)byprovidingaplatformthatenablescompaniestoeasilycreatenewIoTsystemsandtorapidlyharness available information using advanced Systems-of-Systems (SoS) capabilities for connected smartobjectsandeasilycratinginnovativebusinessprocesses.Thisdeliverablepresentsanapproachtowardsestablishingaservicecomposition frameworkwhichallowsnon-programmerstoorchestrate IoTdevices, i.e., todetectandreactoncertaineventsbyspecifyingdataflows.ItisbasedonleveragingthestandardsO-MIandO-DF,whichareusedbyIoTdevicesthroughoutthebIoTopeecosystemandprovideastandardmethodtointeract(e.g.,update,subscribefornotifications)withIoTdevicesanddata.However,thestandardizedrepresentationofO-MI/O-DFisbasedonXML,whichhasdisadvantageswhenintegratingdatafrommultiplesources.Inthisdocument,weintroduceourapproachofarepresentationmethodforO-MI/O-DFdatainaneasilyintegrableRDF-basedformatthatlaysthefoundationforusingexistinggraphical toolstoqueryandmanipulatethedata.Weprovidean implementationofthisapproachaswellasanoverviewongraphicaltoolsthatareavailableandwhicharelikelytobeusedtogetherwithourdatarepresentationapproachtoestablishGUI-drivenservicecomposition.ThedeliverabletakesintoaccountusecasesandinteractionscenariosdefinedinDeliverableD2.1aswellasinteractionpatternsdeducedinDeliverableD5.1,andshowshowtheproposedapproachsupportsthem.Fromatechnologyperspective,thecontributionsofthisdeliverablecomplementDeliverableD3.2whichintroducesan Information Source and Consumption Framework. Furthermore, deciding for Linked Data and RDF asunderlyingdataformatforservicecomposition isalignedwiththeactivities inWP4,especiallyreported inDeliverableD4.2describingaKnowledgeRepresentationandInferenceFrameworkusingthesetechnologies.



1. Introduction

1.1. ObjectivesinWP5

TogetanoverviewonthepositionofthisdeliverablewithinthecontextofWorkPackage5,inthefollowing,weshortlysumuptheworkpackage’sobjectivesanddocumentthetasksthathavealreadybeenaddressedorwillbedoneasfuturework.

• IdentifyanddescribeIoTinteractionpatternsandIoTobjectsthatareapplicableinbIoTopepilots:ThiswasthemainfocusofDeliverableD5.1.Inthisdeliverable,werevisittheidentifiedinteractionpatternsanddiscusshowtheycanberealizedwithourproposedapproach.

• Provide intuitive, user-friendly graphic tool that allows developers and non-programmers tocomposeandassembleXaaScomponentsandservicesinavisualmanner:Anoverviewofexistinggraphical tools that fit this purpose is provided in this document in section “Graphical UserInteraction”.AsworkontheServiceCompositionFrameworkwillproceed,wewillselectoneofthementionedtoolsandadoptandintegrateitinordertobuildaworkingprototype.Thistaskdefinesthegoalweworktowardsinthisdeliverable.

• Develop customizable UI widgets including a multitude of features (e.g., equipment statusindicators,alarms,graphsofsensorvalues,statisticsontraffic...)thatcanbeusedforcomposingpersonalizeddashboardsinwebbrowsers,smartphonesandotherdevices:BasicUIwidgetshavealreadybeen identified inDeliverableD5.1,morecomplexwidgetscovering,forexample,dataanalysiswillbeintroducedinDeliverableD5.4.

• Developcontext-sensitiveend-userdashboardsthatcanself-adaptthelayout,contentsandotherpropertiesofthedashboardaccordingtotheuser’sorobject’slocation,profile,surroundingandbehavior,possibleevenlearningfromuserbehavior:ThisobjectiveiscoveredbyDeliverableD5.3,forwhichresearchiscurrentlyongoingandwhichisduebyM18.D5.3willbebasedonboth(i)theinteractionsituationsandUIwidgetidentifiedinD5.1and(ii)theRDFrepresentationofO-MI/O-DFdatawhichisprovidedinthisdeliverableandwhichisonepossibleinputformatforcreatingend-userdashboards.

1.2. ObjectivesinTask5.AThe scope of this deliverable is embedded in Task 5.A of Work Package 5. The requirements from thedescriptionofworkarethefollowing:“BecausebIoTopesoftwarecomponentswill support standardizedOpenAPIs,notablyO-MIandO-DF, it ispossibletorepresenttheminagenericwayas“functionblocks”withinputsandoutputsthatcanbeconnectedtogetherwithoutprogramming.Thissignifiesthatnew,assembledcomponentsandservicescanbeconfiguredalsobynon-programmers,includingservicesthatconnectvariousinputsourcesandeventstosuitableactions,possiblypassingbyoneorseveral“processingblocks”,therebymakingitpossibletoimplementtheidentifiedinteraction patterns (D5.1), without programming. Such tools exist in many platforms and domains(automation systems, JavaBeans composition editors...). Based on the recognized interaction patterns andproposedsolutionsinexistingpublications,thistaskwillnotdevelopsucheditorsfromscratch;ratheritaimstomakeuseofexistingsolutions.“Theworkwhichwereport in thisdeliverableaddresses these requirementsbyproposinganapproach forintegratingmultipleIoTdevicesthatsupportO-MI/O-DFonthedatalevel.WeprovideanimplementationofthisapproachwhichestablishesthefoundationstouseexistingGUI-basedtoolsforperformingthenecessaryactionsthatallownon-programmerstoorchestrateIoTdevices.Inthecurrentstateofwork,wedescribehowserviceinteractioncanworkonthedatalevel.However,wealsogiveanoverviewoftoolsthatweconsidertohavethepotentialtosupportthisprocessontheuserinterfacelevel.



1.3. ContentofthisDocument

Thisdocumentisstructuredasfollows:afterprovidinganintroductiontotheworkpackagesgoalandtheroleofthisdeliverable,inSection2wediscusstheproblemdomainofIoTservicecompositionandhowitisrelatedtothegoalsandobjectivesofWorkPackage5.Section3outlinesourapproachtoovercometheidentifiedproblemsbyintroducinganexemplarysettingthathelpsillustratingthebasicprinciples.Afterthat,Section3concretizes themethods by examples based on real-world data. Section 4 describes the architecture andintegrationmethodwehavechosentoimplementthedata-integrationplatformthatfollowsourapproachanddrives theservicecomposition framework.Section5providesanoverviewon tools forgraphicaluserinteractionthatmaybeusedasafrontendforservicecomposition.InSection6,wediscussrelatedworkthathasalreadybeendoneinthefield,andSection7concludesandoutlinesfutureworktowardsaUI-enabledservicecompositionframework.



2. ProblemDefinition

ThegoalofanIoTecosystemsuchasbIoTopeistoprovideaplatformtointegratemultipleIoTobjectssothattheyareusable followingclearlydefined,agreed-upondata formatsandprotocols.An IoTobject isadatasourceordataconsumer(orboth)thatprovidesservicesorinvokeservicesofotherIoTobjects.IoTobjectscancoverawidevarietyofcomplexity:theycan,forexample,beimplementedasanetwork-awaresensorthatmeasuresandprovidestemperaturedataor,towardstheotherendofthecomplexityscale,theoften-citedsmartfridgewhichisawareofthestatusoftheproductsitcontains,sothatitcanautomaticallyrestockitself,basedontheowner’sneedsandpreferencesandwiththegoalofminimizingwasteoffood.

2.1. bIoTopeSoftwareComponentsInteraction

WithinthebIoTopeecosystem,softwarecomponentsareabletoexchangeinformationbyusingtheO-MI/O-DFstandard.Itprovidesthebasisofcommunicationandinteroperabilityandallowsfortheintroductionofadditional components like context, knowledge or user interfaces “as a service” (XaaS). The unique dataformatallowstotreatIoTobjectsandsoftwarecomponentsasblackboxes,onlymakinguseofthedatatheyprovideorconsumeandtorealizetheUserInterfaceasaService(UIaaS)approach.BasedonthedataprovidedbyIoTobjectswhichconformtotheO-MI/O-DFstandard,weidentifytwoobjectivesforestablishingUIaaS.Itshouldbepossible to (i) automatically createuser interfaces (intended tobedisplayed indashboards) forinteractingwiththesedevices,basedonapredefinedUIwidgetlibrary,and(ii)towiretogethercomponentsandservicesandorchestratethemaccordingtocertainrulesbyusingexistingtoolswithoutanyprogramminginvolved.InordertomakeuseofanIoTecosystem,bothobjectives(i)and(ii)mustbemet,becausetheyarerequiredbycommoninteractionscenarios:

• Objective (i) is necessary for providing easy interaction (maybe just read-only) with deployed IoTobjects.ThesemaybesingleobjectssuchasabottlebankthatreportsafillstateaswellasaggregateddatafrommultipleIoTobjects.

• Objective (ii) is required so that users can easily create additional value by orchestrating (i.e.,combininginputsandoutputs)IoTobjects.Targetgroupforthisfunctionalityarebothexpertuserswithhighresponsibility(e.g.,trafficplanners)butalsoenduserswhomovethroughanIoTecosystemandwanttocustomizeitfortheirpurposeanddevices(e.g.,notificationonchargingstationswhenapproachingacity).

ThereiscurrentlynoexistingsolutiontoautomaticallycreateuserinterfacesforIoTobjectsthatpublishtheirdatausingO-MI/O-DF.Atthemoment,datafromIoTobjectsinthebIoTopeecosystemcanberetrievedinXML formatwhich requires additional knowledge of the nature of the IoT device to display its data in ameaningfulway(e.g.interpretdataasgeocoordinates).AlthoughO-DFsupportstheannotationofdatasetswithmetadata,thiscanonlybedoneusingfreetextandthereiscurrentlynocommonunderstandinghowtoextendthistosupportotherdataformatsorvocabularies.IfIoTdeviceswouldpublishdataenrichedwithsemanticssuchasthetypeofthevalues,thissemanticscouldbeinterpretedbyanUIaaScomponentsothatthemostmeaningfulUIcomponentfordisplayingthedataischosenoutofalibrary.Hence,inthisdeliverablewearguetoovercomethelackofsemanticsincurrentO-MI/O-DFdata(currentlyonlypain-textdescriptions,notmachine-friendlytosupportautomaticreasoning)byproposing amethod to annotateO-DF’s so-calledInfoItems andObjectswith semantic informationusingRDFresources.PleaserefertotheO-DFspecification11fordetailedinformationaboutthestructureofO-DFdocuments.FurtherstepstowardsgenericUIwidgetsforusewithO-MI/O-DFdataprovidingserviceswillbedocumentedintheDeliverablesD5.3(Context-SensitiveEnd-UserDashboardFramework)andD5.4(2Dand3DUIWidgetsLibrary).11https://www2.opengroup.org/ogsys/catalog/C14A



From the perspective of service composition and integration, the current XML-based O-MI/O-DFrepresentationmakesithardtointegratedifferentsourcesbecauseofmissinggloballyuniqueidentifiersandconsistent,agreed-uponsemanticsofvalues.WethereforearguetoconverttheXML-basedrepresentationofO-MI/O-DF to an RDF-based representation so that data can be combined with other data on theWebfollowingLinkedDataprinciples.ThisdeliverablethereforefocusesonreportingourprogressindevelopinganapproachforservicecompositioninthebIoTopeecosystembymakinguseofLinkedDatatechnologies.

2.2. ExemplaryIoTObjects

Table 1 provides some examples of IoT objects and their input and output data types as identified inDeliverable5.1.ItisevidentthatannotationsofdatatypesoftheIoTobject’soutputdataareimportantfordeterminingtheUIwidgetsinadashboardrepresentationoftheIoTobject.

IoTObject Input Output DashboardUIWidgetforOutput

Trafficcontroldevice(havingintegratedorseparateUIdevicesliketrafficlight,signs)

switchstatusrequest,setstatuschangefrequency

statusoneofredorgreen,stop/giveway

Colorindicator

Schoolschedule School-internalproprietarydatabase

currentlectureendtime,nextlecturestarttime

Timeline,clock,countdown

Roadsensor - temperature,statusofcondition(oneofdry,wet,slippery)

Cloudpictograms

Bottlebank - nextclosestbottlebanklocation,fillstatus

Percentagebar,Route

Car Preconditions(e.g.setmaximumspeedforaspecificuser)

currentspeed,destination

UIdevice-Smartphone location,route vibration,speech,directions

Map,turnindicators

UIdevice-Infoscreen Schedulewhentopresentwhatinformation,changefrequency(billboardfunction)

Text,images -

Contextsource(e.g.,Smartphone)

- movementstatus(walking,running,driving)

Movementpictograms

Table1:InterfacesofexemplaryIoTobjects



3. ApproachforIoTServiceIntegrationusingO-MI/O-DFandRDF

EffectiveorchestrationofIoTobjectsrequires(i)acommon,opendataformatthatisusedforbothinputandoutput data of the IoT objects and (ii) standardmethods and interfaces to describe the information flowbetweentwoormoreIoTobjects.InbIoTope,(i)iscoveredbyusingO-MI/O-DFasthedataexchangeformatbetweenIoTdevicesand/orIoTsubsystems.However,(ii)hasnotyetbeenestablished.BecauseofO-MI/O-DFs’sstandardizedandwell-defineddataschemathatisbasedonXMLandtheusageofstandardHTTPcallstomodifyO-DFstructures(viaO-MInodes),existingtoolsforissuingthecallscanbeused.Examplesarethecommand-linebasedtoolcurl12ortheGUI-baseddashboardNode-RED13,whichisauser-friendlytooltoorchestrateinformationflowsbetweenAPIs.AnO-MInodepluginforaNode-REDcomponentexistswhichcanbeusedtointegratethemwithexistingIoTdevices.However,usingNode-REDtoorchestrateIoT devices located in differentO-MI nodes by HTTP calls is tedious and error prone. Definition rules fororchestrationthatdependontheIoTobject’sdataarealsohardtoexpressinNode-REDfornon-programmers,becausethisrequiresimplementationofJavaScriptmethodsthatareprocessinganode’sinputandoutputvalues.Wethereforeproposeanapproachthathasproventobeusefulintheenterprisedataintegrationdomain,especiallywhenworkingwithdatasources thatprovidedifferent typesof information.Thisapproachalsosupportslogicalreasoningandthereforetheinferenceofnewknowledgefromthedata.ItusesanRDF-baseddatamodel(theO-DFOntology)thathasbeenderivedfromtheO-MI/O-DFspecification.TheO-DFstructuresofallIoTobjectsthatshouldbeintegratedcanbeexpressedfollowingthisontologyandstoredinacommondatabase,whichisatriplestoreexposingaSPARQLinterface.

3.1. SpecifyingIoTDeviceInteraction–AnExemplarySetting

Inan IoT service composition framework it isessential tohaveameans fordefining the information flowbetween IoTobjects.Weproposean approach for realizing sucha service composition/orchestration andillustrate it by an example that is based on the Brussels “SafeRoad” pilot use casewhich is described inDeliverable2.1.Inthisusecase,thesafetyofchildrenontheirwaytoandfromschoolshouldbeimprovedby“influencingthetrafficaroundchildren”thatisdonethroughtrafficsignalizationandgamificationapproaches.Inourexample,wethereforefocusontwoIoTobjectsthatareinvolvedinthisusecase:

1. Theschoolschedulethatindicateswhetherthereiscurrentlyalessoninprogressandifandwhenthenext lesson will start. This is, of course, very simplified since we assume only one schedule andtherefore only one school class.We suppose that the schedule provides three information fields(calledInfoItemsintheO-DFspecification):

a. lectureInProgress: abooleanfieldindicatingifthereiscurrentlyalecturegoingon b. nextLectureStart: thetimethenextlecturewillstartc. timeUntilCurLectureEndSec: holdstheremainingsecondsofthecurrentlecture(if

any)2. Apedestriantrafficlightsystemwithtwolights(redandgreen)andatimerthatswitchesbetween

thelights.Forthepurposeoftheexample,thisisagainverysimplified,andweimplicitlyassumethatthetrafficlightsystemisembeddedinalargercontextofsignalingsystems,forexample,accompaniedbyacartrafficlightsystemwhichadjustsaccordingtochangesinthepedestriantrafficlightsystemsetup.WesupposethatthetrafficlighthasonewritablefieldstatusChangeFreqSec thatholdsthesecondsbetweenalightstatuschange(red->greenandviceversa).

12https://curl.haxx.se/13https://nodered.org/



Inthissetting,apossibleservicecompositioninvolvingthesetwoIoTobjectscouldbetocoverthedirective“Iftheschoolcalendarindicatesthatthelastschoolhourofthedayisabouttoend,thetrafficlightinfrontoftheschool’sexitshouldbeconfiguredforalongergreenphase.”Even inourverysimplifiedexample, this involvesknowledgeofboththecalendar’sandtraffic light’sdatamodels,readandwriteaccesstoselecteddataitemsprovidedbytheIoTobjectsandaformalway(language)tospecifyevents(e.g.,pollingoftheschoolscheduleorproactivenotificationbytheschedulethatthestartorendtimeofanentryinithasbeenreached),conditions(“schoolcalendarindicatesthatthelastschoolhourofthedayisabouttoend”)andactions(“trafficlightshouldbeconfiguredforalongergreenphase”).TheIoTdeviceinteractioninourexamplecanbeexpressedinanalgorithmicwaylikeinthefollowinglisting,usingJava-likepseudo-code: schoolSchedule.onTimerPollEvent () { if (calendar.lectureInProgress == true && calendar.nextLectureStart == null && calendar.timeUntilCurLectureEndSec < 180) { trafficLight.statusChangeFreqSec = 30 } } Anotherwaywouldbetoformulatetheinteractionasadatabasequery.SupposeeachIoTobjectprovidesitsinformationfieldsusingRDF,asshowninthefollowingexampleusingTurtle14notation::schoolSchedule a iot:Calendar; iot:lectureInProgress true^^xsd:boolean; iot:timeUntilCurLectureEndSec 120; iot:nextLectureStart :noneForToday. :trafficLight a iot:TrafficLight; iot:statusChangeFreqSec 20. NotethatthisRDFrepresentationisdesignedtodescribeourexampleinaneasilyunderstandableway.Itisdifferentfromtheapproachweintroducebelowonasyntacticlevelbutthebasicprinciplesareidentical.Havingsuchadatarepresentationinplace,itisthenpossibletoachieveasimilarinteractionwithanIoTdeviceusinga(pseudo)SPARQLconstructstatementlikethefollowing:CONSTRUCT {:trafficLight iot:statusChangeFreqSec 30} WHERE { :schoolSchedule iot:nextLectureStart :noneForToday; :schoolSchedule iot:timeUntilCurLectureEndSec ?secsRemaining; FILTER (?secsRemaining < 180) } Thesetwoapproachesarefundamentallydifferent.Whilealgorithmicimplementationsoperateinaclosedworld,SPARQLassumesanopenworld.Javaobjectsareinaclearlydefinedstateatanytimeandnon-existinginformationisconsideredfalse.Incontrast,whenIoTobjectspublishtheirdataasRDFtriples,theseareusuallyinterpreted in away that information that is not explicitly stated is considered as unknown (openworld

14https://www.w3.org/TR/turtle/



assumption). Furthermore, the RDF data stream of IoT objects must include timestamps for each of theproperty’s values, so that themost recententry,which is validat themoment, canbe identified. For thesimplicityoftheexampleabove,weomittedtimestamphandling.Comparedtothealgorithmicimplementation,RDFandSPARQL-basedIoTobjectorchestrationhasnumerousadvantages:

• AsRDFisbasedongloballyuniqueIDs(URIs)andexpressesstatementsastriples,RDFdataofmultipleIoTdevicescanbecombinedeasilybyaggregatingitintothesametriplestore.

• IoTdevicescansharecommonvocabulariesanddatamodels,whicharedefinedontheWeb(e.g.,theSemanticSensorNetworkOntologyorcommonvocabulariesforunitsofmeasurements).

• Semantic information fromdatamodelsand instancedatacanbeusedtoautomatically infernewknowledgebasedonSemanticWebreasoningtechniques.

• ExposingIoTdataasRDFallowsustoreuseexistingtoolsforinteractivelyexploringRDFtriplestores,aswellastoolstographicallyqueryRDFtriplestores,addressingtherequirementthat“assembledcomponentsandservicescanbeconfiguredalsobynon-programmers”,asstatedinthedescriptionofworkofTask5.Awhichisaddressedbythisdeliverable.

3.2. ExpressingO-DFStructuresusingRDFForidentifyingO-DFInfoItemsbasedonacommonstandardizedvocabulary,weproposetousetwoadditionaloptionalattributesintheO-DFschemathatarecompatiblewiththeexistingO-DFschemadefinition:

• TheattributeclasstoannotateanInfoItem’sclassusinganURI,and• TheattributepropertytobeusedtogetherwiththeO-DFvalueelementsothatanURIcanbe

specifiedwhich can be used as an RDF property to express the value. If such an attribute is notspecified,thedefaultpropertyforannotatingvalues,odf:dataValue,isused(illustratedintherepresentationofthetrafficlightobjectfurtherbelow).

3.2.1. O-DFStructureofaScheduleIoTObjectThefollowingcodeillustrateshowtheO-DFdatastructureofanIoTscheduleobjectcanbeextendedbyclassandpropertyattributestolinktoresourcesontheWeb(indicatedinboldfontface):

<Objects> <Object type=“Schedule for a school class”> <id>SSMS_3C</id> <InfoItem name=“Time left of current lesson for class” class=“ex:TimeLeftCurLesson”> <description> Time in seconds until current lesson end. </description > <value dateTime=“2001-10-26T15:34:15” type=“xs:integer” property=“iot:timeUntilCurLectureEndSec”> 121 </value> </InfoItem> <InfoItem name=“Upcoming lesson for class” class=“ex:NextLecture”> <description>Begin date and time of upcoming lesson.</ description > <value dateTime=“2001-10-26T15:34:15” type=“xs:dateTime” property=“ iot:nextLectureStart”> 2001-10-26T15:33:21 </value> </InfoItem> </Object> </Objects>



3.2.2. RDFRepresentationofthisStructureTheXML-basedO-DFstructurecanbetranslatedtoanRDFrepresentationinastraightforwardwayusingtheO-DFOntology(seeAppendix):

ex:ssms_3c a odf:Object; skos:notation “SSMS_3C”; odf:infoItem [ a ex:TimeLeftCurLesson; a odf:InfoItem; dct:title “Time left of current lesson for class”; dct:description “Time in seconds until current lesson end.”; odf:value [ dct:created “2001-10-26T15:34:15”^^xsd:dateTime; iot:timeUntilCurLectureEndSec 121^^xsd:integer ] ] odf:infoItem [ a ex:NextLecture; a odf:InfoItem; dct:title “Time left of current lesson for class”; dct:description “Time in seconds until current lesson end.” odf:value [ dct:created “2001-10-26T15:34:15”^^xsd:dateTime; iot:nextLectureStart “2001-10-26T15:33:21”^^xsd:datetime; ] ].

3.2.3. O-DFStructureofaTrafficLightIoTObjectThefollowingcodeillustratestheO-DFdatastructureofanIoT-enabledtrafficlight:

<Objects> <Object type=“Pedestrian traffic light”> <id>PTL_123</id> <InfoItem name=“Red light status” class=“ex:RedLightStatus”> <id>RedLight</id> <value type=“xs:boolean”>true</value> </InfoItem> <InfoItem name=“Green light status” class=“ex:GreenLightStatus”> <id>GreenLight</id> <value type=“xs:boolean”>false</value> </InfoItem> <InfoItem name=“Status change frequency” class=“ iot:statusChangeFreqSec”> <id>StatusChangeFrequency</id> <description>Time in seconds the lights switch status</description> <value type=“xs:integer”>15</value> </InfoItem> </Object> </Objects>

3.2.4. RDFRepresentationofthisStructureInthesamewayasthescheduleIoTobject,theRDFrepresentationofthisdatalooksthefollowing:



ex:ptl_123 a odf:Object; skos:notation “PTL_123”; odf:infoItem [ a ex:RedLightStatus; odf:value [ dct:created „2001-10-26T15:34:15”^^xsd:dateTime; odf:dataValue true^^xsd:boolean; ] ] odf:infoItem [ a ex:GreenLightStatus; odf:value [ dct:created „2001-10-26T15:34:15”^^xsd:dateTime; odf:dataValue false^^xsd:boolean; ] ] odf:infoItem [ a iot:statusChangeFreqSec; odf:value [ dct:created „2001-10-26T15:34:15”^^xsd:dateTime; odf:dataValue 15^^xsd:integer; ] ].

3.3. RealizingRDF-basedServiceIntegrationusingSPARQLThefollowingSPARQLconstructqueryshowshowvaluesofIoTobjectscanbemanipulated.Itexpressesthestates that threeminutesbeforetheendofaday’s last lecture, thevalueofa traffic light’sstatuschangefrequencyshouldbesetto30(insteadof15whichwasthepreviousvalue).Tokeepthisexamplesimple,weassumethatthedataofthetwointegratedIoTobjectsisavailableinoneSPARQLendpoint,andthatforeachInfoItemonlyoneodf:value(themostrecentone)isstored.

CONSTRUCT { ?statChangeInfItem odf:value _:newVal. _:newVal dct:created now(); odf:dataValue 30^^xsd:integer. } WHERE { ?statChangeInfItem a ex:StatusChangeFrequency. ?timeleftInfItem a ex:TimeLeftCurLesson; odf:value/ex:remainingSecs ?remainingSecs. ?nextLectureInfItem a ex:NextLecture; odf:value/ex:start ?nextLectureStart. } FILTER ((?remainingSecs < 180) && (day(?nextLectureStart) > day(now()))



4. O-DFtoRDFConversionPrototypeArchitecture,IntegrationandImplementation

We provide a prototype implementation that performs the conversion of O-DF data structures into arepresentationusingRDFfollowingtheapproachoutlinedintheprevioussection.ForeasyintegrationwiththebIoTopeecosystemwechoseaservice-basedapproach,i.e.,theconversionlogicisembeddedinaservicewe call OORI (O-MI/O-DF RDF Integration Server) that communicates with other components (e.g., O-MInodes)byHTTPcalls.

4.1. Architecture

Figure1:OORIArchitectureandbIoTopecomponentinteractions

Figure1providesanoverviewonthecomponentsoftheOORIserver(indicatedbythedashedgreenline)andtheirinterfaces.TheOORIserverconsistsofaconversionservicecomponentwhichreceivestheURIofanO-MInodeandtheO-MI/O-DFXMLstructuredescribingtheobjectsthatshouldbeconverted intotheirRDFrepresentation.Thisstructurecaneitherbegeneratedmanuallybyusers(forexampleO-MInodeoperators)orbytheIoTBnBplatform(seealsoFigure2).TheO-MI/O-DFXMLstructureisthenconvertedintoanO-MIsubscriptionmessage so thatoneachvalue change, theO-MInode calls the conversion service’s callbackmethod.Whenthecallbackmethodistriggered,theconversionservicecreatestheRDFgraphoftheO-MI/O-DFstructureandstoresittoanRDFserverrunningonthesamehost.ThisRDFservercanbeusedforSPARQLintegrationqueries,coveringdatafromallO-DFstructurestheconversionserviceissubscribedto.



4.2. IntegrationWorkflowwithExistingbIoTopeComponents

Figure2:ExampleworkflowforOORIintegrationwithinbIoTope

Figure2describesthesystemsinvolvedinourproposedapproachandtheinformationflowbetweenthem.Onthelefthandsideofthefigure,theIoTEnvironmentofauser,exemplarilycalled„Jeremy”,isillustratedby a dashed-line circulated area. It consists of anO-MI node and theuser itself, interactingwith anothersystem,theIoTBnBplatform.Thisplatformisaseparate,publiclyavailableserverthatpublishesIoTdatainO-MI/O-DFformat.Thesystemswithinthedashed-linedgreyareasalreadyexistandnumerousinstancesaredeployedontheWeb.Ourcontributioninthisdeliverable,theO-MI/O-DFIntegrationServer(OORI)isoutlinedontherighthandsideofFigure2usingthegreendashedline.OORI performs the conversionofO-MI/O-DFdata in anRDF representation, using anO-DFontology. It iscurrentlydesignedtobeinstalledasastand-aloneserverontheWeb,exposingitsservicesasRESTendpoints.However,ifsensitiveinformationshouldbeprocessed,operatingapublicOORIservermayraisessecurityorprivacyconcerns.Therefore,itisalsopossibletorunOORIwithinthepremisesof,e.g.,theuserJeremy.Inthefuturewealsoplan to integrateOORI’s functionalitywith the capabilitiesofO-MInodes so that they candirectlydealwithRDFdataandavoidprivacy,securityorperformanceproblems.AtypicalworkflowofOORIintegratedinthebIoTopeecosystemcouldlookasfollows:

1. Jeremydecidestopublish IoTdataofhis localO-MInodeusingtheIoTBnBplatform.HethereforesendsanappropriaterequesttotheIoTBnBserver.

2. InhisrequesttotheIoTBnBserver,Jeremyhasadditionallystatedthathewantshisdatatobepubliclyavailable as Linked Data using OORI. Based on this decision, the IoTBnB server sends the URL ofJeremy’s O-MI node and the O-MI/O-DF XML request that states the InfoItems that should bepublishedtotheOORIserver.

3. TheOORIserversubscribesitselftoJeremy’sO-MInodetogetnotifiedonchangesofthepublishedInfoItems.

4. Whenever changes to an InfoItem’s value occur, they are converted to the corresponding RDFrepresentationandpersistedintoOORI’sinternalRDFtriplestore.

5. IfthedataischangedinOORI’sinternaltriplestore(e.g.,byaSPARQLdeleteorinsertrequest),thedataonJeremy’sO-MINodemustbeupdatedaswell.This isnotyet implementedandsubjectoffuturework.



4.3. PracticalExample

Inthefollowingweshowhowtheworkflowoutlinedabovecanbeappliedtoareal-worldscenariousingpublicdataaboutbikestandsinBrussels.

Figure3:O-MInodeprovingdataonbikeparkingspots

Figure3showsmultipleIoTobjectsthatrepresentbikeparkingspotswithavailablebikesandbikestands.Thetreeintheupperleftareaofthescreenshotshowsoneselectedparkingspot(withtheid328).The„Request”sectionrightnexttoitshowstheO-MI/O-DFrequestthatcanbeissuedagainsttheO-MInodetoreceivetheactualdataoftheobject.ThisrequestcanalsobesenttogetherwiththeO-MInode’spublicURItotheOORIserver,sothatcontinuousconversionoftheparkingspot’sdataintoRDFisperformed.



Figure4:O-MI/O-DFrequestandresponsemessagesforaccessingparkingspacedata

Thelowersection(labeled„Response”)ofthescreenshotshowninFigure4showstheO-MI/O-DFresponsethatcontainsdataofallparkingspotobjects.Inthisexample,wefocusonthedataoftheparkingspotwiththeid328,whichindetaillooksasfollows:

<omi:omiEnvelope ttl=“10.0” version=“1.0” xmlns=“odf.xsd” xmlns:omi=“omi.xsd” xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”> <omi:response> <omi:result msgformat=“odf”> <omi:return returnCode=“200”></omi:return> <omi:msg> <Objects> <Object> <id>BrusselsBikesParkingSpot</id> <Object> <id>328</id> <InfoItem name=“AvailableBikeStands”> <value unixTime=“1480788671” dateTime=“2016-12- 03T18:11:11.854Z” type=“xs:int”>9</value> </InfoItem> <InfoItem name=“AvailableBikes”> <value unixTime=“1480788671” dateTime=“2016-12-



03T18:11:11.854Z” type=“xs:int”>11</value> </InfoItem> </Object> </Object> </Objects> </omi:msg> </omi:result> </omi:response> </omi:omiEnvelope>

OORIconvertsthisinformationintoanRDFgraph andstoresitinanRDFtriplestorethatcanbequeriedusingSPARQL.Forexample,togetanoverviewonallodf:Objectsinthegraph,thequery

SELECT * WHERE { ?s a odf:Object; }

canbeissuedagainstthetriplestore,whichrevealsthatthereisaparkingspot328representedbytheresource

http://eis-biotope.iais.fraunhofer.de/localhost/obj/BrusselsBikesParkingSpot/328

thatcanbefurtherqueried.ASPARQLquerylike

DESCRIBE <http://eis-biotope.iais.fraunhofer.de/localhost/obj/BrusselsBikesParkingSpot/328>

canhelptofurtherexploretheknowledgegraphthisparkingspotprovides.Itresultsin,e.g:

<http://eis-biotope.iais.fraunhofer.de/localhost/obj/BrusselsBikesParkingSpot/328> a odf:Object ; <http://www.w3.org/2004/02/skos/core#notation> “328”; odf:infoitem <http://eis-biotope.iais.fraunhofer.de/localhost/infoitem/BrusselsBikesParkingSpot/328/AvailableBikes> , <http://eis-biotope.iais.fraunhofer.de/localhost/infoitem/BrusselsBikesParkingSpot/328/AvailableBikeStands>.

Tochecktheavailablebikesofthisspot:

DESCRIBE <http://eis-biotope.iais.fraunhofer.de/localhost/infoitem/BrusselsBikesParkingSpot/328/AvailableBikes>

resultingin

<http://eis-biotope.iais.fraunhofer.de/localhost/infoitem/BrusselsBikesParkingSpot/328/AvailableBikes> a odf:InfoItem ; <http://purl.org/dc/terms/title> “AvailableBikes” ; odf:value [ a odf:Value ; odf:dataValue “11”^^<xs:int> ; <http://purl.org/dc/terms/created> “2016-12-



03T18:11:11.854Z”^^<http://www.w3.org/2001/XMLSchema#dateTime> ].

Similarly,tochecktheavailablebikestandsofthisspot,thequery

DESCRIBE <http://eis-biotope.iais.fraunhofer.de/localhost/infoitem/BrusselsBikesParkingSpot/328/AvailableBikeStands>

canbeissuedwhichprovidesthefollowinginformation:

<http://eis-biotope.iais.fraunhofer.de/localhost/infoitem/BrusselsBikesParkingSpot/328/AvailableBikeStands> a odf:InfoItem ; <http://purl.org/dc/terms/title> “AvailableBikeStands” ; odf:value [ a odf:Value ; odf:dataValue “9”^^<xs:int> ; <http://purl.org/dc/terms/created>“2016-12-03T18:11:11.854Z”^^<http://www.w3.org/2001/XMLSchema#dateTime> ].

4.4. Implementation

WeprovidetheOORIserverunderanopensourcelicenseatGitHub15. It is implementedasaWebserviceusingtheSpringBootApplicationFrameworkandrdf4j16asalibrarytoserializeO-DFdatastructuresintoanRDFrepresentation.TheresultingRDFdataisstoredintoanRDFtriplestore.OORIperdefaultusesFuseki17forthistask.Fromadatarepresentationpointofview,O-MIandO-DFarenotboundtoaspecifictechnology.Althoughthestandards’documentsuseXMLSchemaasameanstospecifyO-MIandO-DF,otherrepresentationswouldbe possible. However, the prevailing format is XML and therefore a conversion into RDF needs to beimplemented.Variousapproachesfordataconversionsexist.[Dimou2014]introduceRML,agenericlanguageformappingmultipleformats(e.g.,JSON,XML,CSV)intoanRDFrepresentation.FocusingsolelyonRDFtoXMLconversionandviceversa,XSPARQL[Akhtar2008,DellAglio2014]isanapproachthatcombinesXQueryandSPARQL.Currently,theXMLtoRDFconversiondonebyOORIisbasedonanintermediatestepofcreatingan in-memoryJavabeanmodelfromtheXMLrepresentationandthenserializing ittoRDFusingtheO-DFontology(seeAnnex1).InfutureversionsofOORIimplementationswearegoingtoevaluateifthementionedapproacheshaveadvantagesoverourcurrentimplementation.Foraneasytestingsetup,weprovideinstructionshowtobuildtheserveraswellasaDockercomposefileforsimplified deployment and demo data. In-depth instructions for building, deploying and using OORI areavailableintheprojectrepositoryaswell18.

15https://github.com/cmader/OORI16http://rdf4j.org/17https://jena.apache.org/documentation/serving_data/18https://github.com/cmader/OORI/blob/master/README.md



5. VisualUserInterfacesforRDFGraphExploration

InordertoenableusersunfamiliarwithRDFandSPARQLtoqueryLinkedData,visualinterfacescanprovidegraphicalsupport.TheinterfacesshouldenabletheflexiblecreationofSPARQLqueries,alsoforuserswithlittle or no knowledge about RDF, SPARQL, and related Linked Data technologies. In the following, weintroducesomevisualinterfacesthatcouldbewellappliedtothearchitecturedescribedaboveinordertosupportuserstoquerytheLinkedDatacompliantIoTdata.OneofthenexttasksintheprojectwillbetoapplyaselectionoftheseinterfacesandevaluatetheminthecontextofconcretebIoTopeusecases.Inaddition,visualinterfacessupportingservicecompositionwillbeinvestigatedandintegratedinoneofthenexttasks.

5.1. SparqlFilterFlow

We already introduced SparqlFilterFlow in the Service Composition Editors section in Deliverable 5.1.However, based on themethods and approachwe introduced in this document,we revisit it again as itsapplicationmaybecomemoreevidenttothereadernow.SparqlFilterFlowprovidesavisualinterfaceforthecompositionofSPARQLqueries.Figure5illustrateshowafilter/flowrepresentationofaSPARQLquerycanlooklike.Theleftsideshowsaqueryformalizingthecondition“retrieveallbookswithatleastoneauthorwhohaswonanawardandatleastoneauthorwhoselanguageisEnglish”.Anotherqueryisrepresentedontheright-handsideofthefigure.ItretrievesdataaboutislandsprovidedbyDBpedia,filteredbyvariouscriteriasuchasareaorpopulation.InthecontextofbIoTope,afilter/flowvisualizationandinteractionapproachcouldbeprovedasusefulfororchestratingIoTobjects.Incontrasttorelatedwork,nostructuredtextinputisrequiredbutthequeriescanbe created entirelywith graphical elements [Haag2014],meeting one of the requirements for a bIoTopeservicecompositionframework.Furthermore, using SparqlFilterFlowwould transparentlymake use of rules that can be evaluated in thebackgroundbytheusedtriplestore(e.g.,basedonOWLaxioms),inferringadditionalknowledgefromtheIoTdata.Dependingonthedeploymentlocationofthistriplestore(i.e.,iteitheraggregatesallthedatainoneplaceoraccompanieseachIoTdeviceholdingonlylocaldata),evenpeer-to-peerreasoningusinglocalrulebaseslikeintroducedby[Kortuem2010]canbeimplemented.Thefilter/flowgraphscouldbeusefulforbothconstructingsuchrulebasesaswellastointerconnectdevicesthatprovidethem.



Figure5:GraphicalrepresentationofSPARQLqueriesinSparqlFilterFlow

5.2. QueryVOWL

SimilartoSparqlFilterFlow,QueryVOWLprovidesavisualinterfaceforthecompositionofSPARQLqueries.IncontrasttoSparqlFilterFlow,itisnotbasedonthefilter/flowmodelbutontheontologyvisualizationlanguageVOWL[Lohmann2016].VOWLdefinesmappingsofOWLlanguageconstructstographicalelementsthatarecombinedtonode-linkdiagrams.Similarly,QueryVOWLhasbeendesignedasaneasytouselanguagewithclearmappingstoSPARQL[Haag2015].Thequeriescanbecreatedentirelywithvisualelements,takingintoaccountRDFSandOWLconceptsoftenusedtostructurethedata.WhenaQueryVOWLgraphisappliedtoagivenRDFdataset,allsubgraphsfromthedatasetthatmatchthequeryareretrieved.

Figure6:GraphicalrepresentationofSPARQLqueryinQueryVOWL

Figure6showsaQueryVOWLgraphforretrievinganymoviesalongwithtwooftheiractors,oneofwhombeingthechildoftheother.Thelatteractorisfocused,asthegraphisusedtoidentifytheelderactorofthetwo(accordingtothedirectionofthepropertychild).Theresult,i.e.,thenumberofinstancesinthedata(inthisexampleDBpedia)thatmatchthequeriesgraphpatternisshownasanumberinthefocusednode.



5.3. LD-VOWL

LD-VOWLisalsobasedonthevisualVOWLlanguage.IncontrasttoQueryVOWL,itisanotaquerytoolbutautomaticallyextractsschemainformationfromtheLinkedDataendpoint.Nevertheless,itreliesonSPARQL,asschemainformationisinferredviaanumberofpredefinedSPARQLqueriesandthengraduallyaddedtoaninteractiveVOWLgraphvisualization.Theextractionapproachusesaclass-centricperspective,i.e.,classesareextractedfirstanddefinetheviewontheLinkedDatasource.Theseclassesarethenconnectedbyobjectpropertiesandenrichedbydatatypes.Wehavechosenthisapproach,asaclass-centricperspectiveisverycommoninontologyengineeringandfitswellwiththenode-linkparadigmofthegraphvisualizationthattheVOWLnotationisbasedupon.The approach has been implemented in a web application and tested on several SPARQL endpoints[Weise2016].ItusesJavaScripttogenerateandsendtheSPARQLqueriesviaHTTP-GETrequestsinordertoextracttheTBox information.Theextracted information isvisualizedusingSVGandCSS.Furthermore,theapplicationmakesuseofthevisualizationtoolkitD319forcomputinganddisplayingtheforce-directedgraph.

Figure7:LD-VOWLvisualizationofschemainformationextractedfromaLinkedDataendpoint

5.4. RelFinder

Another visual interface that could be applied in the bIoTope context to analyse the linked IoT data andsupportservicecompositionistheRelFinder.ItextractsandvisualizesrelationshipsbetweengivenobjectsinRDF data and makes these relationships interactively explorable [Heim2010]. It thereby assists users todiscover unknown connections between data items. The information is extracted by generated SPARQLqueriesanddynamicallyaddedtothevisualization.Figure8showsascreenshotoftheRelFinderappliedtothepublicendpointofDBpedia.

19https://d3js.org



Figure8:ScreenshotoftheRelFindervisualizingfoundrelationships

6. ConclusionandFutureWork

Inthisdeliverable,weintroducedanapproachforrepresentingO-MI/O-DFdatausingtheRDFformatandamethod to introduce additional semantics to O-DF data using Linked Data technologies. We provide aprototypicalimplementationofthisapproachandoutlinehowitcanbeintegratedwithexistingservicesinthebIoTopeecosystem.Our immediate next steps will concentrate on cooperating with the project partners to (i) agree on anapproach how to integrate semantic annotations with O-DF structures and (ii) identify vocabularies werecommendinthebIoTopecontextforexpressingtheseannotationslike,schema.org20.ImprovedsemanticannotationswillenablerealizationofautomatedUIgenerationsuchasitisneededforend-userdashboards(DeliverableD5.3) thatarebasedonstandardUIwidgets (DeliverableD5.4).Wewill furthermoreworkonintegratingtheGUI-basedtoolsthatweidentifiedinthisdeliverableintoourprototypeimplementationforO-DFtoRDFconversiontoreachthegoalofaGUI-basedqueryingandservicecompositionframework.

20http://schema.org/



7. References

[Akhtar2008]Akhtar,W.;Kopecký,J.;Krennwallner,T.&Polleres,A.(2008),XSPARQL:TravelingbetweentheXML and RDF Worlds - and Avoiding the XSLT Pilgrimage., in Sean Bechhofer; Manfred Hauswirth; JörgHoffmann&ManolisKoubarakis,ed.,'ESWC',Springer,,pp.432-447.[Dadzie&Rowe2011] Dadzie, A. S., & Rowe, M. (2011). Approaches to visualising linked data: A survey.SemanticWeb,2(2),89-124.[DellAglio2014]Dell'Aglio, D.; Polleres, A.; Lopes,N.& Bischof, S. (2014),Querying theWeb of DatawithXSPARQL1.1.,inRubenVerborgh&ErikMannens,ed.,'ISWCDevelopersWorkshop',CEUR-WS.org,,pp.113-118.[Dimou2014]Dimou,A.;Sande,M.V.;Colpaert,P.;Verborgh,R.;Mannens,E.&deWalle,R.V.(2014),RML:AGenericLanguageforIntegratedRDFMappingsofHeterogeneousData.,inChristianBizer;TomHeath;SörenAuer&TimBerners-Lee,ed.,'LDOW',CEUR-WS.org,.[Haag2015]Haag,F.,Lohmann,S.,Siek,S.,&Ertl,T.(2015).QueryVOWL:avisualquerynotationforlinkeddata.In:ESWC2015SatelliteEvents,pp.387-402.Springer.[Haag2016] Haag, F., Lohmann, S., Bold, S., & Ertl, T. (2014). Visual SPARQL querying based on extendedfilter/flowgraphs. In: InternationalWorkingConferenceonAdvancedVisual Interfaces (AVI),pp.305-312.ACM.[Heim2010]Heim,P.,Lohmann,S.,&Stegemann,T.(2010).Interactiverelationshipdiscoveryviathesemanticweb.In:ExtendedSemanticWebConference(ESWC),pp.303-317.SpringerBerlinHeidelberg.[Kortuem2010]Kortuem,G.;Kawsar,F.;Sundramoorthy,V.&Fitton,D.(2010),'SmartObjectsasBuildingBlocksfortheInternetofThings.',IEEEInternetComputing14(1),44-51.[Lohmann2016]Lohmann,S.,Negru,S.,Haag,F.,&Ertl,T.(2016).VisualizingontologieswithVOWL.SemanticWeb7(4),pp.1-21.[Weise2016]Weise,M.,Lohmann,S.,&Haag,F.(2016).ExtractionandVisualizationofTBoxInformationfromSPARQLEndpoints. In:20thInternationalConferenceKnowledgeEngineeringandKnowledgeManagement(EKAW),pp.713-728.Springer.



8. Annex1

ThefollowinglistingshowstheO-DFOntologywhichisusedforrepresentingO-MI/O-DFdatainRDF.@prefix odf: <http://eis-biotope.iais.fraunhofer.de/odf#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . # Description of this ontology # ---------------------------- odf: a owl:Ontology; dct:title “Ontology for representing O-DF data structures”@en; dct:creator “Christian Mader” ; dct:publisher “Fraunhofer IAIS/EIS”; dct:date “2016-11-22”; owl:versionInfo “0.0.1”. # Classes # ------- odf:Object a owl:Class. odf:InfoItem a owl:Class. odf:Value a owl:Class. odf:MetaData a owl:Class. # Properties # ---------- odf:value a owl:ObjectProperty; rdfs:domain odf:InfoItem; rdfs:range odf:Value. odf:dataValue a owl:DatatypeProperty; rdfs:domain odf:Value. odf:metadata a owl:ObjectProperty; rdfs:range odf:MetaData; rdfs:range odf:InfoItem. odf:infoitem a owl:ObjectProperty; rdfs:range odf:InfoItem. odf:objects a owl:ObjectProperty; rdfs:domain odf:Object; rdfs:range odf:Object.

Documents

bIoTope D5.2 Service Composition Framework final