Communication between a first API and a second api

Abstract

A source device, a target device, a network node, a method, a computer program and a computer program each for the source device, the target device and the network are provided The method performed by the source device is for communication between a first API, hosted at the source device, and a second API, hosted at the target device, having different semantic models. The method comprises: obtaining, using an SDF mapping extension, an indication of a semantic model of the second API. The SDF mapping extension comprises: i) a first SDF quality comprising an API call definition, the API call definition comprises a first key relating to the second API, and ii) a second SDF quality comprising a first value corresponding to the first key; and transmitting, to the target device, a first message. A syntax of the first message is based on the obtained indication.

Description

[0001]COMMUNICATION BETWEEN A FIRST API AND A SECOND API TECHNICAL FIELD The disclosure herein relates to a source device, a target device and a networknode, and provides a method performed by the source device, a method performed bythe target device, a method performed by the network node, a corresponding computerprogram and computer program product each for the source device, the target device and the network node. BACKGROUND Acommunication device can expand or add new capabilities by negotiating withother similar communication devices. This negotiation is possible between similarcommunication devices. In case of heterogenous devices, the negotiation is possible ifeach communication device has an interpreter module (e.g. HyperCat) and then thecommunication device (i.e., a capability requesting device) adapts a request to be sentto the other similar communication devices by complying with the other communicationdevices' data format and / or API format. Currently, the negotiation is cumbersome froman interoperability perspective. Neither is the negotiation seamless enough to searchand / or acquire capabilities from a communication device belonging either to a differentdevice ecosystem or a different communication device within the same deviceecosystem. Semantic web, sometimes known as Web 3.0 , is an extension of the World Wide Web (WWW) through standards set by the World Wide Web Consortium (W3C). Thegoal of the Semantic Web is to make Internet data machine-readable. The vision ofSemantic web is for data to be shared, interpreted, and reused among applications without human deductive reasoning and inference. To enable data to be shared, interpreted, and reused among applications without human deductive reasoning andinference, the Semantic web requires human intervention to create data stores on theweb, build vocabularies, and write rules for handling data. However, creating contents(i.e., data stores on the web, building vocabularies, and writing rules for handling data)for the Semantic web is still a human task. The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. An SDF specification describes definitions of SDF Objects / SDF Things and their associated interactions (e.g. Events, Actions, Properties), as well as the Data types for the information exchanged inthose interactions. The SDF is designed to be an extensible format. The SDF describes ageneral data model which is similar to the data models used by Internet of Things (IoT)ecosystems such as Internet Protocol for Smart Objects (IPSO) Alliance, OpenConnectivity Foundation (OCF) and Zigbee Alliance. For example, an SDF data modelmay define objects with related interaction patterns, as well as complementarymetadata, such as license information. To model more complex IoT devices, acomposition mechanism is defined, with which SDF Things can be composed of SDF Objects or other SDF Things. The standardization and further development of SDF is currently on going in Internet Engineering Task Force (IETF). US20170300364A1 discloses modular electronic devices that are capable ofpredicting future availability of module combinations and associated computing resources and / or capable of predicting future tasks. SUMMARY Alimitation of Semantic web is that it may not be feasible for a communicationdevice to store multiple data model representations and / or interactions, especiallywhen the interactions belong to more than one domain, i.e., when a communicationdevice is configured to interact with another communication device belonging either toa different device ecosystem or a different communication device within the samedevice ecosystem. Additionally, it may not be feasible for a communication device toaccess and / or store information relating to multiple tools (e.g. Resource DescriptionFramework (RDF), Web Ontology Language (OWL), Extensible Markup Language (XML)) due to processing and / or memory constraints. A way to enable the Semantic mapping is to use a discovery phase for anapplication program interface (API) hosted on a client device without fully storing theentire semantic model but instead only storing the needed components that match those required by the API. Therefore, reducing the complexity and quantity of data that the application needs to manage and understand. The reduced context is normally achieved with schemas and shared data structures that are populated with the exchangeable assets that provides the semantics, but that would require a pre-agreement between the application and the client device of what terms (e.g. SemanticDefinition Format (SDF) objects / SDF Things) are required. This pre-agreement is notfeasible in certain scenarios (e.g. when different proprietary semantic models are beingused at the client device and the application; when the client device does not comprise adatabase of types of ecosystem which may interact with the device in the client device’smemory; when the client device has limited capacity, i.e., the client device may onlystore certain number of semantic models). Also, this pre-agreement is not feasible in usecases where the usages and components are more generic by nature. This pre-agreement furthermore does not allow ad-hoc interactions between devices. Nor doesthe pre-agreement support evolvability of APIs or a service that a communicationdevice is capable of providing. Therefore, Semantic web and SDF currently cannotprovide functionality to realize the vision of connected intelligent machines whichcomprises ad-hoc / dynamic interactions between devices. The Web of Things (WoT) standard tried to address some of the above-mentioned issues by introducing a data model known as WoT-Thing Description (WoT-TD). WoT-TD introduces a high-level set of vocabulary and data schema that targetsthe integration of communication devices using web technologies. The main issue with WoT-TD is that it addresses only a particular instantiation of a communication device (i.e, WoT-TD may address some of the issues for a communication device but not formultiple devices), which means that there are still some incompatibilities that may ariserelating to semantics interoperability between an API hosted on the communication.This incompatibility occurs since the API is commissioned to perform matching of thesemantics of the API to metadata provided by WoT-TD. For example, the WoT-TD may provide a property that is described as “on” or “off”, meanwhile semantics for the APImay be called “lock open” or lock closed”. This matching is easily performed by humanreasoning and inference, but for a device that is performing a discovery automaticallyand dynamically, the matching is complex and may also require translation. World WideWeb Consortium (W3C) Thing models (W3C-TM) provides another level of abstractionfor Things that are similar or share same type of capabilities, but deciding whichcapabilities apply to a particular instance for a Thing is, in many cases, predefined.Furthermore, understanding of the semantics related to the Thing is, in many cases,predefined. The possibilities to provide additional semantic (e.g. using dfn-semantictags) increase the complexity in the device since it is pointing to an RDF baseddescription and requires support for parsing and managing the RDF syntax in many cases. Hypermedia as the engine of application state (HATEOAS) also attempts to explain an API hosted at a communication device but does not provide translation forthe semantics utilized, so another communication device that utilizes such HATEOSwould need to be configured to interpret the semantics that the API hosted at the communication device is utilizing. The disclosure herein enables communication between applications hosted on different devices, wherein the devices may belong to the same device ecosystem (e.g. a first constrained application protocol (CoAP) device and a second CoAP device) butdevices may or may not share the same semantic model for their respectiveapplications. Also, the disclosure herein enables communication between applicationshosted on different devices, wherein the devices belong to different device ecosystems(e.g. a first constrained application protocol (CoAP) device and a second Zigbee device),wherein the different devices may or may not share the same semantic model for theirrespective applications. Furthermore, the disclosure herein enables communicationbetween applications hosted on the same device, but wherein the applications do notshare the same semantic model (e.g. a first HyperText Transfer Protocol (HTTP)message, a second Simple Network Management Protocol message).An object of the invention is to improve management of semantics between two APIs in a communication network. This and other objects are met by means of different aspects of the invention, as defined by the independent claims. According to a first aspect, a method performed by a source device is provided.The method is for communication between a first API hosted at the source device and asecond API hosted at a target device. The first API and the second API have differentsemantic models. The method comprises obtaining, using an SDF mapping extension,an indication of a semantic model of the second API. The SDF mapping extensioncomprises a first SDF quality comprising an API call definition, wherein the API calldefinition comprises a first key relating to the second API. The SDF mapping extensionfurther comprises a second SDF quality comprising a first value corresponding to thefirst key. The first value is the indication of the semantic model of the second API. Themethod comprises transmitting, to the target device, a first message. A syntax of thefirst message is based on the obtained indication of the semantic model of the second API. According to a second aspect, a method for communication between a first APIhosted at a source device and a second API hosted at a target device is provided. Themethod is performed by the target device. The first API and the second API havedifferent semantic models. The method comprises receiving, from the source device, afirst message. A syntax of the first message is based on an obtained indication of thesemantic model of the second API. The indication of the semantic model of the secondAPI is obtained using an SDF mapping extension. The SDF mapping extensioncomprises a first SDF quality comprising an API call definition, wherein the API calldefinition comprises a first key relating to the second API. The SDF mapping furthercomprises a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model of the second API. According to a third aspect, a method performed by a network node is provided.The method is for communication between a first API hosted at a source device and a second API hosted at a target device. The first API and the second API have different semantic models. The method comprises obtaining, using an SDF mapping extension, an indication of a semantic model of the second API. The SDF mapping extension comprises a first SDF quality comprising an API call definition. The API call definition comprises a first key relating to the second API. The SDF mapping extension further comprises a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model. The method further comprises receiving on the API call definition, from the source device, a request toprovide an indication of a semantic model of the second API. The method comprisestransmitting, to the source device, the obtained indication of the semantic model of the second API. According to a fourth aspect, a source device is provided. The source device isprovided for communication between a first API hosted at the source device and a second API hosted at a target device. The first API and the second API have differentsemantic models. The source device is adapted to obtain, using an SDF mappingextension, an indication of a semantic model of the second API. The SDF mappingextension comprises a first SDF quality comprising an API call definition, wherein theAPI call definition comprises a first key relating to the second API. The SDF mappingextension further comprises a second SDF quality comprising a first value corresponding to the first key. The first value is the indication of the semantic model ofthe second API. The source device is adapted to transmit, to the target device, a firstmessage. A syntax of the first message is based on the obtained indication of thesemantic model of the second API. According to a fifth aspect, a target device is provided. The target device is provided for communication between a first API hosted at a source device and a second API hosted at a target device. The first API and the second API have different semanticmodels. The target device is adapted to receive, from the source device, a first message.A syntax of the first message is based on an obtained indication of the semantic modelof the second API. The indication of the semantic model of the second API is obtainedusing an SDF mapping extension. The SDF mapping extension comprises a first SDFquality comprising an API call definition, wherein the API call definition comprises afirst key relating to the second API. The SDF mapping further comprises a second SDFquality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model of the second API. According to a sixth aspect, a network node is provided. The network node isprovided for communication between a first API hosted at a source device and a secondAPI hosted at a target device. The first API and the second API have different semantic models. The network node is adapted to obtain, using an SDF mapping extension, an indication of a semantic model of the second API. The SDF mapping extension comprises a first SDF quality comprising an API call definition. The API call definition comprises a first key relating to the second API. The SDF mapping extension further comprises a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model. The network node isadapted to receive on the API call definition, from the source device, a request toprovide an indication of a semantic model of the second API. The network node is adapted to transmit, to the source device, the obtained indication of the semantic model of the second API. According to a seventh aspect, a source device is provided. The source device comprises at least one processing circuitry. The source device comprises at least one memory. The at least one memory is connected to the at least one processing circuitry. The at least one memory storing program code that is executed by the at least one processing circuitry to perform the method according to the first aspect. According to an eighth aspect, a target device is provided. The target devicecomprises at least one processing circuitry. The target device comprises at least one memory. The at least one memory is connected to the at least one processing circuitry. The at least one memory storing program code that is executed by the at least one processing circuitry to perform the method according to the second aspect. According to a ninth aspect, a network node is provided. The network nodecomprises at least one processing circuitry. The network node comprises at least one memory. The at least one memory is connected to the at least one processing circuitry. The at least one memory storing program code that is executed by the at least one processing circuitry to perform the method according to the third aspect. According to a tenth aspect, a computer program is provided. The computer program comprises instructions which, when executed by at least one processing circuitry of a source device causes the source device to carry out the method according to the first aspect and / or, when executed by at least one processing circuitry of an target device causes the target device to carry out the method according to the secondaspect and / or, when executed by at least one processing circuitry of a network nodecauses the network node to carry out the method according to the third aspect. According to an eleventh aspect, a computer program product stored on a non-transitory computer readable medium is provided. The computer program product comprises instructions that, when executed by at least one processing circuitry of a source device, causes the source device to perform the method according to the firstaspect. Alternatively, or in addition, the computer program product comprisesinstructions that, when executed by at least one processing circuitry of a target device,causes the target device to perform the method according to the second aspect. Alternatively, or in addition, the computer program product comprises instructions that, when executed by at least one processing circuitry of an external node, causes the network node to perform the method according to the third aspect. Advantageously, the disclosure herein enables communication between devices without exchanging information about capabilities of the devices with each otherbeforehand. Hereby, an improved resource (e.g. time resource, memory space,operational complexity) management is achieved. Advantageously, the disclosureherein enables an initial connection (e.g. a handshake) between the devices, allowing for more efficient data transfer. The disclosure herein advantageously enablesdescription of APIs. Furthermore, the disclosure herein provides information on how toutilize and / or interact with an API hosted at a target device by describing the API usingsemantics that a requesting API hosted at a source device may interpret (i.e.,understand, process). The disclosure herein further provides a means for the API hostedat the source device to access a service hosted at the target device.BRIEF DESCRIPTION OF THE DRAWINGS The above, as well as additional objects, features and advantages of the invention, will be better understood through the following illustrative and non-limiting detailed description of embodiments of the invention, with reference to the appended drawings, in which: Fig.1 illustrates an embodiment of a communication network of the invention. Fig. 2 illustrates an embodiment according to a method performed by a sourcedevice of the invention. Fig. 3 illustrates an embodiment according to a method performed by a targetdevice of the invention. Fig. 4 illustrates an embodiment according to a method performed by a networknode of the invention. Fig. 5 illustrates an embodiment of a mapping between semantic models at asource device and a target device of the invention. Fig. 6a illustrates an embodiment of a signaling diagram between a sourcedevice and a target device of the invention. Fig. 6b illustrates an embodiment of a signaling diagram a source device, atarget device and a network node of the invention.Fig. 7 illustrates an embodiment of a communication network node of theinvention. Fig. 8 illustrates an embodiment of a wireless device of the invention.Fig. 9 illustrates an embodiment of a computer program product of theinvention. All the figures are schematic, not necessarily to scale, and generally only show parts which are necessary in order to elucidate the invention, wherein other parts may be omitted or merely suggested. DETAILED DESCRIPTION The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not beconstrued as limited to the embodiments set forth herein. Rather, these embodimentsare provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description. The disclosure herein enables communication between applications hosted on different devices, wherein the devices may belong to the same device ecosystem (e.g. a first constrained application protocol (CoAP) device and a second CoAP device) butdevices may or may not share the same semantic model for their respectiveapplications. Also, the disclosure herein enables communication between applications hosted on different devices, wherein the devices belong to different device ecosystems (e.g. a first constrained application protocol (CoAP) device and a second Zigbee device),wherein the different devices may or may not share the same semantic model for theirrespective applications. Furthermore, the disclosure herein enables communicationbetween applications hosted on the same device, but wherein the applications do not share the same semantic model (e.g. a first HyperText Transfer Protocol (HTTP)message, a second Simple Network Management Protocol message).In other words, the disclosure herein enables communication between a firstdevice and a second device, wherein a first application in the first device and a secondapplication in the second device do not share the same semantics (e.g. have differentsemantic models or have a different syntax). The disclosure herein uses a navigablesemantic description of functions to provide the necessary information that is requiredby an application hosted in a source device to map external services (e.g., a platformservice), one or more inputs (i.e., parameters) of the external services and one or moreoutputs of the external services, to an application logic using semantically defined objects that can be matched to remote calls in an application hosted in a target device. The match of the remote call may be established dynamically and reconfigured tomatch the target device or an external service that provides what is needed by therequesting application hosted in the source device. To provide semantic translation, anintermediary or mediation entity may optionally be used if the source device is notcapable of performing semantic translation or if the source device is not capable offacilitating the semantic matching without errors. This disclosure provides a sourcedevice to discover the Application Programming Interface (API) or a service hosted at atarget device and optionally, consequently use the API (or make a function call to theAPI) hosted in the target device directly without human intervention.The disclosure herein provides a method for communication between a first APIhosted at a source device and a second API hosted at a target device. The first API andthe second API have different semantic models. The method is performed by the sourcedevice, and the method comprises obtaining, using a Semantic Definition Format (SDF)mapping extension, an indication of a semantic model of the second API. The SDFmapping extension comprises a first SDF quality comprising an API call definition,wherein the API call definition comprises a first key relating to the second API. The SDF mapping extension comprises a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semanticmodel of the second API. The method further comprises transmitting, to the targetdevice, a first message. A syntax of the first message is based on the obtainedindication of the semantic model of the second API. The disclosure herein advantageously uses a newly defined SDF mappingextension for facilitating the translation between devices belonging to either differentecosystems or between applications hosted in devices with different semantics. Thedisclosure herein advantageously provides devices with a vocabulary and / or a specificstructure (i.e., a syntax) to discover an API. The disclosure herein furtheradvantageously provides devices with a vocabulary and / or a specific structure (i.e., asyntax) to deploy services in another device. The advantages herein are enabled byextensions to the SDF syntax by enhancing description of an API call definition (i.e., aUniform Resource Location (URL), Uniform Resource Identifier(URI)) by, for example,including how an API call definition should be handled or how an API call definition should be deployed. The disclosure herein enables a discovery mechanism wherein a source devicecommunicates with a target device to query and / or operate the target device’scapabilities without human intervention or without need for translating (or in somecases rewriting) an application layer of the source device. This discovery mechanism isenabled by using semantic models (and in particular a semantic descriptor forfunctions) and an extended SDF format. The SDF extensions enable applications toconstruct API calls for the source device, wherein the API calls that map to applicationlogic and functions of the target device by utilizing new SDF qualities and optionally, new URI templates. Fig. 1 illustrates an embodiment of a communication network 100 according tothe invention. The communication network 100 comprises a source device 110, a targetdevice 120 and a network node 130. In an example, the source device 110 may becapable of communicating with the target device 120 and / or the source device 110may be capable of communicating with the network node 130. The network node 130 may be placed inside the communication network 100 or the network node 130 may be placed outside of the communication network 100. Examples of the source device 110,the target device 120 and / or the network node 130 have been provided in relation tothe description corresponding to Figs.7 and 8. The disclosure therein provides a means to define a capability of a device (e.g., asource device 110, a target device 120) using one or more semantic models, one ormore semantic ontologies and / or one or more semantic vocabularies. The semanticmodels, the semantic ontologies and / or the semantic vocabularies may enable onedevice to interpret which domain, entities, operations / functions, and operational statesmanaged by another device without the two devices having the same programming. The network node 130 (i.e., an example of a mediator between the source device110 and the target device) may provide translation of capability information betweendifferent types of devices and / or different type of APIs hosted by the same deviceand / or different type of APIs hosted by different devices. The capability information for the source device 110 and the target device 120 may be provided using semantic ontologies from a different domain and / or ecosystem. The network node 130 may provide a means of transmitting and / or receiving vocabulary (e.g. domain specific vocabulary and / or an ecosystem specific vocabulary) from a source device 110 to the target device 120. Once an indication of the semantic models (i.e., which semantic model is used bya device / which semantic model is used by an API) is exchanged between the sourcedevice 110 (i.e., a capability requesting device) and the target device 120 (i.e., acapability provisioning device), a first API hosted at the source device 110 may providean input to a second API hosted at the target device 120. This transmitting of the inputwith the same semantics, from the source device 110 to the target device 120, may beused to query and / or utilize one or more capabilities of the target device 120. An example of a source device 110 querying and / or utilizing one or morecapabilities of a target device 120 is provided herein. In the example, a dashboard (i.e.,the source device 110) of a connected vehicle is provided, wherein the dashboard hostsa first API. The first API is configured to warn a user of the connected vehicle aboutdanger on a route. The first API may feature an algorithm that detects certain type oftraffic signs, such as dangerous curve, a crossroad ahead and an incoming traffic signal. Whenever one of the configured traffic signs is detected, the connected vehicle requestsone or more cameras (i.e., the target device 120), i) at a given intersection nearby orwhere the connected vehicle is approaching, or ii) from other connected vehicles whichare already at the intersection, to provide a feed of images and / or location coordinates.The feed of the images and / or location coordinates are used by the first API hosted atthe dashboard to warn the user in case of dangerous situations or to pay specialattention to an event (e.g. a car accident, multiple pedestrians, bicycles on the way,heavy traffic). The request is sent from the first API hosted at the dashboard (i.e., thesource device 110) to a second API hosted by the one or more cameras placed at another location (i.e., the target device 120) such as a camera placed at a trafficintersection camera, or a camera placed on another connected vehicle. The semantics ofthe query (i.e., the request for the one or more cameras) for the first API and the secondAPI are different, but embodiments of the disclosure herein advantageously enable atranslation of the query in a format interpretable by the second API. Fig. 2 illustrates an embodiment according to a method performed by a sourcedevice 110 of the invention. The method 200 is performed by the source device 110, infor example, the communication network 100 as described in relation to the description corresponding to Fig.1. The method 200 is for communication between a first API hosted at the sourcedevice 110 and a second API hosted at a target device 120. The first API and thesecond API have different semantic models. For example, the first API may take a stringas an input, i.e., the first API may take a series of characters as an input, and the second API may take a ‘float’ as an input, i.e., the second API may take a number with decimal point values as input. The method 200 comprises obtaining 202, using an SDF mapping extension, anindication of a semantic model of the second API. The SDF mapping extensioncomprises a first SDF quality comprising an API call definition, wherein the API calldefinition comprises a first key relating to the second API. The SDF mapping extension comprises a second SDF quality comprising a first value corresponding to the first key,wherein the first value is the indication of the semantic model of the second API. Insome embodiments, the SDF mapping extension is based on Internet Engineering TaskForce (IETF) Request for Comments (RFC) 6570. Examples of the first SDF quality are:i) a Uniform Resource Indicator (URI), ii) a Uniform Resource Locator (URL), and iii) ageneric function call. Examples of the second SDF quality are: i) a semantic modelindicating that an API uses CoAP semantics, ii) a semantic model indicating that an API uses LwM2M semantics, and iii) a semantic model indicating that an API usesHyperText Transfer Protocol (HTTP) semantics. Examples of representation of theindication of the semantic models may be a numeric value (e.g. if API uses HTTPsemantics, indication = “1”, if API uses CoAP semantics, indication = “2”, if API usesLwM2M semantics, indication = “3” or any other combination), an alphanumeric value(e.g. if API uses HTTP semantics, indication = “1a”, if API uses CoAP semantics, indication = “2b”, if API uses LwM2M semantics, indication = “3c” or any othercombination) and a binary value (e.g. if API uses HTTP semantics, indication = “001”, ifAPI uses CoAP semantics, indication = “010”, if API uses LwM2M semantics, indication = “011” or any other combination). The method 200 comprises transmitting 204, to the target device 120, a firstmessage. A syntax of the first message is based on the obtained indication of thesemantic model of the second API. The syntax refers to semantics, representationand / or semantic model. Optionally, the indication of the semantic model comprises a semantic descriptorfor the second API. Optionally, the indication of the semantic model comprises at leastone of: i) an available command for the target device 120 (e.g. a request for a camerafeed; a request for an audio feed; a request for a multimedia feed), ii) a function callsignature supported by the target device 120 (e.g. a local function / procedure call in aprogramming language supported by the target device 120; a remote function / procedure call supported by the target device 120; wherein the local function calland / or remote function call may not be related to a protocol interaction as such), iii) avocabulary that is interpretable by the target device 120 (e.g. a set of input and / oroutput parameters which the target device 120 is configured to interpret), iv) asemantic model used by the target device 120 (e.g. an input / output ‘type’ used by thetarget device 120; input = ‘string’, output = ‘Boolean’), v) an operator provided and / orrequired by the second API (e.g. an input must be provided to the second API byproviding the input followed by the enter key; another input must be provided to the second API by providing the input followed by the shift + enter key), vi) a parameterprovided and / or required by the second API (e.g. ‘video quality’; ‘audio quality’; ‘URL’),vii) a syntax for an input for the target device 120 (e.g. an input may be provided to thesecond API by providing the input followed by another input may be provided tothe second API by providing the input followed by the “$”), and / or viii) a syntax for anoutput for the target device 120 (e.g. an output may be provided by the second API byproviding the output followed by a “+” representation; an output may be provided by the second API by providing the output followed by a “ / / ” representation). Optionally, the method 200 comprises translating 206 a syntax of the first message based on the obtained indication of the semantic model of the second API. The translation is performed in order to make the first message interpretable by thetarget device 120. The translation at the source device 110 may reduce computationalcomplexity for the target device 120. In some embodiments, the API call definition is a Uniform Resource Identifier(URI). In some embodiments, a Uniform Resource Locator (URL) is obtained from theURI. In an example, the URI may be resolved (using, for example, DNS resolution) toprovide the URL by the source device 110 and / or a network node 130. In someembodiments, the API call definition is a URL and the SDF mapping extensioncomprises a third SDF quality indicating a method to transmit a request to the URLcomprised in the first SDF quality. In some embodiments, the API call definition is a command or a function call. For example, the command may be from the source device 110 to the target device 120. Optionally, the SDF mapping extension provides a semantic mapping which isallowable (i.e., providable, configurable) by the source device 110. The source device110 may or may not comprise the SDF mapping extension.Optionally, the method comprises storing 208 the obtained indication of a semantic model of the second API. In some embodiments, obtaining 202 the indication of the semantic modelcomprises retrieving the indication of the semantic model of the second API. In anexample, the indication of the semantic model of the second API may be retrieved by performing a URI call towards the first SDF quality. In some embodiments, obtaining 202 the indication of the semantic modelcomprises i) transmitting, to the network node 130, a request to provide the indicationof the semantic model of the second API and ii) in response to the request, receiving,from the network node 130, the indication of the semantic model of the second API. In some embodiments, obtaining 202 the indication of the semantic modelcomprises i) transmitting, to the target device 120, a request for providing the semanticmodel of the target device 120 (including, for example, the semantic model used by the second API). The request optionally comprises a request for providing the information related to the target device’s 120 capability. The request optionally comprises a request for providing the information related to the second API’s functionality. In some embodiments, wherein the API call definition is a URL, the method 200optionally comprises transmitting 210, to the network node 130, the request on the URLcomprised in the first SDF quality. The method 200 optionally comprises receiving 212,from the network node 130, the second SDF quality comprising the first value. Optionally, the method 200 comprises transmitting 214, to the network node 130, an indication of a semantic model of the first API. Optionally, the method 200 comprises transmitting 216, to the network node 130, an indication of a semantic model of a thirdAPI, wherein the indication of the semantic model of the third API is stored on thesource device 110 and / or obtained by the source device 110 (from, for example, thenetwork node 130 or another network node). In some embodiments, the source device 110 and the target device 120 belong to the same ecosystem. For example, the source device 110 belongs to a CoAP-based ecosystem and the target device 120 belongs to a CoAP-based ecosystem. In some embodiments, the source device 110 and the target device 120 each belong to a different ecosystem. For example, the source device 110 belongs to a CoAP-based ecosystem and the target device 120 belongs to an HTTP-based ecosystem.In an example (as defined in relation to Fig. 5), the first SDF quality is “template-href”, wherein the first SDF quality is added to an SDF affordance (e.g. action, event, or property) definition block. In the example, the first SDF quality is used to provide a Uniform Resource Locator (URL) and a request using a protocol (e.g., HTTP, Constrained Application Protocol (CoAP)) is sent to interact with the SDF affordance. The first SDF quality provides a URL template with an Internet Engineering Task Force (IETF) Request For Comments (RFC) 6570 syntax, wherein variables are introduced in a URL within the curly braces (“{” and “}”). The variables in the URL template (e.g., “videoQuality”, “destinationAddress”) refer to the variables introduced in a second SDF quality referred to as “template-values”. In some embodiments, the source device 110 maps 218 parameters of the firstAPI with the second API such that a remote API call may be made from the first API to the second API. The mapping of the parameters may enable a quicker translation between the semantic models of the first API and the second API. Once the mapping of parameters is performed between the first API and thesecond API, the mapping may be stored in the source device 110. The mapping may beused for any future requests from the first API to the second API without the need for a request for information about the semantic models from the source device 110 to the target device 120. If a capability of the target device 120, a functionality of the secondAPI and / or a semantic model of the second API changes, then the source device 110may receive 220 an update from the target device 120 about the changes (e.g. bysending a message to the source device 110 regarding the changes). Figs. 3 illustrates an embodiment according to a method 300 performed by atarget device 120 of the invention. The method 300 is performed by the target device120 in, for example, the communication network 100 as described in relation to thedescription corresponding to Fig. 1. The method 300 is for communication between afirst API hosted at a source device 110 and a second API hosted at the target device120. The first API and the second API have different semantic models.The method 300 comprises receiving 302, from the source device 120, a firstmessage. A syntax of the first message is based on an obtained indication of thesemantic model of the second API, wherein the indication of the semantic model of thesecond API is obtained using an SDF mapping extension. The SDF mapping extensioncomprises: i) a first SDF quality comprising an API call definition, wherein the API calldefinition comprises a first key relating to the second API, and ii) a second SDF qualitycomprising a first value corresponding to the first key, wherein the first value is theindication of the semantic model of the second API. In some embodiments, theindication of the semantic model comprises a semantic descriptor for the second API. Insome embodiments, the SDF mapping extension is based on IETF RFC 6570. In someembodiments, the source device 110 and the target device 120 each belong to a different ecosystem. In some embodiments, the indication of the semantic model comprises at least one of: i) an available command for the target device 120, ii) a function call signature supported by the target device 120, iii) a vocabulary that is interpretable by the target device 120, iv) a semantic model used by the target device 120, v) an operator provided and / or required by the second API, vi) a parameter provided and / or required by thesecond API, vii) a syntax for an input for the target device 120, and / or viii) a syntax foran output for the target device 120. In some embodiments, the API call definition is a URI. In some embodiments, aURL is obtained from the URI. The URL may be obtained using, for example, DomainName Server (DNS) resolution of the URI. In some embodiments, the method 300 comprises receiving 304, from the source device 110, a request to provide the indication of the semantic model of the second API. In some embodiments, the method 300 may comprise transmitting 306, to the sourcedevice 110, the indication of the semantic model of the second API. The transmitting306 may be performed in response to the receiving 304. In some embodiments, the method 300 comprises receiving 308, from a network node 130, a request to provide the indication of the semantic model of the second API. The method 300 may further comprise transmitting 310, to the network node 130, theindication of a semantic model of the second API. The transmitting 310 may beperformed in response to the receiving 308. In some embodiments, the method 300 comprises transmitting 312, to thenetwork node 130, an indication of a semantic model of a third API. The indication ofthe semantic model of the third API may be stored on the target device 120 and / or the indication of the semantic model of the third API may be obtained by the target device120. In an example, the third API may be another related API to the first API or thesecond API. In another example, the third API may be another unrelated API to the first API or the second API. In some embodiments, wherein the API call definition is a URL, the SDF mappingextension comprises: a third SDF quality indicating a method to transmit a request tothe URL comprised in the first SDF quality. For example, the method may provide instructions on how to transmit a request to the URL in the first SDF quality byproviding the accepted parameters (input functions and / or input variables).In some embodiments, the target device 120 stores 314 information about asecond API hosted at the target device 120, wherein the information comprises i) an indication of a semantic model being used by the second API (e.g. type of input data accepted, type of output data to be expected), ii) optionally, an indication of functionality of the second API and iii) optionally, information related to the target device’s 120 capability (e.g. an ecosystem that the target device 120 belongs to). The information may be stored in SDF format using the SDF mapping extensions provided in the disclosure herein. The target device 120 may query 316 the second API for obtaining the information about the second API, prior to storing the information about the second API. In some embodiments, the target device 120 maps 318 parameters of the firstAPI with the second API. The target device 120 may further provide 320 the mappinginformation to the source device 110 and / or the network node 130 (i.e., which parameters correspond to each other in the first API and the second API) such that a remote API call may be made from the first API to the second API. Once the mapping of parameters is performed between the first API and the second API, the mapping may be stored in the source device 110. The mapping may be used for any future requests from the first API to the second API without the need for a request for information about the semantic models from the source device 110 to the target device 120. If a i) capability of the target device 120, ii) a functionality of the second API and / or iii) a semantic model of the second API changes, then the targetdevice 120 may provide 322 an update to the source device 110 and / or the networknode 130 about the changes (e.g. by sending a message to the source device 110regarding the changes). Figs. 4 illustrates an embodiment according to a method 400 performed by anetwork node 130 of the invention. The method 400 is performed by the network node130 in, for example, the communication network 100 as described in relation to thedescription corresponding to Fig. 1. The method 400 is provided for communicationbetween a first API hosted at a source device 110 and a second API hosted at the target device 120. The first API and the second API have different semantic models. The method 400 comprises obtaining 402, using an SDF mapping extension, an indication of a semantic model of the second API. The SDF mapping extension comprises i) a first SDF quality comprising an API call definition, wherein the API calldefinition comprises a first key relating to the second API, and ii) a second SDF qualitycomprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model. In some embodiments, the API call definition is a URI.In some embodiments, a URL is obtained from the URI. In some embodiments, thesource device 110 and the target device 120 each belong to a different ecosystem. The method 400 comprises receiving 404 on the API call definition, from the source device 110, a request to provide an indication of a semantic model of the second API. The method 400 comprises transmitting 406, to the source device 110, the obtained indication of the semantic model of the second API. The method 400 optionally comprises obtaining 408 a first capability registration information comprising an indication of a semantic model used by: i) thesource device 110 and / or ii) the first API. In some embodiments, obtaining the firstcapability registration information comprises receiving, from the source device 110, thefirst capability registration information. In some embodiments, obtaining the firstcapability registration information comprises i) observing at least one protocol of thesource device 110, and ii) inferring the semantic model of the first API based on theobservation. The method 400 optionally comprises obtaining 410 a second capability registration information comprising an indication of a semantic model used by: i) thetarget device 120 and / or ii) the second API. In some embodiments, obtaining thesecond capability registration information comprises receiving, from the target device120, the second capability registration information. In some embodiments, obtainingthe second capability registration information comprises i) observing at least one protocol of the target device, and ii) inferring the semantic model of the second API based on the observation. The method 400 optionally comprises receiving 412, from the source device 110,a first message. A syntax of the first message is based on a semantic model of the firstAPI. The method 400 optionally comprises translating 414 the first message into asyntax based on the obtained indication of the semantic model of the second API. The method 400 optionally comprises transmitting 416, to the target device 120, the translated first message. In some embodiments, the indication of the semantic model comprises at leastone of: i) an available command for the target device, ii) a function call signaturesupported by the target device, iii) a vocabulary that is interpretable by the target device, iv) a semantic model used by the target device, v) an operator provided and / or required by the second API, vi) a parameter provided and / or required by the second API, vii) a syntax for an input for the target device; and / or viii) a syntax for an output for the target device. The method 400 optionally comprises receiving 418, from the source device 110, an indication of a semantic model of the first API. The method 400 optionally comprises receiving 420, from the source device 110,an indication of a semantic model of a third API. The indication of the semantic modelof the third API is stored on the source device 110 and / or the indication of the semantic model of the third API is obtained by the source device 110. In some embodiments, wherein the API call definition is a URL, the SDF mapping extension comprises a third SDF quality indicating a method to transmit a request tothe URL comprised in the first SDF quality. In some embodiments, the source device110 may receive, from the network node 130, the URL wherein the a resource providedat URL comprises one or more of: i) a list of available command(s) / function(s) / callsthat the source device 120 may provide as options or the target device 120 may acceptas input, ii) operator(s) required by the second API and iii) parameter(s) required by thesecond API. In some embodiments, the network node 130 may be utilized for communicationbetween the source device 110 and the target device 120. In such embodiments, thenetwork node 130 is optionally configured to translate a message or query from the source device 110 into a supported semantic model for the target device 120 or the second API. In some embodiments, a type of ecosystem (e.g. CoAP, LwM2M, Open PlatformCommunications - Unified Architecture (OPC-UA)) for the target device 120 is inferredfrom the type of protocols used by the target device 120 and from the interaction of the target device 120 with the network node 130. In some embodiments, the target device 120 explicitly provides information tothe network node 130 about the supported ecosystem semantic models and / or specificvocabulary that the target device 120 supports. The information to the network node130 may be provided: i) through a form (e.g. a form which gathers input from the targetdevice 120 about the ecosystem and semantic model information), ii) by providing aURL to a semantic model including references and / or iii) by transmitting theinformation using an SDF format. In some embodiments, the directory (e.g. a URL, a URI) for a request for available commands is a reserved URL which is negotiated to be used as a standardcommand between the source device 110, the target device 120 and / or the networknode 130. For example, the resource “.well-known / commands” (from IETF RFC 8615)may be used as one way to request such list of commands from a certain device (e.g.the source device 110, the target device 120, the network node 130). The response tothe request for the list of commands may include a list of supported API calls and a typeof the supported API calls. The supported API calls may be called in a hierarchical wayfrom a root domain that is provided by the certain device (e.g. the source device 110,the target device 120, the network node 130). Further interaction capabilities may be included either in an initial response as shown above in the "sdfAction" block or may be discovered using further requests. For example, the descriptions of the two actions (i.e., the sdfAction blocks) detailed aboveprovide information on whether the actions require an input, what are the details ofsuch input and / or output, and if there is additional information related to the type of theinput and / or output. Also, the description field may be tailor made to provide a URI to avocabulary that is interpretable by the source device 110. In this way the source device110 may infer of the possible options, parameters, and the actions that the function / command provides and / or requires. The SDF also allows to customization of a format with semantic descriptors thatare specific to the semantic model (e.g. semantics) that an API performing discovery ofanother API may interpret – this way, there is no need for an API in a certain device toutilize tools (e.g. Resource Description Framework (RDF) parser), to process thedescription of the semantic model(s) of the another API.The use of SDF enables provision of the description and a semantic model (e.g.data model) for a specific device ecosystem (e.g. an IETF-based ecosystem, IEEE-basedecosystem, a 3GPP-based ecosystem, an LwM2M ecosystem, a Bluetooth ecosystem, aZ-wave ecosystem). Furthermore, the usage of SDF for semantic models reduces thecomplexity for a certain device to perform semantic matching from one semantic modelto another. In some examples, the usage of SDF enables a first API at the source device110 to request a second API (hosted at the target device 120) by providing an SDFdescription that matches the type of data model that such the second API is capable ofinterpreting. In some embodiments, the network node 130 may act as an intermediaryto provide details of the semantic model that the second API is able to interpret – facilitating the semantic matching process. The network node 130 may be configured to infer / deduce a type of ecosystem for the certain device (e.g. the source device 110, the target device 120) by observingthe interactions of the certain device and / or by observing the protocols utilized by thecertain device. Fig. 5 illustrates an embodiment of a mapping between semantic models at asource device 110 and a target device 120. The mapping may be performed with orwithout a network node 130 acting as an intermediary node (i.e., the network node 130is optional). The block diagram illustrates the source device 110, which is a connected traffic intersection analysis module, and the target device 120, which is a connected camera. The figure further illustrates attributes and methods with equivalences between the source device’s 110 ‘input-video-stream’ block and the target device’s 120 ‘camera- feed’ block. The equivalence of the semantic models is depicted by a semantic translation system or a semantic translation API which may be hosted at the source device 110, the target device 120 and / or the network node 130. The equivalence of the semantic models illustrates that the following attributesare equivalent: i) Resolution (exif:resolution) of the source device 110 and videoQuality(dbpedia-owl:resolution) of the target device 120, ii) Sampling (ebucore:sampleRate) ofthe source device 110 and Sampling (ids:samplingRate) of the target device 120, iii)Input-address (sioc:ip_address) of the source device 110 and destinationAddress(xhv:link) of the target device 120, iv) Identifier (am:identifier) of the source device 110and StreamId (am:identifier) of the target device 120. The equivalence of the semanticmodels illustrates that the following methods are equivalent: i) playStream(sdm:playStream) of the source device 110 and StartStreaming (saref:StartCommand)of the target device 120, ii) stopStream (sdm:stopStream) of the source device 110 andStopStreaming (saref:StopCommand) of the target device 120. The figure alsoillustrates an example of a non-equivalence (i.e., no equivalent attribute or method found between the source device 110 and the target device 120). The non-equivalencerelates to the method “pauseStream (sdm:pauseStream)” of the source device 110.In a first example, a request from a connected vehicle, which is a source device110, to a traffic light camera, which is the target device 120, of an intersection may beas follows (in italics): GET http: / / traffic-light.traffic-center.ericsson / .well-known / commands For this example, the response includes a description of the supported API callswith a semantic definition attached (i.e., a description or definition of the semanticmodels used by the supported API calls). Using SDF, the description may be as follows(in italics), wherein the ‘namespace’ block provides information about resources and the ‘namespace’ block also provides a vocabulary for the resources defined in the namespace. The resources (or items) defined under the ‘namespace’ block belong to an ontology (e.g. ‘dbo’, ‘iss’, ‘am’): "namespace": { "dbo ": "http: / / dbpedia.org / ontology / #", "iss": "https: / / ont.example.com / intelligence-services / #", "am": "http: / / open-services.net / ns / asset#", "saref": "https: / / saref.etsi.org / core / ", "xhv": "http: / / www.w3.org / 1999 / xhtml / vocab#", "owl": "http: / / www.w3.org / 2002 / 07 / owl#", "rdf": "http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns", "demo": "https: / / example.com / iss-demo-setup / #" }, "defaultNamespace": "demo", "sdfObject": { "video": { "sdfProperty": { "camera-feed": { "description": "MP4 video feed from the camera", "sdfRelation": { "FeedType": { "relType": "rdf:type", "target": [ stream", "sdfRelation": { "FeedType": { "relType": "rdf:type", "target": [ "am:identifier", "iss:data-object" ] } }, "type": "string", "contentFormat": "application / vnd.iss-stream-info- id" From the above ‘namespace’ block, the definition of the SDF property “camera- feed” specifies that as result of a request for a video feed from a traffic light, theresponse in mp4 content format (i.e., "video / mp4") can be expected. Therefore, aconnected vehicle car may request for a functional call to the SDF property ”camera-feed“ at the a URL “http: / / traffic-light.traffic-center.ericsson / ” and receive an mp4stream in response from the traffic light. In the first example, the certain device (e.g. the source device 110, the targetdevice 120) may explicitly inform the network node 130 in an API call about theecosystem that the certain device belongs to. In some cases, the certain device may provide the type of semantics that the certain device is configured to interpret. Thisinformation about the ecosystem and the semantics may be provided using SDF in aformat as follows (in italics): "namespace": { "sdm": "https: / / sdm.wide.ad.jp / sdmo / # / ", "iss": "https: / / ont.example.com / intelligence-services / #", "exif": "http: / / www.w3.org / 2003 / 12 / exif / ns#", "sioc": "http: / / rdfs.org / sioc / ns#", "am": "http: / / open-services.net / ns / asset#", "rdf": "http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns", "app": "http: / / owner.mycar,fi / " }, "defaultNamespace": "app", "sdfObject": { "Camera": { stream", given id", "sdfRelation": { "FeedType": { "relType": "rdf:type", Once the available function calls and / or input parameters required by thesecond API have been obtained by the source device 110, the source device 110 may perform function calls via the first API hosted at the source device 110 to the secondAPI. From the example above, the first API may request the video stream from thetraffic light by mapping the function block “startStreaming”. The mapping is done bytranslation of the function block using the network node 130 or by the source deviceutilizing equivalent services that provide mapping of a function call with semantics.In some embodiments, the mapping semantics of the second API at the target device 120 may be communicated to the first API of the source device 110 using an SDFmapping extension. In the SDF mapping extension, the actions and / or semantic models(e.g. semantic data, data models) are expressed using the semantics that areinterpretable by the source device 110. In the SDF mapping extension, the actionsand / or semantic models (e.g. semantic data, data models) are expressed using thesemantics that allow the source device 110 to produce an API call for the second API byprovide the required semantic data to the source device 110. With respect to aboveexample of the video camera-feed, the API call by the first API utilizes a request to aURL following a pattern. The SDF mapping extension may be a combination of: i) the definition of patterns specified in IETF RFC 6570 to define the API structure and ii) a mapping of specific values to what the second API can interpret / process. In the example, the resolution required for the second API accepts two values, 1 for low-resolution and 2 for high-resolution. This is described in the SDF mapping schema and thus, the source device 110 may map the resolution required to an APIsemantic definition of low resolution or high resolution. In this manner, the first APIapplication utilizes the right input based on the resolution required by the first API. The SDF mapping schema specifies the semantics of the second API. In some embodiments, the source device 110 maps an action that the second API has defined and the second API hosted by the target device 120 can interpret such that relations to a vocabulary known or used by the source device 110 is improved. Furthermore, a first SDF quality is introduced in the SDF mapping scheme which can express a URL template pattern in terms of a format as defined in IETF RFC 6570. A second SDF quality, ‘template-ref’ is introduced as well which corresponds to the value stored in the first SDF quality. In the example herein, the first SDF quality "template-href", includes the URL or the URLpattern which can enable a match for a command known by the first API hosted at thesource device 110. As explained in IETF RFC 6570, the URL pattern may have variableterms (in the SDF mapping scheme below, in bold). The URL pattern is given an SDFdefinition (i.e., the first SDF quality represented by “template-href”) and an SDF relation(i.e., a corresponding second SDF quality, represented by “template-values”) such that the source device 110 can interpret how to map information present in the sourcedevice 110 to what the second API hosted at the target device 120 requires. "app:# / sdfObject / video / sdfAction / playStream / sdfInputData / Resolution" , "dev:# / sdfObject / camera / sdfAction / startStreaming / sdfInputData / videoQ uality" ] } }, "map": { "# / sdfObject / video / sdfAction / playStream": { "cmd:template-href": "http: / / traffic-light.traffic- center.ericsson / camera- feed / startStreaming?videoQuality={videoQuality}&destinationAddress={ destinationAddress}", "sdfRelation": { The SDF mapping schema specifies that the input parameter should be the video quality and the destination address of the video stream. These two parameters areknown by the second API, and can thus be function called (or queried) from thefirst API.Thefirst API then queries the second API by using the equivalent to the two parameters. For example, “http: / / traffic-light.traffic-center.ericsson / camera- feed / startStreaming?videoQuality=1&destinationAddress=http: / / owner.m ycar.ericsson / receiveStream / “ In some embodiments, the network node 130 may map the semantic model from the second API application to the semantic model that the source device 110 is capableof interpreting – making the translation of the message or a query from thefirst API tothe second API clear and compatible. This translation may be done by the SDF mapping schema which provides the information necessary for an API at the network node 130 toapply its own semantics to the message or the query provided by the source device 110.In some embodiments, thefirst API performs API calls based on a semantic model of thefirst API which has been registered at the network node 130. In such embodiments, the network node 130 is configured to translate (on behalf of thefirst API) and construct an API call towards the second API. The API call by the network node 130 (which is the API call on behalf of thefirst API) may be made directly to the second API or the API call translation may be transmitted back to thefirst API so that thefirst API may query the second API itself. In the case wherein the network node 130 constructs and interacts with the second API, the network node 130 is configured to communicate with the source device 110 hosting thefirst API as a proxy and any response from the second API is redirected to thefirst API. Asecond example of a source device 110 is a connected camera (i.e., a camerawhich is capable of communicating with a communication network) that utilizes Open Mobile Alliance’s (OMA) Lightweight Machine-to-Machine (LwM2M) protocols and semantic model. In some embodiments, a description of the source device’s 110 capabilities and semantic model(s) may be specified using SDF mapping schema. In the example, the source device 110 (e.g. the camera) utilizes a semantic model which is registered with object ID 10340. The registered semantic model has specified actions and properties as follows (in italics): , "# / sdfObject / Camera / sdfAction / Image_Matting_Control", "# / sdfObject / Camera / sdfAction / Camera_Snapshot_Control" , "# / sdfObject / Camera / sdfAction / Camera_Recording_Control " ] } An example of an API call for the connected camera with the above described SDF mapping schema may be as follows (in italics): POST http: / / traffic-light.traffic-center.ericsson / 10340 / 0 / 101 / In the above-described API call, the directory “ / 10340” is the LwM2M object idfor the connected camera (i.e., the source device 120 or the target device 120), “ / 0” isthe instance of the LwM2M object and “ / 101” is the function that enables or disables recording for the connected camera. The first API and the second API are both hosted inthe connected camera (i.e., the source device 120 or the target device 120). In thisexample, the payload of a query towards the connected camera required a "1" to enable the camera recording and "0" to disable camera recording (e.g. both the enable and disable queries / requests may be sent using a POST command). In order to provide information about the API (i.e., POST http: / / traffic-light.traffic- center.ericsson / 10340 / 0 / 101 / ; wherein this API is the second API) to a first API, a new mapping schema is required with semantics that the second API may interpret. Thus, a third SDF quality “method” is introduced to clarify the semantics that the first API call requires as payload in a query / request towards the first API. The third SDF qualitycommand enables the connected camera (i.e., the source device 120 or the targetdevice 120) to interpret how to handle an API call. In some embodiments, a URL for theAPI may possess all the information required in the API call itself (e.g. the first examplewith the connected vehicle and the connected traffic light), but in some embodiments, what is needed to be done with the API call is needed to be specified, with a semantic model that the source device 110 (or the target device 120) may interpret. The third SDF quality "method" is provided to describe how to handle the API call and what to expect of the API call (e.g. a payload type of the API call). In some other embodiments, the third SDF quality “method” may be an ‘OBSERVE’ command in LwM2M or another type of new command which has not yet been specified (e.g. XR APIs in LwM2M). An example of an SDF mapping schema for the second API of the source device110 to utilize the connected camera may be as follows (in bold):"info": {"title": "LwM2M Camera Device to Requester dev.Application API mapping"}, "namespace": { "sdm:stopStream", "iss:atomic-service" }, "# / sdfObject / Camera / sdfProperty / Input-video-stream":{ "cmd:template-href": "http: / / traffic-light.traffic-center.ericsson / 10340 / 0 / 9", "sdfRelation": {"FeedType": {"relType": "rdf:type","target": ["dev:# / sdfObject / Camera / sdfProperty / Recording_Lo cation", "sdm:VideoMedia", "iss:stream" ] } In the example above, the same API call is used for starting and stopping the camera streaming, wherein the difference in functionality lies in the payload of the query / request towards the API. The SDF mapping schema specifies the same API call to a URL with different payload contents using the POST method. The destination address for the API call is set to afixed address that is provided by the "Recording_Location" block in the URL, which is specified to map to the "Input-video-stream" property. The third SDF quality enables afirst API to applications to interpret a second API of the device and / or service and then supports in constructing the right API call without the for hardcoding the API call description at setup / during manufacture. The SDF extensions introduced and used in thefirst example and the secondexample have the following structure and semantics: afirst SDF quality “template-href”is added to an SDF affordance (action, event, or property) definition block and used toprovide a URL where a protocol (e.g., HTTP) request can be made to interact with the SDF affordance. Thefirst SDF quality provides a URL template with the IETF RFC 6570syntax, wherein variables are introduced in URLs within curly braces (“{” and “}”). Thevariables in the URL templates based on IETF RFC 6570 (e.g., “videoQuality” and “destinationAddress” in thefirst example) refer to variables introduced in a second SDF quality “template-values”. For example (as in thefirst example): "cmd:template-href":"http: / / traffic-light.traffic-center.ericsson / camera-feed / startStreaming?videoQuality={videoQuality}& destinationAddress={destinationAddress}" The “template-values” quality is used in the same definition block with the“template-href” quality and provides: i) a map with map keys as variable names and ii)values as references to SDF definitions using the SDF JSON pointer syntax. For example (as in thefirst example):"cmd:template-values": {"videoQuality": "# / sdfData / Resolution","inputAddress": "# / sdfObject / video / sdfAction / playStream / sdfInputData / destinationAddress" } When more details are required than the URL to interact with the SDF affordance,additional qualities may be used to provide those details. For example, to indicate thatHTTP POST method should be used with a given URL, a third SDF quality “method” may be used to indicate this together with the other two SDF qualities (i.e., thefirst SDF quality and the second SDF quality) described above. For example (as in second example):"cmd:template-href": "http: / / traffic-light.traffic-center.ericsson / 10340 / 0 / 101", "cmd:method":"POST",In some embodiments, the SDF mapping extensions uses a new SDF quality nameprefix “cmd” (or another similar prefix) that may be registered in the SDF InternetAssigned Numbers Authority (IANA) registry. Alternatively, the SDF mapping extensionsmay become a part of the IETF SDF core vocabulary and hence may be used without the prefix. In the examples discussed, the semantic models of the second API provide adefinition of an expected output for an API call of the different functions / commandsavailable at the second API hosted at the target device 120. In some embodiments, theobtained output from the second API of the target device 120 is mapped to an applicationlogic of thefirst API. In the examples discussed, the video stream from the target device120 may be used by an object algorithm and / or a context recognition algorithm hostedat the source device 110. The object algorithm and / or the context recognition algorithm may be programmed to recognize a situation which needs attention of a user of thesource device (e.g. a driver of the connected vehicle). If analysis of the video streamresults in a risky situation match as programmed at the source device 110 or the targetdevice 120, the source device 110 may be configured to display an alert message to theuser. A new function call to the second API from thefirst API may be done according tothe previously stored semantic model of thefirst API. The disclosure herein enables translation of a request from a first API hosted on a source device 110 to a second API hosted on a target device 120. The translation may be based on hypermedia (e.g. HyperCat) and / or semantic web. Semantic Definition Format (SDF) may be used as a means to express the request as a format / semantics of the second API. The usage of SDF advantageously enables addressing description of abstract application types which suits particular implementations (or instances) better. Also, the usage of SDF provides a means to refer to multiple vocabularies and / or ontologies, which increases semantic interoperability and enables matching of ecosystems based on certain semantic models and / or semantic description. An application logic for thefirst API or the second API may make internal API callsto functions / services. An application logic is a logic for how to process an input and inwhat order to perform operations. The application logic is tied to an implementation. Forexample, afirst device 110 uses a sensor for heart beat every 30 seconds and performsan ‘averaging’ operation for the heartbeat of a person per hour. A second device may takea sample once every 60 seconds and provide either an average or minimum, maximum,and variations during a certain time interval. Thefirst device and the second device perform similar operations, but their application logic are different. The application logic may comprise variables that need to be populated from theAPI call. The application logic requires a semi-stateful system in order to dynamicallymanage new API calls, wherein the application logic determines if the application hasalready an API registered, or it is in discovery phase. During the discovery phase, the application requires to match its own semantic understanding of the function to the one being discovered and skipping or ignoring those functions that are not understandable by its own semantics. The semantic matching could be done in several ways. One is by defining a semantic object with a URL that should match or be equivalent to one used by the API. Another possibility is to use an intermediary, for example and API market, that assists with the discovery and the semantic translation. Such service could provide a semantic object identifier that would represent an equivalent to the function or parameters that the application understands. The application would use an API with the intermediary to request such IDs and the intermediary would match them to the semantic objects of the API. Then during discovery, the different parameters would be addressed in the responses used during the discovery with the semantic object identifier already defined instead of the URL of the object defined in the API. This last away alleviates the need of the application to implement semantic equivalence checking and can use more simple approach based in identifiers. Fig. 6a illustrates an embodiment of a signaling diagram of the invention. Thesignaling diagram showcases an example communication between the source device110 and the target device 120.The target device 120 stores 602 information about a second API hosted at thetarget device 120, wherein the information comprises i) an indication of a semanticmodel being used by the second API (e.g. type of input data accepted, type of outputdata to be expected), ii) optionally, an indication of functionality of the second API andiii) optionally, information related to the target device’s 120 capability (e.g. anecosystem that the target device 120 belongs to). The information may be stored in SDFformat using the SDF mapping extensions provided in the disclosure herein. The targetdevice 120 may query the second API for obtaining the information about the second API, prior to storing the information about the second API. The source device 110 transmits 604, to the target device 120, a request forproviding the semantic model of the target device 120 including, for example, thesemantic model used by the second API. The request optionally comprises a request forproviding the information related to the target device’s 120 capability. The requestoptionally comprises a request for providing the information related to the second API’s functionality. The target device 120 provides 606 the information comprising i) an indication of a semantic model being used by the second API (e.g. type of input data accepted, type of output data to be expected), ii) optionally, an indication of functionality of the second API and iii) optionally, information related to the target device’s 120 capability(e.g. an ecosystem that the target device 120 belongs to), in response to the requestfrom the source device 110. In some embodiments, the information may be provided by the target device 120 in SDF format using the SDF mapping extensions provided in the disclosure herein. In some embodiments, the source device 110 converts the information provided by the target device 120 into an interpretable format by the source device’s 110 first API. Furthermore, the source device 110 may map 608 parameters of the first API with the second API such that a remote API call may be made from the first API to thesecond API. In some embodiments, the target device 120 maps 610 parameters of thefirst API with the second API and then the target device 120 provides 612 the mapping information (i.e., which parameters correspond to each other in the first API and the second API) such that a remote API call may be made from the first API to the second API. Once the mapping of parameters is done between the first API and the second API, the mapping is stored 614 in the source device 120. The mapping may be used forany future requests from the first API to the second API without the need for a requestfor information about the semantic models from the source device 110 to the target device 120. If a capability of the target device 120, functionality of the second API and / or a semantic model of the second API changes, then the target device 120 mayupdate 616 the source device 110 about the changes (e.g. by sending a message to thesource device 110 regarding the changes). Fig. 6b illustrates an embodiment of a signaling diagram of the invention. Thesignaling diagram showcases an example communication between the source device 110, the target device 120 and the network node 130. The target device 120 registers 650 (e.g., transmits), at the network node 130,information about a second API hosted at the target device 120, wherein the information comprises i) an indication of a semantic model being used by the second API (e.g. type of input data accepted, type of output data to be expected), ii) optionally, an indication of functionality of the second API and iii) optionally, information related to the target device’s 120 capability (e.g. an ecosystem that the target device 120 belongs to). The information may be registered at the network node 130 in SDF format using the SDF mapping extensions provided in the disclosure herein. The network node 130 stores 652 the information registered by the target device120. The source device 120 transmits 654, to the network node 130, a request forproviding the semantic model of the target device 120 (including, for example, thesemantic model used by the second API). The request optionally comprises a request for providing the information related to the target device’s 120 capability. The request optionally comprises a request for providing the information related to the second API’s functionality. The network node 130 provides 656 (e.g. transmits to the source device 110) theinformation comprising i) an indication of a semantic model being used by the second API (e.g. type of input data accepted, type of output data to be expected), ii) optionally, an indication of functionality of the second API and iii) optionally, information related to the target device’s 120 capability (e.g. an ecosystem that the target device 120 belongs to), in response to the request from the source device 110. In someembodiments, the information may be provided by the network node 130 in SDF formatusing the SDF mapping extensions provided in the disclosure herein. In someembodiments, the source device 110 converts 658 (i.e., translates) the informationprovided by the network node 130 into an interpretable format by the source device’s110 first API. In some embodiments, the source device 110 maps 660 parameters of the first API with the second API such that a remote API call may be made from the first API tothe second API. In some embodiments, the network node 130 maps 662 parameters ofthe first API with the second API and then the network node 130 provides the mappinginformation (i.e., which parameters correspond to each other in the first API and thesecond API) to the source device 110 such that a remote API call may be made from thefirst API to the second API. Once the mapping of parameters is done between the first API and the secondAPI, the mapping may be stored 664 in the source device 120 and / or the network node130. The mapping may be used for any future requests from the first API to the second API without the need for a request for information about the semantic models from thesource device 110 to the network node 130. If a capability of the target device 120,functionality of the second API and / or a semantic model of the second API changes,then the target device 120 may update 666 the network node 130 about the changes.The network node 130 may in turn inform 668 the source device 110 about the changes. Fig. 7 illustrates an embodiment of a communication network node 700 of theinvention. As used herein, the communication network node 700 refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), routers, base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), RAN nodes, O-RAN nodes or components of anO-RAN node (e.g., O-RU, O-DU, O-CU), and / or any 6G network nodes. The source device110, the target device 120 and / or the network node 130 may also be implemented and illustrated as the communication network node 700 in Fig.7. Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi- cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs). The communication network node 700 includes a processing circuitry 702, a memory 704, a communication interface 706, and a power source 708. The communication network node 700 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the communication network node 700 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the communication network node 700 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated(e.g., separate memory 704 for different RATs) and some components may be reused(e.g., a same antenna 710 may be shared by different RATs). The communication networknode 700 may also include multiple sets of the various illustrated components for different wireless technologies integrated into the communication network node 700, forexample GSM, WCDMA, LTE, NR, 6G, WiFi, Zigbee, Z-wave, LoRaWAN, Radio FrequencyIdentification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within the communication network node 700. The processing circuitry 702 may comprise a combination of one or more of amicroprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit,field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other communication network node 700 components, such as the memory 704, to provide the communication network node 700 functionality. In some embodiments, the processing circuitry 702 includes a system on a chip(SOC). In some embodiments, the processing circuitry 702 includes one or more of radiofrequency (RF) transceiver circuitry 712 and baseband processing circuitry 714. In someembodiments, the radio frequency (RF) transceiver circuitry 712 and the basebandprocessing circuitry 714 may be on separate chips (or sets of chips), boards, or units, suchas radio units and digital units. In alternative embodiments, part or all of RF transceivercircuitry 712 and baseband processing circuitry 714 may be on the same chip or set ofchips, boards, or units. The memory 704 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, aflash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non-transitory device- readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry 702. The memory 704 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or otherinstructions capable of being executed by the processing circuitry 702 and utilized by thecommunication network node 700. The memory 704 may be used to store anycalculations made by the processing circuitry 702 and / or any data received via thecommunication interface 706. In some embodiments, the processing circuitry 702 andmemory 704 is integrated.The communication interface 706 is used in wired or wireless communication ofsignaling and / or data between a network node, access network, and / or UE. As illustrated,the communication interface 706 comprises port(s) / terminal(s) 716 to transmit andreceive data, for example to and from a network over a wired connection. Thecommunication interface 706 also includes radio front-end circuitry 718 that may becoupled to, or in certain embodiments a part of, the antenna 710. Radio front-end circuitry718 comprisesfilters 720 and amplifiers 722. The radio front-end circuitry 718 may beconnected to an antenna 710 and processing circuitry 702. The radio front-end circuitrymay be configured to condition signals communicated between antenna 710 andprocessing circuitry 702. The radio front-end circuitry 718 may receive digital data that isto be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 718 may convert the digital data into a radio signal having the appropriatechannel and bandwidth parameters using a combination offilters 720 and / or amplifiers722. The radio signal may then be transmitted via the antenna 710. Similarly, whenreceiving data, the antenna 710 may collect radio signals which are then converted intodigital data by the radio front-end circuitry 718. The digital data may be passed to the processing circuitry 702. In other embodiments, the communication interface may comprise different components and / or different combinations of components. In certain alternative embodiments, the communication network node 700 does not include separate radio front-end circuitry 718, instead, the processing circuitry 702 includes radio front-end circuitry and is connected to the antenna 710. Similarly, in someembodiments, all or some of the RF transceiver circuitry 712 is part of the communicationinterface 706. In still other embodiments, the communication interface 706 includes oneor more ports or terminals 716, the radio front-end circuitry 718, and the RF transceiver circuitry 712, as part of a radio unit (not shown), and the communication interface 706 communicates with the baseband processing circuitry 714, which is part of a digital unit (not shown). The antenna 710 may include one or more antennas, or antenna arrays,configured to transmit and / or receive wireless signals. The antenna 710 may be coupledto the radio front-end circuitry 718 and may be any type of antenna capable oftransmitting and receiving data and / or signals wirelessly. In certain embodiments, theantenna 710 is separate from the communication network node 700 and connectable tothe communication network node 700 through an interface or port. The antenna 710, communication interface 706, and / or the processing circuitry702 may be configured to perform any receiving operations and / or certain obtainingoperations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna 710, the communication interface 706, and / orthe processing circuitry 702 may be configured to perform any transmitting operationsdescribed herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment. The power source 708 provides power to the various components of thecommunication network node 700 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source708 may further comprise, or be coupled to, power management circuitry to supply thecomponents of the communication network node 700 with power for performing thefunctionality described herein. For example, the communication network node 700 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 708. As a further example,the power source 708 may comprise a source of power in the form of a battery or batterypack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail. Embodiments of the communication network node 700 may include additional components beyond those shown in Fig.5 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and / or anyfunctionality necessary to support the subject matter described herein. For example, thecommunication network node 700 may include user interface equipment to allow input of information into the communication network node 700 and to allow output of information from the communication network node 700. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the communication network node 700. The communication network node 700 is configured to perform the operations according to any of the methods disclosed herein in relation tothe communication network node 700, including the methods shown in Figs. 2, 3 and 4,the block diagram of Fig. 5 and the signaling diagrams of Figs. 6a and 6b.Fig.8 illustrates an embodiment of a wireless device 800 of the invention. As usedherein, the wireless device 800 refers to a device capable, configured, arranged and / oroperable to communicate wirelessly with network nodes and / or other wireless devices.Examples of the wireless device 800 include, but are not limited to, a smart phone, mobilephone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device,music storage device, playback appliance, wearable terminal device, wireless endpoint,mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examplesinclude any wireless device 800 identified by the 3rd Generation Partnership Project(3GPP) including a 6G compatible wireless device, including a narrow band IoT (NB-IoT)wireless device, a machine type communication (MTC) wireless device 800, and / or anenhanced MTC (eMTC) wireless device. The wireless device 800 is configured to perform the operations according to any of the methods disclosed herein in relation to the source device 110, the target device 120 and / or the network node 130, including the methods shown in Figs.2, 3 and 4, the block diagram of Fig.5 and the signalling diagrams of Figs.6a and 6b. The source device 110, the target device 120 and / or the network node 130may also be implemented and illustrated as the wireless device 800 in Fig.8. The wireless device 800 may support device-to-device (D2D) communication,for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to- infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, the wirelessdevice 800 may not necessarily have a user in the sense of a human user who ownsand / or operates the relevant device. Instead, the wireless device 800 may represent adevice that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinklercontroller). Alternatively, the wireless device 800 may represent a device that is notintended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter). The wireless device 800 includes processing circuitry 802 that is operativelycoupled via a bus 804 to an input / output interface 806, a power source 808, a memory810, a communication interface 812, and / or any other component, or any combinationthereof. Certain wireless devices may utilize all or a subset of the components shown inFig.8. The level of integration between the components may vary from one wirelessdevice to another wireless device. Further, certain wireless devices may contain multipleinstances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc. The processing circuitry 802 is configured to process instructions and data andmay be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 810. Theprocessing circuitry 802 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processingcircuitry 802 may include multiple central processing units (CPUs).In the example, the input / output interface 806 may be configured to provide aninterface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the wireless device 800. Examples of an input device include a touch- sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device. In some embodiments, the power source 808 is structured as a battery or batterypack. Other types of power sources, such as an external power source (e.g., an electricityoutlet), photovoltaic device, or power cell, may be used. The power source 808 mayfurther include power circuitry for delivering power from the power source 808 itself,and / or an external power source, to the various parts of the wireless device 800 viainput circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 808. Power circuitry may perform anyformatting, converting, or other modification to the power from the power source 808 tomake the power suitable for the respective components of the wireless device 800 towhich power is supplied.The memory 810 may be or be configured to include memory such as randomaccess memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 810 includes one or more application programs 814, such as an operating system, web browser application, a widget, gadget engine, or other application, and correspondingdata 816. The memory 810 may store, for use by the wireless device 800, any of avariety of various operating systems or combinations of operating systems. The memory 810 may be configured to include a number of physical drive units,such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatiledisc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive,holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ Thememory 810 may allow the wireless device 800 to access instructions, applicationprograms and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 810, which may be or comprise a device-readable storage medium. The processing circuitry 802 may be configured to communicate with an accessnetwork or other network using the communication interface 812. The communicationinterface 812 may comprise one or more communication subsystems and may includeor be communicatively coupled to an antenna 822. The communication interface 812 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wirelesscommunication (e.g., another wireless device or a network node in an access network).Each transceiver may include a transmitter 818 and / or a receiver 820 appropriate toprovide network communications (e.g., optical, electrical, frequency allocations, and soforth). Moreover, the transmitter 818 and receiver 820 may be coupled to one or moreantennas (e.g., antenna 822) and may share circuit components, software or firmware, or alternatively be implemented separately. In the illustrated embodiment, communication functions of the communicationinterface 812 may include cellular communication, Wi-Fi communication, LPWANcommunication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth. Regardless of the type of sensor, the wireless device 800 may provide an outputof data captured by its sensors, through its communication interface 812, via a wirelessconnection to a network node. Data captured by sensors of the wireless device 800 canbe communicated through a wireless connection to a network node via another wireless device. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient). As another example, the wireless device 800 comprises an actuator, a motor, ora switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the wirelessdevice 800 may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. The wireless device 800, when in the form of an IoT device, may be a device foruse in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an IoT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensoryenhancement, a water sprinkler, an animal- or item-tracking device, a sensor formonitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgicalrobot. The wireless device 800 in the form of an IoT device comprises circuitry and / orsoftware in dependence of the intended application of the IoT device in addition toother components as described in relation to the wireless device 800 shown in Fig. 6.As yet another specific example, in an IoT scenario, the wireless device 800 mayrepresent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another wirelessdevice 800 and / or a network node. The wireless device 800 may in this case be an M2Mdevice, which may in a 3GPP context be referred to as an MTC device. As one particularexample, the wireless device 800 may implement the 3GPP NB-IoT standard. In otherscenarios, the wireless device 800 may represent a vehicle, such as a car, a bus, a truck,a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. As yet another specific example, in an IoT scenario, the wireless device 800 mayrepresent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another wirelessdevice 800 and / or a network node via a wired means (e.g. via ethernet).In practice, any number of wireless devices may be used together with respect toa single use case. For example, a first wireless device might be or be integrated in adrone and provide the drone’s speed information (obtained through a speed sensor) toa second wireless device that is a remote controller operating the drone. When the usermakes changes from the remote controller, the first wireless device may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’sspeed. The first and / or the second wireless device can also include more than one of thefunctionalities described above. For example, the wireless device 800 might comprisethe sensor and the actuator, and handle communication of data for both the speed sensor and the actuators. Fig. 9 illustrates an embodiment of a computer program product 810 accordingto the invention. The computer program product 910 of the source device 110, thetarget device 120 and / or the network node 130 includes a computer readable storagemedium (storage or recording medium) storing a computer program 920 comprising computer readable instructions. The computer readable medium of the source device110, the target device 120 and / or the network node 130, may be a non-transitorycomputer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the computer readable instructions of the computer program 720 are configured such that when executed by processing circuitry 702 and / or the processing circuitry 802, the computer readable instructions cause the source device 110, thetarget device 120 and / or the network node 130 to perform steps described herein (e.g.,method 200, method 300, method 400, block diagram of Fig.5 and signaling diagrams of Fig.6a and 6b). In other embodiments, the source device 110, the target device 120and / or the network node 130 may be configured / operable to perform steps describedherein without the need for code. That is, for example, the processing circuity 702 and / or the processing circuitry 802 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software. The computer program code mentioned above may also be provided, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the hardware. One such carrier may bein the form of a CD ROM disc. It is however feasible with other data carriers such as amemory stick. The computer program code may furthermore be provided as pureprogram code on the source device 110, the target device 120 and / or the network node130, and downloaded to the hardware at production, and / or during software updates. When an API hosted by the source device requires a mapping of applications and / or functions by semantic matching in addition to the actual discovery of the API. This matching may be enabled by several mechanisms as described, and the matching is dynamically adjusted to every new interfaced faced. By using SDF mapping extensions in conjunction with the new SDF qualities (i.e., the first SDF quality and thesecond SDF quality), an automated way to match functionality to application intents isprovided in the embodiments disclosed herein.

