Model-driven approach to ontology-based application development

Abstract

A system and method for ontology model development are disclosed. An example system and method may include: defining an ontology model, generating an ontology library based on the ontology model, deploying the ontology library to an Internet of Things system, generating an ontology instance based on the ontology library deployed to the Internet of Things system, modifying an Internet of Things application based on the ontology instance, and managing the Internet of Things system using the Internet of Things application.

Description

Technical Field

[0001] Embodiments of the present disclosure relate generally to methods of data processing, and more particularly to a model-driven approach to ontology-based application development. Background Art

[0002] The Internet of Things (IoT) offers a variety of opportunities and value-added services in a variety of settings such as residential, commercial, and industrial. Such opportunities are made possible through connectivity and collaboration between various “things” or edge points in the IoT. However, many of these opportunities still face interoperability challenges due to the heterogeneous nature of these endpoints. Semantic technologies and linked data can be a good solution to these heterogeneity issues and the associated interoperability challenges. From modeling and development to storage and querying, many efforts have been made to develop ontology software suites. However, despite its potential and promise, semantic technologies remain in the hands of a few ontology experts.

[0003] Based on this challenge, in order to accelerate the adoption and development of ontology-based IoT applications without the need for ontology experts, an ontology-based model-driven methodology is needed to develop existing ontology libraries and frameworks. Summary of the invention

[0004] Systems, methods, and computers for performing ontology model development are disclosed. An example system and method may include defining an ontology model, generating an ontology library based on the ontology model, deploying the ontology library to an Internet of Things system, generating an ontology instance based on the ontology library deployed to the Internet of Things system, modifying an Internet of Things application based on the ontology instance, and managing the Internet of Things system using the Internet of Things application.

[0005] Other embodiments of the above-described systems, methods, and computers contemplate that the defined ontology model is composed of a plurality of ontology models, and the plurality of ontology models are defined by an autonomous system and / or defined by a machine learning system.

[0006] Other embodiments of the above-described systems, methods, and computers contemplate that the generated ontology library is for an embedded IoT application or a cloud-based IoT application.

[0007] A further embodiment contemplates a processor-readable non-transitory storage medium comprising a plurality of instructions for managing data, wherein execution of the plurality of instructions by one or more hardware processors performs a plurality of actions, the actions comprising defining an ontology model, generating an ontology library based on the ontology model, deploying the ontology library to an Internet of Things system, generating an ontology instance based on the ontology library deployed to the Internet of Things system, modifying an Internet of Things application based on the ontology instance, and managing the Internet of Things system using the Internet of Things application. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] These drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component illustrated in various figures is represented by a line number. For clarity, not every component is labeled in every drawing. In the drawings:

[0009] Figure 1 Various aspects of ontology representation are described according to various embodiments of a model-driven approach to ontology-based application development;

[0010] Figure 2 Various aspects of the flowchart are described according to various embodiments of a model-driven approach to ontology-based application development;

[0011] Figure 3 Various aspects of the system architecture are described according to various embodiments of a model-driven approach to ontology-based application development;

[0012] Figure 4 Various aspects of a data model diagram are described according to various embodiments of a model-driven approach to ontology-based application development;

[0013] Figure 5 An embodiment of a model-driven approach to ontology-based application development is a functional block diagram of a general-purpose computer system; and

[0014] Figure 6 according to Figure 5 A general-purpose computer system is a functional block diagram of a general-purpose storage system. DETAILED DESCRIPTION

[0015] The present disclosure is not limited in its application to the configuration details and components set forth in the following description or illustrated by the accompanying drawings. The present disclosure can have other embodiments and can be practiced or implemented in various ways. In addition, the words and terms used herein are for descriptive purposes and should not be considered limiting. The use of "includes," "comprising," "having," "including," "involving," and variations thereof herein is open ended, i.e., "including but not limited to."

[0016] The Internet of Things (IoT) promises to massively interconnect a large number of sensors, devices, gateways, and systems to address many challenges in various industries. This interconnection is an important part in designing industrial systems with value-added services that are more energy efficient at low cost while contributing to a better environment. These benefits facilitated by the advent of the Industrial Internet of Things (IoT) have proliferated the importance of interoperability between IoT devices to turn this vision into reality.

[0017] The design of IoT applications leverages a common understanding of the data exchanged between those "things". Semantic technologies are a growing area in the knowledge representation space that promises to enable interoperability in IoT. The World Wide Web Consortium (W3C) has defined a set of standards that include, among other things, representation and query languages, providing a beneficial ecosystem to address the heterogeneity challenges in IoT. In industrial environments and automation, semantic technologies have been used to address various data interoperability issues and provide context-aware applications and services.

[0018] In addition to standardization, there are several resources that contribute to the development of ontology software suites. Examples include ontology editors, storage, reasoning engines, and / or graphical tools for representation, editing, and querying. Developers typically leverage two types of frameworks in the form of serializers, such as RDF4J, and object-relational mappers (ORMs), such as RomanticWeb.