Claims

CLAIMS 1. A method (200) for communication between a first application program interface,API, hosted at a source device (110) and a second API hosted at a target device (120),wherein the first API and the second API have different semantic models, the methodbeing performed by the source device (110), the method comprising:obtaining (202), using a Semantic Definition Format, SDF, mapping extension,an indication of a semantic model of the second API; wherein the SDF mapping extension comprises: a first SDF quality comprising an API call definition, wherein the API call definition comprises a first key relating to the second API; and a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model of the second API; and transmitting (204), to the target device (120), a first message, wherein a syntaxof the first message is based on the obtained indication of the semantic model of the second API.

2. The method of claim 1, wherein the indication of the semantic model comprises a semantic descriptor for the second API.

3. The method of claims 1 or 2, wherein the indication of the semantic model comprises at least one of: i) an available command for the target device (120);ii) a function call signature supported by the target device (120);iii) a vocabulary that is interpretable by the target device (120);iv) a semantic model used by the target device (120);v) an operator provided and / or required by the second API; vi) a parameter provided and / or required by the second API; vii) a syntax for an input for the target device (120); and / orviii) a syntax for an output for the target device (120).

4. The method of claims 1-3, comprising: translating (206; 658) a syntax of the first message based on the obtained indication of the semantic model of the second API.