[0019] Semantic technologies and ontology-based IoT applications are still often used only by ontology experts. One potential reason for the exclusion of others in this field could be the lack of appropriate methodologies and tools that involve other key actors in the design lifecycle of IoT applications and make them usable by others, other than ontology system experts. A set of proposed solutions could include model-driven methodologies and software module approaches that remove barriers for IoT developers and accelerate the adoption of semantic technologies. An example of a possible validation of the proposed modules based on the SAREF ontology.

[0020] Serializers may be used to provide read / write access to ontology documents, SPARQL protocol endpoints, and / or persistent Resource Description Framework (RDF) repositories. Resource Description Framework serializers may be implemented in various programming languages, examples include OWL API in Java, RDF4J and / or Jackson-Jsonld, dotNetRDF in .Net, Redland in C, and RDFLib in Python. The serializer application programming interface (API) may provide low-level classes and functions to manipulate concepts that map directly to the Resource Description Framework language without requiring any higher-level abstractions. Therefore, in order to implement ontology-based IoT applications, it is helpful for any IoT developer to understand the technical aspects and theories of the Resource Description Framework concepts and principles.

[0021] Some serializers may provide basic code generation through plugins that take an ontology as input and generate code facilitators or stubs. For example, the Protégé code generation plugin that may be integrated into Protégé provides Java code generation based on the OWL API. However, the code generation may be partial in nature, where only class names and interfaces and associated empty constructors are provided. Developers may decide to complete the generated code by adhering to, for example, an OWL API that can be directly mapped to Resource Description Framework (RDF) concepts. The RDF4J Schema generator extends the RDF4J API and provides automatic generation of Resource Description Framework schemas from an ontology. The output of the ontology generation may be contained in a Java file that contains only the Internationalized Resource Identifiers (IRIs) for each concept of the ontology. The result of this process is "flat" code generation, where there are no classes, associations, or constraints between the generated elements. The developer may then manually implement the associations, mappings, and constraints.

[0022] AutoRDF can extend the Redland library and propose a generator that takes an ontology and generates C++ object-oriented code to manipulate the Resource Description Framework concepts. The generated code is an abstraction layer that contains a set of functions based on ontology classes and relations, which developers can use to generate ontology instances (A-Boxes).

[0023] Object-relational mappers (ORMs) can be built on top of serializers and provide an object-oriented abstraction layer that allows developers to manipulate objects rather than Resource Description Framework (RDF) concepts. Several object-relational mappers are available in various programming languages, such as KOMMA, Empire and / or AliBaba in Java, RomanceNet and TrinityRDF in .Net, and RDFAlchemy in Python. Object-relational mappers make use of "code decoration", where developers annotate code with tags that reference internationalized resource identifiers from ontology terms (T-Boxes). Many Java object-relational mappers (Java ORMs) rely on the Java Persistence API (JPA), while .Net ORMs rely on the Entity Framework. During code implementation of an application, developers can request a factory that instantiates an ontology (A-Box) and can formulate SPARQL queries relying on a SPARQL query builder or adapter in the .NET domain, such as LINQ to SPARQL.

[0024] The following object-relational mappers provide some code generation capabilities. For example, AliBaba provides the following three interesting features for ontology developers. First, the object server exposes object factories through the REST application programming interface, making available objects as manually annotated resources on the web. Second, Aspect behaviors allow each factory object to intercept method requests and execute specific behaviors. Annotations such as prepend provide developers with greater control over the behavior execution flow. Third, SPARQL query decoration on the getters / setters of objects that implement dynamic query execution.

[0025] As another example, KOMMA relies on the Eclipse Modeling Framework (EMF). KOMMA provides a unified framework consisting of three layers. First, the object mapping persistence layer. Second, the visualization tools. Third, the ontology editor based on EMF capabilities. KOMMA details the code generator plug-in, however, it is not integrated in the visualization and editing layer, so the mapping and implementation of the interface is still manual for the developer. KOMMA's unified approach may target ontology developers with the integration of the three layers in a common framework.

[0026] Using this general approach, Figure 1 Various aspects of ontology representation are described according to various embodiments of a model-driven approach to ontology-based application development. Embodiments may include, but are not limited to, residential, commercial, and / or industrial systems composed of various ontologies, such as device types, quantities and units and / or locations.

[0027] Figure 1 An embodiment based on the concepts disclosed above illustrates one of many potential examples of an ontology representation. A device catalog (e.g., building server, server...), quantity and unit (e.g., data source, temperature...), and location (e.g., building, floor...) (T-Box) ontology is created. Ontology models (A-Boxes) are also created and maintained (e.g., Bldg A, L2, West2, 202A). In addition, these A-Boxes can be attached to one of the available resource description framework development libraries described in the previous section to formulate queries to extract T-Box data. In this way, a user can determine specific information about an object without the need for an expert in the object. For example, a user can query "Where is my building server?" and receive a response "Room 202A, West Section, 2nd Floor, Building A". A user or system no longer needs an expert to query and receive actionable information.