5. The method of claims 1-4, wherein the API call definition is a Uniform Resource Identifier, URI.

6. The method of claim 5, wherein a Uniform Resource Locator, URL is obtained from the URI.

7. The method of claim 1-6, wherein the SDF mapping extension provides a semanticmapping which is allowable by the source device (110).

8. The method of claims 1-7, wherein the SDF mapping extension is based on IETF Request for Comments, RFC, 6570.

9. The method of claims 1-8, comprising: storing (208) the obtained indication of a semantic model of the second API.

10. The method of claims 1-9, wherein obtaining (202) the indication of the semantic model comprises: retrieving the indication of the semantic model of the second API.

11. The method of claims 1-9, wherein obtaining (202) the indication of the semantic model comprises: transmitting, to a network node (130), a request to provide the indication of thesemantic model of the second API; and receiving, from the network node (130), the indication of the semantic model ofthe second API.

12. The method of claim 11, wherein the API call definition is a Uniform Resource Locator, URL and the method comprises:transmitting (210), to the network node (130), the request on the URL comprisedin the first SDF quality; and receiving (212), from the network node (130), the second SDF quality comprisingthe first value.

13. The method of claim 12, comprising: transmitting (214), to the network node (130), an indication of a semantic modelof the first API.

14. The method of claims 12 or 13, comprising:transmitting (216), to the network node (130), an indication of a semantic modelof a third API, wherein the indication of the semantic model of the third API is stored onthe source device (110) and / or obtained by the source device (110).

15. The method of claims 1-14, comprising: mapping (218; 608; 660) parameters of the first API with the second API.

16. The method of claims 1-15, comprising: receiving (220; 616), from the target device (120), an update about a change ini) a functionality of the second API, ii) a semantic model of the second API and / or acapability of the target device (120).

17. The method of claims 1-16, wherein the source device (110) and the target device(120) each belong to a different ecosystem.

18. The method of claims 1-17, wherein the API call definition is a URL and wherein the SDF mapping extension comprises: a third SDF quality indicating a method to transmit a request to the URL comprised in the first SDF quality.

19. A method (300) for communication between a first application program interface, API, hosted at a source device (110) and a second API hosted at a target device (120),wherein the first API and the second API have different semantic models, the method being performed by the target device (110), the method comprising: receiving (302), from the source device (120), a first message, wherein a syntaxof the first message is based on an obtained indication of the semantic model of thesecond API, wherein the indication of the semantic model of the second API is obtainedusing a Semantic Definition Format, SDF, mapping extension and wherein the SDFmapping extension comprises: a first SDF quality comprising an API call definition, wherein the API call definition comprises a first key relating to the second API; and a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model of the second API.

20. The method of claim 19, wherein the indication of the semantic model comprises a semantic descriptor for the second API.

21. The method of claims 19 or 20, wherein the API call definition is a Uniform ResourceIdentifier, URI.