[0028] Two other factors emerge regarding this ontology-based approach to IoT application development. First, the technical feasibility of ontology-based vertical and horizontal solutions in an industrial context. Several ontology designs demonstrate the benefits of vertical and horizontal deployments. In a vertical deployment or silo, a sensor-to-gateway or a device / system-to-cloud connection is combined with area-specific applications. A common example is when several endpoints (e.g., sensors) communicate with a communication aggregation device such as a gateway. This gateway may then communicate with a cloud. Various vertical silos can be used based on technical area (e.g., industrial system), geographical location (e.g., building A), technical area (e.g., temperature sensor), and / or a combination of all of these.

[0029] A horizontal deployment may involve integrating different silos (vertical lines), areas where the silos drive interoperability between overall systems and devices. As one of many examples, two industrial systems, a building management, and a power solution system may be connected to the cloud. In these cases, we appear to have disparate systems that can relate to each other through a common ontology. As mentioned earlier, a significant benefit of the present disclosure is that it is no longer necessary for users to be experts in all of these areas to use the overall system.

[0030] Secondly, an adaptation layer exposes the information of the system through an ontology representation, which can be consumed by a business intelligence layer to extract information based on various business intelligence systems. A cloud-based joint query ontology and time series engine enables big data queries for business and machine learning applications. In addition, domain-specific ontologies are emerging in the industry and standardization bodies. For example, in the field of smart buildings, ontologies such as SAREF and extensions, Haystack and Brick have emerged. In addition, efforts have been proposed for energy modeling and access, such as Siemens Work, SPITFIRE and OptiquePlatform2.

[0031] These combinations now allow for the creation and optimization of relationships within the existing systems that a user is responsible for, as well as any external data that may exist (e.g., a data lake). Additionally, these relationships may be used for management of corresponding business operations through recommendations to a user who may later articulate changes, through autonomous systems, and / or a combination of both. Finally, based on the relationships formed, optimized, executed, and learned, these relationships and optimized data may be used in other machine learning systems to further optimize the respective systems. Other benefits related to embodiments of the present disclosure are described below.

[0032] Ontologies powerfully represent the topology of internal systems, such as the interconnectivity between the devices and sensors, their physical locations, and the functional interactions between them. Although a useful abstraction layer is provided by an object-relational mapper, a mapping is still usually required through code decoration. However, IoT developers may take advantage of a Just Instantiate and Link library that may be introduced into a development environment, where the concepts and relationships of the ontology model (T-Box) are provided using the described methods. Once such a library is introduced, a developer can instantiate the ontology concepts and link them into an ontology instance (A-Box). Such libraries can rely on, for example, existing SDKs and other available libraries. This capability reduces the burden on developers to become experts in the relevant IoT systems they are programming.

[0033] Various programming languages ​​may be used to obtain the benefits of embodiments of the present disclosure. The diversity of different industries, businesses, and implementations benefits from the diversity of skill sets that implement IoT-based applications using different programming languages. These applications may range from embedded devices (c, c++, python), systems (c++, .Net, java), and / or cloud applications. Therefore, it is beneficial to support such real-time instantiation and linking library support and various dependencies on third-party libraries and programming languages. It should be understood that these are merely examples of programming languages ​​that can be used in various embodiments of the present disclosure.

[0034] A wide variety of query languages ​​can be used. In various embodiments of the present disclosure, it is very advantageous to store and retrieve data on a system or cloud. The IoT development community often varies in the query languages ​​used. While some are familiar with query languages ​​such as SQL or LINQ and advocate reusing them in development based on the IoT ontology, other developers use SPARQL as an evolving non-tabular query language. It is possible to generate SPARQL through a visual tool using an alternative such as the visual query builder and use it in the IoT development. It should be understood that these are merely examples of query languages ​​that can be used in various embodiments of the present disclosure.

[0035] Figure 2Various aspects of a flowchart are described according to various embodiments of a model-driven method for ontology-based application development. The flowchart includes an ontology expert, a domain expert, one or more ontology features, one or more ontology libraries, one or more ontology models, one or more Internet of Things systems, one or more data warehouses, multiple Internet of Things developers and / or one or more Internet of Things applications. It should be understood that these are merely examples of a flowchart and that various elements can be used in various embodiments of the present disclosure.

[0036] The ontology expert 200 may be an ontology practitioner who is typically experienced in the ontology development tools, languages, and storage infrastructure. Examples of their tasks may include assisting a domain expert 202 in capturing the concepts used in an IoT application to be deployed in a specific domain. The domain expert 202 may be a product owner and / or a technical architect. They typically have global and / or specific knowledge of how to deploy, invest, and / or operate a specific system. They can work in collaboration with the ontology expert 200 and explicitly express the concepts and / or relationships of a system with the ontology expert 200.

[0037] It should be understood that some embodiments may not utilize these roles, utilize one or more of these roles, as some ontology models (T-boxes) 204 may be retrieved from memory, and / or automatically generated from a machine learning system. In addition, an individual may play multiple roles, as an ontology expert 200 and a domain expert 202 or team may play these roles and may create ontology concepts and relationships to form an ontology model (T-Box) 204 as described below, and propose an ontology for further processing.

[0038] An ontology model (T-Box) 204 may be provided to an ontology library generator (Ontology Library Generator, OLGA 206), which is also later Figure 3. OLGA 206 receives an ontology and its imported ontology, the imported ontology together with a selection of the desired library or framework. OLGA 206 then generates a library 208 to conform to the previously defined ontology model (T-Box) 204. A generated library 208 abstracts the ontology complexity and enables IoT developers to instantiate and link ontology categories and relationships previously defined by the ontology expert 200 and domain expert 202. A generated library 208 may depend on a serializer or an object-relational mapper library. An ontology model (T-Box) 204 may also or additionally be provided to a resource description framework (RDF) repository for additional / future uses. The ontology expert 200 and / or domain expert 202 may iterate, extend or reuse or extend the existing ontology model 204.

[0039] An embedded IoT developer 214 can implement an embedded IoT application 216 using the ontology model (T-Box) 204 previously defined by the experts 200, 202. The embedded IoT application 216 may be used in a device and / or system. The embedded IoT developer 214 can import the generated library 208, which contains the ontology concepts and relationships previously defined to instantiate the embedded IoT application 216.

[0040] An ontology instance (A-Box) 218 ​​may be derived from the embedded IoT application 216. Once integrated, the ontology concepts are linked together into an ontology instance (A-Box) 218. An ontology instance (A-Box) 218 ​​may also or additionally be provided to a resource description framework (RDF) repository for additional / future use.

[0041] The cloud IoT developer 210 may implement the IoT application 216 using the ontology model (T-Box) 204 previously defined by the experts 200, 202. The cloud-based application 212 may be used in one or more cloud systems. The cloud IoT developer 210 will import the generated library 208, which contains the ontology concepts and possible relationships previously defined to instantiate the model. The IoT application 216 may also or additionally be provided to a resource description framework repository for additional / future use.

[0042] An IoT developer may import the generated library 208 and embed the generated library into a device, system and / or an IoT cloud application. Once integrated into an existing system or device, the generated library may have multiple applications. In one example, used with commissioning software for a building management system, where the generated library 208 is used to instantiate an ontology model of a system for a given facility, an ontology instance 218 can capture Figure 1 . The ontology instance may then be sent along with the model to a cloud storage where a business application layer or an IoT based cloud application can query and extract information about a specific smart building to drive better insights. At the cloud level, a developer may also import a generated library 208 of their choice through the OLGA 206 supporting the programming language and technology. A generated library may conform to the same ontology defined by the expert and will be used to interact with a resource description framework repository to load and query instances of the model to fulfill the cloud application requirements.

[0043] An additional benefit of embodiments of the described methodology enables separation of aspects and roles and places the complexity in areas that can be addressed by relying on an appropriate tool and domain expertise. A domain expert 202 typically has both overall knowledge and specific knowledge about a particular system and domain. An ontology expert 200 may be a modeling practitioner, but may lack the overall system vision and domain knowledge expertise. Finally, IoT developers 210, 214 may now decide the programming language and framework of their choice to implement ontology-based IoT applications by relying on the generated library, which conforms to the ontology model without the complexity of the ontology language.

[0044] Figure 3 Various aspects of a system architecture are described according to various embodiments of a model-driven approach to ontology-based application development. Embodiments of the architecture may include, but are not limited to, a multi-library builder, importer, guest, model, builder, compiler and packager, and / or various tools and resources generally used to create applications across platforms.

[0045] OLGA 206 is a Figure 3A multi-library code generator of various embodiments described. OLGA 206 may accept various inputs, including one or more ontologies 300. Notably, an ontology may depend on other ontologies as well as a selection of library dependencies. Various embodiments contemplate that a generated library may depend on a serializer or an object-relational mapper (ORM). OLGA 206 may use pre-existing libraries and frameworks. By providing the IoT developer with multiple options for development of ontology-based IoT applications, OLGA 216 enables an IoT developer to select and reuse existing open source libraries (e.g., serializers or object-relational mappers) while providing an abstraction and library to use that conforms to an ontology model previously specified by the various domain experts.

[0046] Various embodiments of OLGA 206 consist of the following ontology library generator subsystem 310. An Importer loads the one or more input ontologies 300 into memory and processes them into a single optimized ontology. A Visitor spans all elements of the ontology processed by the Importer. The Visitor processes one or more of the following ontology elements: categories, object attributes, data attributes, individuals, literals, and / or various axioms used to populate the data model, such as Figure 4 It should be understood that any or both of the importers and / or visitors may interact with the OWL API to create, manipulate and / or serialize OWL ontologies.

[0047] A model allows the import of the ontology information (T-Box) independent of any target library or programming language. Separating the model from any targeted implementation provides OLGA 206 flexibility in another language or dependent library that supports the use of templates. The model is populated by the visitor and consists of a presentation layer that captures all elements of an ontology. The model is described in Figure 4 The elements of the model are inherited from the superclass node, and the superclass node is identified by an international resource identifier (IRI) and a name parameter.