22. The method of claims 19-21, wherein the SDF mapping extension is based on IETF Request for Comments, RFC, 6570.

23. The method of claims 19-22, comprising: receiving (304; 604), from the source device (110), a request to provide the indication of the semantic model of the second API.

24. The method of claim 23, comprising: transmitting (306; 606), to the source device (110), the indication of the semantic model of the second API.

25. The method of claims 19-24, comprising: receiving (308), from a network node (130), a request to provide the indicationof the semantic model of the second API.

26. The method of claim 25, comprising:transmitting (310), to the network node (130), the indication of a semanticmodel of the second API.

27. The method of claims 25 or 26, comprising:transmitting (312), to the network node (130), an indication of a semantic model of a third API, wherein the indication of the semantic model of the third API is stored on the target device (120) and / or obtained by the target device (120).

28. The method of claims 19-27, wherein the source device (110) and the target device (120) each belong to a different ecosystem.

29. The method of claims 19-28, wherein the API call definition is a URL and wherein the SDF mapping extension comprises: a third SDF quality indicating a method to transmit a request to the URL comprised in the first SDF quality.

30. The method of claims 19-29, comprising: storing (314; 602) information about the second API hosted at the target device (120), wherein the information comprises one or more of: i) an indication of a semantic model being used by the second API, ii) an indication of functionality of the second API and iii) information related to the target device’s 120 capability.