[0048] Based on the owl:SubClassOf, each class may have zero (owl:Thing) or multiple superclasses populated by the visitor. Classes such as namespace, package name, and class name are extracted based on the ClassIRI of the code generator. An example template used by OLGA 206 to generate RomanticWeb based code may be as follows:

[0049] <#if consolidatedImports??>

[0050] <#list consolidatedImports as import>

[0051] using${import};

[0052] < / #list>

[0053] < / #if>

[0054] namespace${Zclass.getPackageName()}

[0055] {

[0056] [Class(″${Zclass.Iri()}″)]

[0057] public interface I${Zclass.ClassName()}

[0058] <#if Zclass.SuperZClassList()??>

[0059] <#if Zclass.SuperZClassList()?has_content>:

[0060] <#list Zclass.SuperZClassList()as

[0061] SuperZClassCurrentElementOfList>

[0062] I${SuperZClassCurrentElementOfList.ClassName()}<#sep>,

[0063] < / #list>

[0064] <#else>:IEntity

[0065] < / #if>

[0066] < / #if>

[0067] {

[0068] <#if listDataProperties??>

[0069] <#list listDataProperties as DataPropertyList>

[0070] [Property(″${DataPropertyList.DataProperty()}″)]

[0071] ${DataPropertyList.RangeXSDType()}

[0072] ${DataPropertyList

[0073] .DataPropertyShortForm()? capitalize}{get;set;}

[0074] < / #list>

[0075] < / #if>

[0076] }

[0077] <#if listObjectProperties? ? >

[0078] < / #if>

[0079] }

[0080] exist Figure 4 In the data model described in , a class can have zero or several object properties (ObjectProperty). A visitor can fill the following parameters for each object property: a constraint type (owl:AllValuesFrom), an optional constraint cardinality (owl:minCardinality), a constraint number associated with the cardinality, possibly one or more characteristics of the property (owl:TransitiveProperty) and an optional expression (owl:UnionOf). An object property is associated with the following concepts:

[0081] Category to Category: One or more scope categories depending on the constraint type and expression. For example, a building contains certain floors.

[0082] Class to Individual: One or more range individuals depending on the constraint type and expression. For example, a TemperatureMeasure Class has a Unit Degree_Celsius Individual.

[0083] · Individual to Individual: When an individual is associated with another individual, the visitor will not populate the constraint type, cardinality, expression and characteristics. For example, a building 1 contains floor 1. For the purpose of the code generation only the name parameter is used in the object property.

[0084] A body is an instance of a class. A visitor populates the namespace and packageName for the code generator based on its internationalized resource identifier. When a DataProperty is associated with a body, the visitor only populates the scope (text). However, when the DataProperty is associated with a class, the visitor also populates the restriction type and restriction cardinality in addition to the previous parameters.