31. The method of claims 19-30, comprising: querying (316) the second API for obtaining information about the second API, wherein the information comprises one or more of: i) an indication of a semantic model being used by the second API, ii) an indication of functionality of the second API and iii) information related to the target device’s 120 capability.

32. The method of claims 19-31, comprising: mapping (318; 608) parameters of the first API with the second API.

33. The method of claims 19-32, comprising: providing (320; 612), to the source device (110), an update, wherein the updateis about a change in: i) a functionality of the second API, ii) a semantic model of thesecond API and / or iii) a capability of the target device (120).

34. A method (400) for communication between a first application program interface,API, hosted at a source device (110) and a second API hosted at a target device (120),wherein the first API and the second API have different semantic models, the methodbeing performed by a network node (130), the method comprising:obtaining (402), using a Semantic Definition Format, SDF, mapping extension,an indication of a semantic model of the second API, wherein the SDF mapping extension comprises: a first SDF quality comprising an API call definition, wherein the API call definition comprises a first key relating to the second API; and a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model; receiving (404; 654) on the API call definition, from the source device (110), arequest to provide an indication of a semantic model of the second API; and transmitting (406; 656), to the source device (110), the obtained indication ofthe semantic model of the second API.

35. The method of claim 34, wherein the API call definition is a Uniform Resource Identifier, URI.

36. The method of claims 34 or 35, comprising:obtaining (408) a first capability registration information comprising an indication of a semantic model used by: i) the source device (110) and / or ii) the first API.

37. The method of claim 36, wherein obtaining the first capability registration information comprises:receiving, from the source device (110), the first capability registrationinformation.

38. The method of claims 36 or 37, wherein obtaining the first capability registrationinformation comprises: observing at least one protocol of the source device (110); andinferring the semantic model of the first API based on the observation.

39. The method of claims 34-38, comprising: obtaining (410) a second capability registration information comprising anindication of a semantic model used by: i) the target device (120) and / or ii) the secondAPI.

40. The method of claim 39, wherein obtaining the second capability registration information comprises: receiving, from the target device (120; 650), the second capability registrationinformation.

41. The method of claims 39 or 40, wherein obtaining the second capability registrationinformation comprises: observing at least one protocol of the target device; and inferring the semantic model of the second API based on the observation.

42. The method of claims 34-41, comprising: receiving (412), from the source device (110), a first message, wherein a syntaxof the first message is based on a semantic model of the first API; translating (414) the first message into a syntax based on the obtained indication of the semantic model of the second API; and transmitting (416), to the target device (120), the translated first message.

43. The method of claims 34-42, wherein the indication of the semantic model comprises at least one of:i) an available command for the target device; ii) a function call signature supported by the target device; iii) a vocabulary that is interpretable by the target device; iv) a semantic model used by the target device; v) an operator provided and / or required by the second API; vi) a parameter provided and / or required by the second API; vii) a syntax for an input for the target device; and / or viii) a syntax for an output for the target device.