[0085] Templates may be set up through library dependencies, a serializer (Jackson-Jsonld, RDF4J) and / or an object-relational mapper (RomanticNet). As shown in the template examples above, each template may contain a code snippet written according to a programming language syntax (Java, C#, Python or other language), and may save various information waiting to be filled from the data model, such as the import declaration of the package associated with the dependent library, the name of the class / interface to be generated, etc. In addition, each of the data and object properties will be converted to a parameter using a getter / setter function. These templates will be loaded into memory by the generator, and the code snippet will be completed according to the information filled in the data model.

[0086] The generator may be based on a selected library dependency, where enough templates are loaded into memory to start code generation from the populated data model. The generator injects the information from the data model into the template. The separation between the model and the template provides flexibility and makes supporting an additional library a trivial matter for template extension. In the case of a selected object-relational mapper (ORM) dependency, each class and individual of the ontology may be generated into an interface. In fact, an object-relational mapper library provides a factory that allows developers to instantiate the interface into objects. OLGA 206 handles multiple inheritance and composition by generating interfaces that extend other interfaces. This makes code generation more efficient because potentially only the interface needs to be generated. Developers may use the factory to instantiate their objects based on the generated interface, so the object-relational mapper's factory will handle multiple extensions of the interface and its declared functions.

[0087] Because a serializer does not typically provide a factory to instantiate / implement a class, multiple interfaces and their implementations are generated in the event of selected serializer dependencies. OLGA 206 handles multiple inheritance and composition by propagating the implementation of the functions from the extended interface to the implementing class, and relying on Override annotations in Java (or similar) annotations in other programming languages.

[0088] Once the code is injected into the template, compilers and packagers can be used. A generator creates files containing the desired code, and then the compilation and packaging phase can begin. Depending on the selected library 320 and its programming language, an appropriate compiler is loaded. After the compilation is successfully completed, the packaging of the compiled image is triggered to prepare the appropriate format (.jar, .dll, .whl or other format).

[0089] Once the generated library is packaged, it can be imported and ready to be used by any IoT developer. An example of a SAREF generated library is then provided, where an IoT developer can instantiate and link, reference an Idegree_Celsius, and then create an indoor measurement and link to a specific instance of a temperature sensor. Such code that can be implemented by the IoT developer may then be deployed on a cloud-connected device or gateway. On more resource-rich systems, such as a building management server, a generated library that relies on an object-relational mapper may be used, as such systems may host local applications that can interact with a local resource description framework library.

[0090] Figure 4 Various aspects of a data model diagram are described according to various embodiments of a model-driven approach to ontology-based application development. Figure 3 Embodiments of the data model utilized by the system architecture described in may include a presentation layer that captures elements of an entity.

[0091] OLGA 206 may be deployed on any general purpose computer system and use a variety of languages, libraries and options. Some examples include the OWL application programming interface (API) for importing and merging one or more interdependent ontologies. A guest module uses the OWL API to generate the merged ontology and populate Figure 4The data model is displayed. A generator uses the FreeMarker template engine and the templates are written in the FreeMarker template language. FreeMarker provides a beneficial mechanism to inject parameters from the data model into the template to generate program code files. A compiler and packager module utilizes Maven plugins, which depend on the selected programming language, .Net3, Java4 and Python5. OLGA 206 generates a pom.xml file that can be used with the corresponding Maven plugin for compilation and packaging. It should be understood that these are only illustrative examples and the supported dependency library is expected to grow over time based on adoption and available technology.

[0092] An example of generating SAREF instantiation code for an ontology library:

[0093] public static void Create_SAREF_Topology()

[0094] {

[0095] / / refer to the unit

[0096] Idegree_Celsius degreeCelius=context

[0097] .Create<Idegree_Celsius> (new Uri(clientURI+″#1″));

[0098] / / Create a measurement from the factory

[0099] IMeasurement indoorTemperature=context

[0100] .Create <imeasurement>(new Uri(clientURI+″#2″));

[0101] indoorTemperature.AddIsmeasuredin_Only_UnitOfMeasure

[0102] .Add(degreeCelius);

[0103] indoorTemperature.Hasvalue=32;

[0104] indoorTemperature.Hastimestamp=DateTime.UtcNow;

[0105] / / Link it to Temperature

[0106] ITemperature temperature=context

[0107] .Create <itemperature>(new Uri(clientURI+″#3″));

[0108] temperature.AddRelatestomeasurement_Only_Measurement

[0109] .Add(indoorTemperature);

[0110] / / Create a Temperature Sensor

[0111] ITemperatureSensor temperatureSensor=context

[0112] .Create <itemperaturesensor>(new Uri(clientURI+″#4″));

[0113] temperatureSensor.Hasmanufacturer="CompanyA";

[0114] temperatureSensor.Hasmodel="M321";

[0115] temperatureSensor

[0116] .Hasdescription="Low range Zigee temperature sensor";

[0117] / / add its measurement

[0118] temperatureSensor.AddMakesmeasurement_Only_Measurement

[0119] .Add(indoorTemperature);

[0120] / / commit data to factory

[0121] context.Commit();

[0122] }

[0123] As previously detailed, any general purpose computer system used in various embodiments of the present disclosure may be, for example, a general purpose computer such as a computer based on an Intel Pentium processor, a Motorola PowerPC, a Sun UltraSPARC, a HP PA-RISC processor, or any other type of processor.

[0124] For example, various embodiments of the present disclosure may be implemented in Figure 5 500 is a computer system 500 that is shown as being executed in dedicated software. The computer system 500 may include a processor 520 connected to one or more storage devices 530, such as a disk drive, memory, or other device for storing data. The memory 530 is typically used to store programs and data during operation of the computer system 500. The computer system 500 may also include a storage system 550 that provides additional storage capacity. The components of the computer system 500 may be coupled via an interconnection mechanism 540, which may include one or more buses (e.g., between components integrated within the same machine) and / or a network (e.g., between components residing on separate discrete machines). The interconnection mechanism 540 enables communications (e.g., data, instructions) to be exchanged between system components of the system 500.

[0125] The computer system 500 also includes one or more input devices 510, such as a keyboard, a mouse, a trackball, a microphone, a touch screen, and one or more output devices 560, such as a printing device, a display screen, and a speaker. In addition, the computer system 500 may include one or more interfaces (not shown) that connect the computer system 500 to a communication network (in addition to or instead of the interconnection mechanism 540).

[0126] exist Figure 6 The storage system 550, shown in more detail in FIG. 5 , generally includes a computer readable and writable non-volatile recording medium 610, wherein signals are stored in the non-volatile recording medium 610, the signals defining a program to be executed by the processor, or defining information to be processed by the program stored on or in the medium 610 to perform one or more functions associated with the embodiments described herein. The medium may be, for example, a disk or a flash memory. Typically, in operation, the processor causes data to be read from the non-volatile recording medium 610 to another memory 620, which allows the processor to access the information faster than the medium 610. The memory 620 is typically a volatile random access memory such as a dynamic random access memory (DRAM) or static random access memory (SRAM). As shown, it can be located in the storage system 600, or in the memory system 530. The processor 520 typically manipulates the data in the integrated circuit memory 530, 620, and then copies the data to the medium 610 after processing is completed. Various mechanisms are known for managing data movement between the medium 610 and the integrated circuit memory devices 530 , 620 , and the present disclosure is not limited thereto. The present disclosure is not limited to a particular memory system 530 or storage system 550 .

[0127] The computer system may include specially programmed dedicated hardware, such as an application specific integrated circuit (ASIC). Various aspects of the present disclosure may be implemented in software, hardware or firmware or any combination thereof. In addition, such method actions, systems, system elements and components thereof may be implemented as part of the above-mentioned computer system or as independent components.

[0128] Although computer system 500 is shown by way of example as one type of computer system on which various aspects of the present disclosure may be practiced, it should be understood that various aspects of the present disclosure are not limited to such computer systems. Figure 6 The computer system shown in FIG. Figure 6 Various aspects of the present disclosure may be practiced on one or more computers with different architectures or components as shown. In addition, the functions or processes of the embodiments of the present disclosure are described herein (or in the claims) as being executed on a processor or controller, and such description is intended to include systems that use more than one processor or controller to perform the functions.

[0129] Computer system 500 may be a general-purpose computer system that is programmable using a high-level computer programming language. Computer system 500 may also be implemented using specially programmed dedicated hardware. In computer system 500, processor 520 is typically a commercially available processor, such as a well-known Pentium-class processor obtained from Intel Corporation. Many other processors are also available. Such a processor typically executes an operating system, which may be, for example, Windows 95, Windows 98, Windows NT, Windows 2000, Windows ME, Windows XP, Vista, Windows 7, Windows 10 or a later operating system available from Microsoft Corporation, MACOS System X or a later operating system available from Apple Computer, Solaris operating system available from Sun Microsystems, UNIX, Linux (any distribution) or a later operating system available from various sources. Many other operating systems may be used.

[0130] The processor and the operating system together define a computer platform, and a high-level programming language is used to write application programs for the computer platform. It should be understood that the embodiments of the present disclosure are not limited to a specific computer system platform, processor, operating system, or network. Moreover, it is obvious to those skilled in the art that the present disclosure is not limited to a specific programming language or computer system. In addition, it should be understood that other appropriate programming languages ​​and other appropriate computer systems may also be used.

[0131] One or more portions of the computer system may be distributed across one or more computer systems coupled to a communication network. For example, as described above, a computer system that determines available power capacity may be located remotely from a system manager. These computer systems may also be general purpose computer systems. For example, various aspects of the present disclosure may be distributed across one or more computer systems configured to provide a service (e.g., a server) to one or more client computers, or to perform an overall task as part of a distributed system. For example, various aspects of the present disclosure may be performed on a client-server or multi-tier system that includes components distributed between one or more server systems that perform various functions according to various embodiments of the present disclosure. These components may be executable, intermediate (e.g., IL) or interpreted (e.g., Java) code that communicates over a communication network (e.g., the Internet) using a communication protocol (e.g., TCP / IP). For example, one or more database library servers may be used to store device data, such as expected power consumption, that is used to design a layout associated with an embodiment of the present disclosure.

[0132] It should be understood that the present disclosure is not limited to executing on any particular system or group of systems. Furthermore, it should be understood that the present disclosure is not limited to any particular distributed architecture, network or communication protocol.

[0133] Various embodiments of the present disclosure may be programmed using an object-oriented programming language such as SmallTalk, Java, C++, Ada, or C# (C-Sharp). Other object-oriented programming languages ​​may also be used. Alternatively, functional, scripting, and / or logic programming languages ​​such as BASIC, ForTran, COBoL, TCL, or Lua may be used. Various aspects of the present disclosure may be implemented in a non-programming environment (e.g., when a document created in HTML, XML, or other format is viewed in a window of a browser program, the document presents aspects of a graphical user interface (GUI) or performs other functions). Various aspects of the present disclosure may be implemented as programmed or non-programmed elements, or any combination thereof.

[0134] In the embodiments of the present disclosure discussed above, the analysis results described are provided in real time. As will be appreciated by those skilled in the art, the use of the term real time does not mean that the results are immediately available, but rather that the designer is given the ability to try out a variety of different designs in a short period of time, such as a few minutes, quickly and efficiently.

[0135] Thus, having described several aspects of at least one embodiment of the present disclosure, it should be appreciated that various changes, modifications and improvements will readily occur to those skilled in the art. Such changes, modifications and improvements are intended to be part of the present disclosure and are intended to fall within the spirit and scope of the present disclosure. Therefore, the foregoing description and drawings are intended only as examples.< / itemperaturesensor> < / itemperature> < / imeasurement>

Claims

1. A method for developing an application based on an ontology model, characterized in that: The method comprises: defining an ontology model, wherein the ontology model specifies a plurality of ontology categories and a plurality of relationships between the plurality of ontology categories; autonomously generating an ontology library based on an ontology library template by an ontology library generator, wherein the ontology library abstracts the plurality of ontology categories and the plurality of relationships defined in the ontology model and configured to generate a plurality of ontology instances, wherein the generated ontology library includes a plurality of generated functions corresponding to one of the plurality of ontology categories within the ontology model; Deploying the ontology library to an Internet of Things system; generating an ontology instance based on the ontology library deployed to the IoT system, wherein the ontology instance is derived from an IoT application executed in the IoT system; Exposing an adaptation layer of the Internet of Things system through an ontology representation to provide information to a business intelligence layer; and The Internet of Things system using the generated ontology instance and the business intelligence layer is managed through the Internet of Things application.

2. The method according to claim 1, characterized in that: The defined ontology model is composed of multiple ontology models.

3. The method according to claim 1, characterized in that: The ontology model is defined by an autonomous system.

4. The method according to claim 3, characterized in that: The ontology model is defined by a machine learning system.

5. The method according to claim 1, characterized in that: The generated ontology library is configured as an embedded Internet of Things application.

6. The method according to claim 1, characterized in that: The generated ontology library is configured as a cloud-based Internet of Things application.

7. A system for developing application programs based on an ontology model, characterized in that: The system comprises: a processor configured to: defining an ontology model, wherein the ontology model specifies a plurality of ontology categories and a plurality of relationships between the plurality of ontology categories; autonomously generating an ontology library based on an ontology library template by an ontology library generator, wherein the ontology library abstracts the plurality of ontology categories and the plurality of relationships defined in the ontology model and configured to generate a plurality of ontology instances, wherein the generated ontology library includes a plurality of generated functions corresponding to one of the plurality of ontology categories within the ontology model; Deploying the ontology library to an Internet of Things system; generating an ontology instance based on the ontology library deployed to the IoT system, wherein the ontology instance is derived from an IoT application executed in the IoT system; Exposing an adaptation layer of the Internet of Things system through an ontology representation to provide information to a business intelligence layer; and The Internet of Things system using the generated ontology instance and the business intelligence layer is managed through the Internet of Things application.

8. The system of claim 7, wherein :The ontology model defined therein is composed of multiple ontology models.

9. The system according to claim 7, characterized in that :Wherein the ontology model is defined by an autonomous system.

10. The system of claim 9, wherein :Wherein the ontology model is defined by a machine learning system.

11. The system of claim 7, wherein :The generated ontology library is configured as an embedded Internet of Things application.

12. The system of claim 7, wherein :The generated ontology library is configured as a cloud-based Internet of Things application.

13. An application development system based on ontology model, characterized in that: The system comprises: a network computer, comprising: a transceiver that communicates via a network; a memory storing at least one instruction set; and One or more processor devices that execute instructions to perform actions including: defining an ontology model, wherein the ontology model specifies a plurality of ontology categories and a plurality of relationships between the plurality of ontology categories; autonomously generating an ontology library based on an ontology library template by an ontology library generator, wherein the ontology library abstracts the plurality of ontology categories and the plurality of relationships defined in the ontology model and configured to generate a plurality of ontology instances, wherein the generated ontology library includes a plurality of generated functions corresponding to one of the plurality of ontology categories within the ontology model; Deploying the ontology library to an Internet of Things system; generating an ontology instance based on the ontology library deployed to the IoT system, wherein the ontology instance is derived from an IoT application executed in the IoT system; Exposing an adaptation layer of the Internet of Things system through an ontology representation to provide information to a business intelligence layer; and The Internet of Things system using the generated ontology instance and the business intelligence layer is managed through the Internet of Things application.

14. The system of claim 13, wherein :The ontology model defined therein is composed of multiple ontology models.

15. The system of claim 13, wherein :Wherein the ontology model is defined by an autonomous system.

16. The system of claim 15, wherein :Wherein the ontology model is defined by a machine learning system.

17. The system of claim 13, wherein :The generated ontology library is configured as an embedded Internet of Things application.

18. The system of claim 13, wherein :The generated ontology library is configured as a cloud-based Internet of Things application.

19. A processor-readable non-transitory storage medium comprising a plurality of instructions for managing data, wherein execution of the plurality of instructions by one or more hardware processors performs a plurality of actions, characterized in that: The actions include: defining an ontology model, wherein the ontology model specifies a plurality of ontology categories and a plurality of relationships between the plurality of ontology categories; autonomously generating an ontology library based on an ontology library template by an ontology library generator, wherein the ontology library abstracts the plurality of ontology categories and the plurality of relationships defined in the ontology model and configured to generate a plurality of ontology instances, wherein the generated ontology library includes a plurality of generated functions corresponding to one of the plurality of ontology categories within the ontology model; Deploying the ontology library to an Internet of Things system; generating an ontology instance based on the ontology library deployed to the IoT system, wherein the ontology instance is derived from an IoT application executed in the IoT system; Exposing an adaptation layer of the Internet of Things system through an ontology representation to provide information to a business intelligence layer; and The Internet of Things system using the generated ontology instance and the business intelligence layer is managed through the Internet of Things application.

Images