44. The method of claims 34-43, comprising: receiving (418), from the source device (110), an indication of a semantic modelof the first API.

45. The method of claims 34-44, comprising: receiving (420), from the source device (110), an indication of a semantic modelof a third API, wherein the indication of the semantic model of the third API is stored onthe source device (110) and / or obtained by the source device (110).

46. The method of claims 34-45, wherein the source device (110) and the target device(120) each belong to a different ecosystem.

47. The method of claims 34-46, wherein the API call definition is a URL and wherein the SDF mapping extension comprises: a third SDF quality indicating a method to transmit a request to the URL comprised in the first SDF quality.

48. A source device (110; 700; 800) for communication between a first applicationprogram interface, API, hosted at the source device (110) and a second API hosted at a target device (120), wherein the first API and the second API have different semanticmodels, the source device (110; 700; 800) comprising:at least one processing circuitry (702; 802); andat least one memory (704; 804) connected to the at least one processing circuitry (702; 802) and storing program code that is executed by the at least one processing circuitry to: obtain (202), using a Semantic Definition Format, SDF, mapping extension, an indication of a semantic model of the second API; wherein the SDF mapping extension comprises: a first SDF quality comprising an API call definition, wherein the API call definition comprises a first key relating to the second API; and a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model of the second API; and transmit (204), to the target device (120), a first message, wherein a syntax of the first message is based on the obtained indication of the semantic model of the second API.

49. The source device of claim 48, wherein the at least one processing circuitry isconfigured to perform the method according to any one of claims 2 to 18.

50. A target device (120; 700; 800) for communication between a first applicationprogram interface, API, hosted at a source device (110) and a second API hosted at the target device (120), wherein the first API and the second API have different semanticmodels, the target device (120; 700; 800) comprising:at least one processing circuitry (702; 802); and at least one memory (704; 804) connected to the at least one processing circuitry (702; 802) and storing program code that is executed by the at least one processing circuitry to: receive (302), from the source device (120), a first message, wherein a syntax of the first message is based on an obtained indication of the semantic model of the second API, wherein the indication of the semantic model of the second API is obtainedusing a Semantic Definition Format, SDF, mapping extension and wherein the SDFmapping extension comprises:a first SDF quality comprising an API call definition, wherein the API call definition comprises a first key relating to the second API; and a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model of the second API.

51. The target device of claim 49, wherein the at least one processing circuitry isconfigured to perform the method according to any one of claims 20 to 33.

52. A network node (130; 700; 800) for communication between a first applicationprogram interface, API, hosted at a source device (110) and a second API hosted at a target device (120), wherein the first API and the second API have different semanticmodels, the network node (130; 700; 800) comprising:at least one processing circuitry (702; 802); and at least one memory (704; 804) connected to the at least one processing circuitry (702; 802) and storing program code that is executed by the at least one processing circuitry to: obtain (402), using a Semantic Definition Format, SDF, mapping extension, an indication of a semantic model of the second API, wherein the SDF mapping extension comprises: a first SDF quality comprising an API call definition, wherein the API call definition comprises a first key relating to the second API; and a second SDF quality comprising a first value corresponding to the first key, wherein the first value is the indication of the semantic model; receive (404) on the API call definition, from the source device (110), a request to provide an indication of a semantic model of the second API; and transmit (406), to the source device (110), the obtained indication of the semantic model of the second API.

53. The network node of claim 52, wherein the at least one processing circuitry isconfigured to perform the method according to any one of claims 35 to 47.

54. A computer program (920) comprising instructions which, when executed by at least one processing circuitry (702; 802) of: a source device (110; 700; 800), causes the source device to carry out the method according to any one of claims 1 to 18; and / or a target device (120; 700; 800), causes the target device to carry out the methodaccording to any one of claims 19 to 33; and / ora network node (130; 700; 800), causes the network node to carry out themethod according to any one of claims 34 to 47.

55. A computer program product (910) stored on a non-transitory computer readable medium and comprising instructions that, when executed by at least one processing circuitry (702; 802) of: a source device (110; 700; 800), causes the source device to perform the method according to any one of claims 1 to 18; and / or atarget device (120; 700; 800), causes the target device to perform the methodaccording to any one of claims 19 to 33; and / ora network node (130; 700; 800), causes the network node to perform themethod according to any one of claims 34 to 47.

Images