WO2021020356A1 - Data interpretation device, method and program, data integration device, method and program, and digital city construction system - Google Patents

Abstract

This data interpretation device is provided with a platform for automatically executing type conversion of an object. The platform is provided in a control unit of the data interpretation device, and includes a capture unit and an interpretation unit. The capture unit captures input data as platform objects. The interpretation unit performs interpretation by creating an initial graph with respect to the objects and automatically growing a graph starting from the initial graph while appropriately executing type conversion of the object associated with each node of the graph to the extension side or the intension side.

Description

Data interpreters, methods and programs, data integration devices, methods and programs, and digital city building systems

The present invention relates to a data interpretation device, a method and a program, a data integration device, a method and a program, and a digital city construction system.

In order to realize the advanced fusion of cyberspace and physical space, which is the premise of Society 5.0 of the Science and Technology Basic Plan, at a realistic cost, we will not only carry out new trials for new structures. It is indispensable to utilize materials such as design drawings that have been accumulated enormously for old infrastructure structures. However, since old materials are basically expressed so that they can be visually interpreted by humans, a huge cost is required to utilize them for wide-area and high-resolution simulations.

Since the 1980s, many studies have been conducted to automatically construct 3D models from design drawings (Non-Patent Document 1), but because they relied on a method of assembling drawing elements (lines and characters) from the bottom up. , There was a difficulty that it was not possible to deal with complicated drawings because the failure to interpret the part spread to the whole and the three-dimensionalization collapsed.

In recent years, the technology of importing drawings into a CAD system and semi-automatically making them three-dimensional has become the mainstream. However, the use of this technology requires engineers who have knowledge of both CAD systems and design drawings, and it still requires enormous costs to make a large number of structures three-dimensional.

Japanese Unexamined Patent Publication No. 2011-123644 Japanese Unexamined Patent Publication No. 04-2315142 Japanese Unexamined Patent Publication No. 04-030265 Japanese Unexamined Patent Publication No. 04-275684 Japanese Unexamined Patent Publication No. 2018-10997

Technology for automatically interpreting design drawings and automatically constructing 3D models has been developed for a long time, but it is difficult to completely extract information, and general-purpose and robust automatic construction of 3D models has been put into practical use. Absent. There is a need for a general-purpose methodology that can flexibly and robustly construct a 3D model even for the results of automatic interpretation of incomplete drawings. Further, the three-dimensional model is required to be usable for various purposes such as high-resolution numerical simulation.

Data that is basically expressed so that it can be visually interpreted by humans and that cannot be extracted by a computer as it is is called "unstructured data". For example, a 2D-CAD drawing is unstructured data and is composed of elements such as lines, curves, and character strings, but it does not necessarily mean that it is a "figure" or "table" that a collection of elements has. Is not explicitly described, and human beings visually interpret it as a "figure" or "table" and read the information. In addition to 2D-CAD drawings, unstructured data includes images with pixels as elements and point cloud data with points as elements. Further, in general, data that is not called unstructured data may be regarded as unstructured data when necessary information cannot be directly extracted. There is a need for a technique in which a computer automatically interprets the meaning of unstructured data based on the relationship between the element data and the element (including the positional relationship) and reads fragmentary information.

The figures and tables included in the 2D-CAD drawing represent fragmentary information of the object (for example, a certain structure) in the physical space to be represented in the 2D-CAD drawing, and represent the 2D-CAD drawing. It is neither the object itself (that is, the object in physical space) nor the model of the object of expression. Here, the "model" refers to a corresponding object in the virtual space to be expressed. Further, "fragmentary information" refers to information that is not always sufficient to create a model to be expressed and may be integrated with other information to create a model to be expressed. In order to create a model of an object (for example, a structure) at low cost, multiple and different types of data, from new data to old data (a type of data), are created according to individual purposes. It is required to utilize the data of the above, and a technology to create a model to be expressed by integrating fragmentary information distributed in a plurality of data is required.

In order to continuously improve the technology that utilizes data in response to the rapid increase in data called data explosion and the exponential improvement of computer performance that has continued for decades, the program is expensive. Reusability is required. However, in general, individually developed programs read and write data in a unique format optimized for each purpose, and for cooperation between programs, there are simply as many data conversion programs as there are combinations of programs. You will need it. This means that the cost of reuse is extremely low, and it is not feasible to continuously advance the technology with simple measures. It is common to deal with this problem by defining a standard expression format, but if the expression format is defined uniformly and fixedly, data providers and data users will have to devise their own data format. To limit. In addition, the technology becomes rigid because all programs depend on a fixed expression form.

In the present invention, in order to continuously advance the technology for utilizing data, both the data expressed in the standard and defined format and the data in the original format optimized for each purpose are simultaneously used. Provide a loosely coupled method that becomes available. It also provides data interpreters, methods and programs for extracting information from a wide range of data, from new data to old data. Further, a data integration device, a method, and a program for creating a model of a data expression target by integrating fragmentary information distributed in a plurality of data are provided. It also provides a digital city platform.

In the present disclosure, as an example of means for solving a problem, a method for robustly and automatically interpreting a two-dimensional design drawing and flexibly and automatically constructing a three-dimensional model having different degrees of detail according to the accuracy of the interpretation result. To present.

In the present application, not only the elements of the drawing are assembled bottom-up, but also the context of the figure is automatically specified to estimate the meaning suitable for the figure from the top down and information is obtained from the drawing according to the meaning. The supplementary drawing interpretation method is disclosed. Specifically, this is realized by automatically growing (automatically structuring) the tree structure in which the elements of the drawing are associated with the nodes, with the relationship between the whole and the part as a parent-child relationship.

This method is a robust method in which even if the interpretation fails, the tree structure does not grow, that is, the accuracy of the interpretation does not improve and the whole does not collapse. In this research, this automatic structuring method is also adopted for the automatic construction of 3D models. This makes it possible to flexibly and automatically construct 3D models having different degrees of detail according to the accuracy of drawing interpretation. In the 3D model automatically constructed by the method of this research, information is organized based on the relationship between the whole and the part, and not only the shape but also various information such as the internal structure and physical properties of the structure can be retained. Therefore, it can be expected to be applied to various purposes.

Further, in the present invention, an interpreter capable of object-oriented programming that executes automatic type conversion based on the extension / inclusion relationship between objects is constructed, and more detailed extension is appropriately applied when interpreting data and integrating data. Create the side object from the inclusion side object (downcast). In general object-oriented programming, downcasting that cannot be properly executed due to lack of information is possible with the method of the present invention.

That is, the present invention is as follows.
[1] A data interpretation device provided with a platform for automatically executing type conversion of an object. The platform is provided in a control unit of the data interpretation device, has an acquisition unit and an interpretation unit, and has the acquisition unit. The unit acquires the input data as an object of the platform; the interpreting unit creates an initial graph for the object and performs a type conversion of the object associated with each node of the graph to the extension side or the inclusion side. A data interpretation device that operates a control unit so as to perform interpretation by automatically growing a graph from the initial graph while executing as appropriate.
[2] The interpreting unit executes downcasting, which is a type conversion of the object to the extension side based on the extension / inclusion relationship between the objects, and displays the nodes associated with the downcast object in the graph. The data interpretation device according to [1], wherein the graph is automatically grown by adding the data.
[3] A data interpretation method using a platform that automatically executes type conversion of an object. The platform is provided in a control unit of a computer and has an acquisition unit and an interpretation unit. The step of acquiring input data as an object of the platform; the interpreter creates an initial graph for the object and appropriately performs type conversion of the object associated with each node of the graph to the extension side or the inclusion side. At the same time, a data interpretation method for executing the step of performing interpretation by automatically growing a graph from the initial graph.
[4] In a program executed by a computer, which is provided in a control unit of the computer, has an acquisition unit and an interpretation unit, and automatically executes type conversion of an object, the acquisition unit inputs input data. The step of acquiring as an object of the platform; the interpreter creates an initial graph for the object and appropriately performs type conversion of the object associated with each node of the graph to the extension side or the inclusion side. A program that operates a control unit to perform the step of interpreting by automatically growing a graph from an initial graph.
[5] A data integration device provided with a platform for automatically executing type conversion of an object. The platform is provided in a control unit, has an acquisition unit and an interpretation unit, and the acquisition unit receives input data. Acquired as an object of the platform; the interpreter creates an initial graph for the object and appropriately performs type conversion of the object associated with each node of the graph to the extension side or the inclusion side. A data integration device that operates a control unit so as to interpret by automatically growing a graph from an initial graph and construct integrated data that integrates one or more of the above objects.
[6] A data integration method using a platform that automatically executes type conversion of an object. The platform is provided in a control unit of a computer, has an acquisition unit and an interpretation unit, and the acquisition unit inputs. The step of acquiring data as an object of the platform; while the interpreter creates an initial graph for the object and appropriately performs type conversion of the object associated with each node of the graph to the extension side or the inclusion side. , A step of interpreting by automatically growing a graph from the initial graph and constructing integrated data in which one or more of the objects are integrated;
How to integrate data.
[7] In a platform that is a program executed by a computer, is provided in a control unit of the computer, has an acquisition unit and an interpretation unit, and automatically executes type conversion of an object, the acquisition unit inputs input data. The step of acquiring as an object of the platform; the initial graph is created for the object, and the type conversion of the object associated with each node of the graph to the extension side or the inclusion side is appropriately performed. A program that operates a computer control unit to perform an interpretation by automatically growing a graph from a graph and to construct integrated data that integrates one or more of the above objects.
[8] A platform that automatically converts the data representation format.
A plurality of programs having a predetermined element program and having inputs and outputs of arbitrary expression formats are loosely coupled via data by automatic conversion of the expression format, and the expression target of the integrated data is a city or a structure. There is a digital city building platform.

The present invention realizes a data processing platform which is an interpreter capable of expanding the application range of a program and improving the reusability of the program by automatically converting the representation format of the data based on the meaning of the data. be able to. The data processing platform can simultaneously use both the data expressed in the standard and defined format and the data in the unique format optimized for each purpose, and accumulates programs for utilizing the data. The technology can be continuously advanced.
In addition, a data processing platform can be used to implement data interpreters, methods and programs for extracting information from a wide range of data, from new data to old data.
Furthermore, using a data processing platform, it is possible to realize a data integration device, method, and program that integrates fragmentary information distributed in a plurality of data to create a model of a data expression target.

It is a figure which shows the physical structure of the data interpretation apparatus which concerns on Embodiment 1. FIG. A diagram schematically showing the conversion of data in the representation formats of "source 1", "source 2", and "source 3" into data in the representation formats of "target 1", "target 2", and "target 3". Is. It is schematically shown that "mediation data" is set as an intermediary for conversion from "source 1", "source 2", and "source 3" to "target 1", "target 2", and "target 3". It is a figure. It is a figure which shows another situation of the intermediary data by automatic data conversion. It is a figure which shows the example of the data automatic conversion in the interpreter of this invention. This is an example of a general pier structure diagram showing a pier structure composed of CAD data. It is a figure which shows the "title column" in the pier structure general drawing. It is a figure which shows the object (class name "LineBuf2D") which consists of a line in "pier structure general figure". It is a figure which shows that the object which is not a subclass "CellSet" was excluded from the object of a group of lines (class name "LineBuf2D"), and 6 objects were interpreted as "CellSet". It is a figure which shows that the character string extracted from CAD data is input to the object of the class "CellSet", and is interpreted into the class of "Table". It is a figure which analyzes and classifies whether the item of a "title block" exists in the object of a class "Table", and if it exists, it is interpreted as the object of the class "title block". It is a figure which shows that the object which is not a subclass "View" was excluded from the object (class name "LineBuf2D") of a group of lines, and eight objects were interpreted as "View". Of the eight class name View objects shown in FIG. 9, those that do not belong to the main structure (D-STR) layer are excluded, and the remaining seven cells are shown. For the object of class "View", enter the character string to be the title extracted from the CAD data, and the object with the item peculiar to "Pier front view" is the object whose class name is "Pier front view". It is a figure which shows that it is interpreted as being. It is a figure which shows how the projection plane of a structure is automatically created from the front view, the plan view, and the side view. It is a figure which shows how the 3D model is automatically created from the projection plane of a structure. It is a figure which shows that the "front view of a pier" included in a 2D-CAD drawing is recognized step by step. It is a figure which shows that the "substructure coordinate table" included in a 2D-CAD drawing is recognized step by step. In the data interpretation device and the data interpretation method according to the present disclosure, it is a figure which shows that the stage for 2D-CAD drawing recognition is hierarchized. In the present disclosure, it is a diagram showing that two main methods of recognizing a 2D-CAD drawing are set: (1) "input of information" and (2) "analysis / interpretation". It is a figure which shows the flow of the digital bridge automatic construction method. It is a figure which shows the initial tree structure for drawing interpretation. It is a figure which shows the growth example of the tree structure in the drawing interpretation. It is a figure which shows the automatic construction of a digital pier based on a 2D CAD drawing. It is a figure which shows the recognition process of a title column. It is a figure which shows the physical structure of the data integration apparatus which concerns on Embodiment 2. FIG. It is a figure which shows the implementation method of data processing in the case of developing individually. It is a figure which shows the implementation method of data processing when using a standard format. It is a figure which shows the implementation method of data processing when using automatic conversion. It is a figure which shows the star-shaped network centering on a standard representation form as an example of the topology of the network which a representation form and a transformation path make. It is a figure which shows the free network based on the automatic conversion of the expression form as an example of the topology of the network which the expression form and the conversion path make. It is a figure which shows the form of the fixed digital city by the standard form. It is a figure which shows the form of the digital city construction system which has development sustainability. It is a figure which shows the case of the one-term function φ of L1 as an example of automatic conversion of a representation form. This is an example of a script for interpreting the 2D-CAD drawing "006_P2 General diagram of pier structure.dxf".

Hereinafter, embodiments will be described in detail with reference to the drawings as appropriate. However, more detailed explanation than necessary may be omitted. For example, detailed explanations of already well-known matters and duplicate explanations for substantially the same configuration may be omitted. This is to avoid unnecessary redundancy of the following description and to facilitate the understanding of those skilled in the art.

It should be noted that the inventor does not intend to limit the subject matter described in the claims by those skilled in the art by providing the accompanying drawings and the following description in order to fully understand the present disclosure. Absent.

1. 1. Research on data processing platform Introduction, regarding the data processing platform (DPP), "1.1. Purpose and content of research", "1.2. Significance and importance of automatic conversion of data expression format" Sections of "Gender", "1.3. Definition of Logical Equivalence between Data", "1.4. Requirements and Implementation of DPP", and "1.5. Conclusions to the Developed Theory and Implementation" ( These sections will be described below in "Disclosures Related to this Research and Ideas"). The data processing platform relates to the research of the present inventor and functions as an interpreter for constructing a digital city.

1.1. Purpose and content of the research 1.1.1. The Need for Digital Cities Attempts to quantify the damage caused by earthquakes and tsunamis to cities with supercomputers are progressing to interdisciplinary research such as assessing the impact on transportation and the economy. It is expected that the resulting programs will be used together with high-performance computers and will be useful for comprehensive disaster prevention. However, even with computers and programs, it cannot be applied to actual cities without a digital city that serves as a place to simulate disasters.

1.1.2. Digital Cities Requirements What should a digital city look like? At the very least, it must be possible to freely extract the information necessary for quantifying damage. In addition, in the midst of "data explosions" and "exponential improvements in computer performance," it is not a fixed thing that quickly becomes obsolete, but it flexibly responds to new data and new programs and continuously develops. It should be possible.

1.1.3. Difficulties in building a digital city: Heterogeneity The challenge of building a digital city is to balance the ability to freely extract information from a wide variety of data and to enable the continuous development of a digital city. It's not easy. Conventionally, in order to freely extract information, measures have been taken to standardize and unify the data expression format, but the expression format is fixed. Moreover, as a matter of fact, the data is recorded in the optimum expression format according to the purpose at the time of creation, and the expression format of the existing data is not unified.

1.1.4. Building a digital city, difficult to predict with traditional methods Nevertheless, it is possible to build a digital city with the necessary standardization for the immediate purpose. However, this method is inefficient because it requires the development of digital cities and programs for their construction from the initial stage every time the purpose changes, and the complexity of digital cities cannot withstand redevelopment. At that time, it is expected that the development of digital urban construction technology will reach a plateau.

1.1.5. Purpose Originally, unlike the standardized shapes of machine parts, the data representation format can be flexibly changed as long as the meaning and content of the data are the same, and the program assumes a specific representation format as input. However, if there is a mechanism to automatically change the expression format, it can be applied to data expressed in a different format. For example, when a program that calculates the distance between two points on a two-dimensional plane expressed in a Cartesian coordinate system is given a point expressed in another coordinate system such as a polar coordinate system, the coordinate system is automatically set. By performing the conversion, one program can be commonly used for a plurality of expression formats. If this mechanism can be realized universally, it will be possible to easily create an information extraction program that does not depend on the expression format, and it will be easy to replace data and programs.

In the disclosure related to this research and devise, an interpreter (this is called a data processing platform (DPP)) having a mechanism for automatically converting the expression format is constructed, and element programs for constructing a digital city are accumulated as its library. I suggest that. "Platform" refers to a platform that functions as a foundation for aggregating and linking elemental programs. As for the "data processing platform (DPP)" disclosed in the present specification, the term "platform" also means that DPP functions as a basis for aggregating and linking elemental programs.

In a system consisting of DPP and its library, it is possible to incorporate new data and new programs by simply adding or replacing programs, and the sophistication of the system corresponds to the sophistication of digital cities. In addition, in the disclosure related to this research and the invention, in order to realize this system, the purpose is to define the logical equivalence between data with different expression formats and to present an automatic conversion method of the expression format according to the definition. ..

1.1.6. Contents The contents of the disclosure related to this research and the device are summarized as follows. The significance and importance of automatic conversion of data representation formats in the construction of digital cities is emphasized in "1.2.", And the theory for the conversion, especially the logical equivalence between data, is described in "1." This will be explained in "3.3." Then, the implementation corresponding to the theory will be described in "1.4.". In "1.5.", The conclusions for the developed theory and implementation are stated.

1.2. Significance and importance of automatic conversion of data representation format 1.2.1. Purpose of this section This section "1.2." Explains the variety of representation formats of data that are the material of digital cities and the challenges in using them. In addition, it will be explained that by automatically converting the data representation format based on the meaning of the data, the applicable range of the program, which is usually limited by the data representation format, is expanded and the reusability of the program is improved. Then, it will be explained that the system for automatically constructing a digital city can be realized as a loosely coupled system in which element programs can be flexibly added and changed by improving the reusability.

1.2.2. Diversity of data representation format and issues of use 1.2.2.1. Ingenuity for expression formats in each field The data used as materials for digital cities are usually data created individually for some specific purpose, and the expression formats are devised according to the purpose and usage. There is.

For example, in general, data sharing is performed in a format defined by a standardization mechanism, and data is often in text format that can be read by humans, but in high-performance computing, binary format is usually adopted and the entire data can be read and written at high speed. The same kind of data is often arranged in a row. In addition, when searching for data to be stored for a long period of time, access to a part of the data is normal, and a data structure based on the meaning and content of the search target can be selected. Even if the data has the same meaning and content, various expression formats are defined and used by the calculation subject and the data management subject according to various processing purposes.

1.2.2.2. Difficulties in building a digital city 1: Combinatorial explosion in program development (Fig. 23A)
The construction and utilization of a digital city can be regarded as a systematic application of a process that takes multiple data as inputs and outputs target data, and each process is characterized by input data and output data. In general, even for processes with the same meaning and content, it is necessary to implement different programs if the data expression format is different, and the variety of expression formats may significantly reduce development efficiency. For example, even for a simple process of outputting the distance between two objects, it is necessary to implement each combination of input data expression formats as shown in FIG. 23A, and a combinatorial explosion easily occurs.

23A to 23C are diagrams showing three types of data processing implementation methods. Arrows represent conversions of data representation. FIG. 23A is a case of individually developing, FIG. 23B is a case of using a standard format, and FIG. 23C is a case of using automatic conversion. In FIG 23A ~ FIG _{23C, F (X i, Y} j) is to input data _{y j} of data _{x i} and representation _{Y j} of representation _{X i,} represents the function for performing predetermined data processing There is. Further, if i ≠ i', the expression formats of X _i and X _i'are different, and similarly, if j ≠ j', the expression formats of Y _j and Y _j'are different.

1.2.2.3. Difficulty in building a digital city 2: Problem of standard format If the representation format of the data to be used is unified and the processing program is implemented only for the standard representation format as shown in Fig. 23B, similar implementation is repeated. You can avoid that. However, this methodology is not feasible, especially in the field of high performance computing, because it hinders the design and use of expression formats suitable for the purpose. This is because programs developed in the field of high-performance computing often input data in a representation format originally designed by the developer for the purpose of improving computing performance. It goes without saying that the standardization mechanism defines a standard expression format, but in order to apply numerical simulations that apply high-performance programs developed in the field of high-performance computing to digital cities, a wide variety of expressions are used. There is a need for a new methodology for linking data and programs that can handle format data.

1.2.3. Reuse of processing programs by automatic data conversion 1.2.3.1. Reuse of processing programs by automatic conversion (including route search)
As shown in FIG. 23C, it is possible to expand the application range of the program and improve the reusability of the program by automatically converting the representation format of the data based on the meaning of the data. Normally, the scope of application of the program depends on the data representation format, but a conversion path that preserves the meaning and content of the data is defined in advance between the representation formats, and a function that automatically searches for a route that follows this conversion path is implemented. If this is done, the scope of application of the program will be expanded to depend on the meaning and content. In addition, by appropriately defining the route search method, it is possible to select and execute the optimum one from the implementations of a plurality of processing programs.

1.2.3.2. Mediation data / standard relativization As shown in FIG. 24, a network in which the expression format is a node and the conversion path is a link can be considered. Here, FIG. 24 is the topology of the network created by the expression format and the conversion path. FIG. 24A is a star-shaped network centered on a standard representation format, and FIG. 24B is a free network based on automatic conversion of the representation format.

The methodology based on the standard representation format limits the topology of this network to a star shape centered on the standard representation format, as shown in FIG. 24A, and the standard representation format is an intermediate between data and the program. Plays the role of data format. On the other hand, in the methodology based on the automatic conversion of the representation format, the topology configuration of the network is free, and the position where the data and the program are combined is also free (see FIG. 24B). In addition, data that is not directly combined with the program is also automatically combined indirectly by automatic conversion, so that the data and the program can be easily exchanged. And this network can grow by adding new expression formats and processing programs. A star-shaped topology can be constructed as a result of network growth, but the centrally located representation is natural, bottom-up, unlike the standard representation defined in a top-down fashion. It is a de facto standard expression format that is determined by.

1.2.3.3. Reducing the burden on data users In recent years, many open data useful as materials for digital cities have been released and shared through clearing houses. However, there are a wide variety of open data representation formats, and when application program developers combine multiple data, they often understand the representation format of each data and extract information from the data. You need to start by developing a program to do. If there is a system that realizes a methodology based on automatic conversion of expression formats and information extraction programs can be shared, open data and already-developed processing programs will be automatically combined, facilitating the development of application programs. In addition, the system can handle the data without being aware of the non-essential details of the data, that is, the implementation specific to a specific expression format, so that the learning burden on the data user is reduced.

1.2.3.4. Improving reusability by wrapping processing programs While automatic conversion of representations hides the details of data implementation, another mechanism that enhances program reusability is the application programming interface (API), which implements programs. Hide the details of. Providing city information by Web API is expected to reduce the development cost of application programs when sharing the above-mentioned information extraction program. For this reason, various information on cities has already been provided as a Web API, and the number is expected to increase in the future, but this situation is similar to the increase in useful data in its own format. .. Since the function of an application program equipped with an API is characterized by the representation format of input and output data, it is possible to apply automatic conversion of the representation format. In this case, the input data expresses the instruction to the API.

1.2.4. Digital city construction system 1.2.4.1. Definition of Digital Cities The structures that are the constituents of cities have a long service life, while research and development progresses rapidly. For this reason, it is expected that data generated at each stage of design, construction, and maintenance will be accumulated and used for multiple purposes by applying the technology developed later. In fact, a huge amount of data is stored in existing structures, and effective utilization of that data is being promoted. For example, damage estimation of earthquakes and tsunamis using numerical simulation is one example. In order to carry out a numerical simulation, it is necessary to represent a model of a city with a certain degree of detail on a computer, and the model extracts city information as fragments from multiple data and of the actual city. It is constructed by integrating into data that expresses knowledge about the components. In the disclosure of this research and devise, this model of the city as integrated knowledge is defined as a digital city. Digital cities are used as a source of information for creating desired data, such as input data for numerical simulations.

1.2.4.2. Digital City Based on Standard Format The simple form of construction and utilization of a digital city is expressed in that format from the material data by defining a standard format that can express all the components of the city, as shown in Fig. 25A. It is to create the desired data and apply the implemented program to the standard format data to create the desired data. However, as mentioned above, the methodology for linking data and programs based on this form cannot correspond to various actual expression forms. Moreover, since all programs depend on the standard format, it takes a lot of labor to change the standard format. The task of manually converting existing old standard format data to match the new standard format is enormous. As a result, the numerical representation of cities is fixed and impedes technological development.

1.2.4.3. Digital city construction system In the disclosure related to this research and devise, as a form of construction and use of a digital city, as shown in Fig. 25B, digital is based on DPP, which is an original interpreter with a mechanism to automatically convert the expression format. We propose to develop a digital city construction system that accumulates elemental programs for building a city, and to use the material data and target data of the digital city as their inputs and outputs, respectively. In this system, programs are connected via data, and the connection between data and programs depends on the meaning and content, not on the data representation format. This means that if the meaning and content are the same, the combination can be flexibly changed regardless of the difference in expression format. It is extremely important for the development of digital city construction technology to adopt a design that avoids duplicate development and prevents the technology from peaking by using a loosely coupled system that can flexibly add and change element programs. ..

1.3. Definition of logical equivalence between data The fact that two data represented in different formats are equivalent means that one data can be replaced by another data represented in a different format. Is. If there is no clear definition of the conditions for the two data to be correctly replaceable, meanings and contents different from the original can be extracted from the replaced data. In this section "1.3.", Predicate logic is used to define the logical equivalence between data with different representation formats so that logically correct replacement is always possible.

13.1. Extension / inclusion relationship between data representations In order to define the logical equivalence between data representations, which is the basis for automatically converting the representation format of data, consider the predicate logic L1 with the set of the entire data representation as the universe of discourse D1. .. Here, each representation format of the data corresponds to the one-argument predicate of L1, and the subset of D1 in which the value of the one-argument predicate is true is the whole data representation that can be represented in that format. The logical equivalence of two data representations is defined as the fact that the binary predicate ⇒ of L1 representing the extension / inclusion relationship between the data representations that are the elements of D1 holds in both directions. The term "subordinate concept" is used instead of the term "extension", the term "superordinate concept" is used instead of the term "inclusion", and the term "superordinate concept / subordinate concept relationship" is used instead of the term "extension / inclusion relationship". May be used respectively.

The second argument ⇒ is defined as satisfying the following reflection law and transition law. However, → is a logical symbol.

∀x (x ⇒ x)
∀x∀y∀z ((x ⇒ y) && (y ⇒ z) → (x ⇒ z))
From now on, it is assumed that x ⇒ y holds, that x has y as an intension, or y has x as an extension. In addition, the two-argument predicate ⇔ is defined as follows,
∀x∀y ((x ⇔ y) ← → ((x ⇒ y) && (y ⇒ x)))
When x⇔y holds, we define x and y as equivalent.

Then, the n-term function φ of L1 and the n-term predicate ψ are called regular when the following two conditions are satisfied.

∀x∀y ((x ⇒ y) → (φ (…, x,…) ⇒ φ (…, y,…))) (Equation 1)
∀x∀y ((x ⇒ y) → (ψ (…, y,…) → ψ (…, x,…))) (Equation 2)
For example, if x and y are log house and house data representations, respectively, and Roof (a) is a holomorphic function that associates a with the roof data representation of a, then from the first equation, (x ⇒ y ) → (Roof (x) ⇒ Roof (y)) holds. This means, "If the log house is a house, the roof of the log house is the roof of the house." Also, if HasRoof (a) is a regular one-argument predicate that expresses the attribute "a has a roof", then from the second equation (x ⇒ y) → (HasRoof (y) → HasRoof (x)) It holds. This means, "If the log house is a house, if the house has a roof, then the log house also has a roof."

The identity function is a holomorphic function, and the predicate that always returns true and the predicate that always returns false are regular predicates. On the other hand, in general, it is not possible to determine which function / predicate is a holomorphic function / regular predicate simply by imposing the establishment of the reflex law and the transition law on the extension / intensional relationship between data expressions, and between two data expressions. It is also uncertain whether or not there is an extension / inclusion relationship. In the disclosure related to this research and devise, only the basic holomorphic functions and holomorphic predicates are defined first, and then the holomorphic functions and holomorphic predicates are sequentially defined. If Holomorphic functions and holomorphic predicates satisfy Equations 1 and 2, we define that the two data representations are in an extension / inclusion relationship. This means that the meaning of the object is given by the definition of the holomorphic function and the regular predicate. The purpose of the disclosure of this study is to abstract non-essential differences between representations, and by defining functions and predicates whose values can be determined regardless of representations as holomorphic functions and holomorphic predicates. Determine the extension / inclusion relationship between data representations.

As an example, consider Cartesian2D, which expresses points on a two-dimensional plane in a Cartesian coordinate system, and Polar2D, which expresses points on a two-dimensional plane in a polar coordinate system. The data representation of Cartesian2D is a set of x-coordinate and y-coordinate (x, y), and the data representation of Polar2D is a set of radial diameter r and argument θ (r, θ). The position of a point on a two-dimensional plane can be measured in x and y coordinates with respect to a given Cartesian coordinate system, regardless of the data representation. For example, when the Cartesian coordinate system and the polar coordinate system are related to x = r cosθ, y = r sinθ, for the Polar2D data representation (r, θ), the x and y coordinates are calculated from this relational expression. It can be measured. Here, if the x-coordinate and y-coordinate surveys are defined as regular functions that correspond the data representation of the real number representation format Real to the points on the two-dimensional plane, the Polar2D data representation is an extension of the Cartesian2D data representation. In some cases, from Equation 1, the x-coordinate and y-coordinate survey results for the two data representations are equivalent, that is, the two data representations represent the same point.

For another example, consider the expression format Cartesian2D_RGB, which expresses colored points on a two-dimensional plane with a set of x-coordinates, y-coordinates, and RGB values (x, y, r, g, b). The x-coordinate and y-coordinate surveys are also possible for the Cartesian2D_RGB data representation, and if the Cartesian2D_RGB data representation is an extension of the Cartesian2D data representation, x for the two data representations, as in the previous example. The measurement results of the coordinates and the y-coordinate are the same, and the two data representations represent the same point.

1.3.2. Extension / inclusion relations between expression formats In the previous measure "13.1.", Extension / inclusion relations between data representations were defined. In this measure, we introduce the predicate logic L2 in which the set of the entire one-argument predicate of L1 is the domain of discourse D2, and reconsider the extension / intensional relationship as the relationship between the one-argument predicates of L1. This means that the extension / inclusion relationship between data is grasped as the relationship between symbols with the one-term predicate name as the referent and each data expression as the referent, and the nature of the data and the data expression method are treated separately. Make it possible. Specifically, when recording certain information as data, the properties of the data are first discussed in L2, and then the specific representation method of the data is determined so that it has the properties expressed in L2. It is possible to do.

The fact that the one-argument predicates A and B of L1 have an extension / inclusion relationship in L2 is defined as the fact that A and B satisfy the following relational expression in L1.

∀x (A (x) → ∃y (B (y) && (x ⇒ y))) (Equation 3)
From this equation, it can be immediately said that the reflection law and the transition law are established for the extension / intensional relationship in L2 as well as in L1. Also, considering two special one-argument predicates T and F of L1 that satisfy the conditions ∀x (T (x)) and ∀x (￢F (x)), respectively, T extends all one-argument predicates. Mochi, F has all one-argument predicates inclusive.

For each data representation of L1, it is possible to think of a one-argument predicate of L1 whose value is true only for that data representation, and that one-argument predicate is the source of D2. In the disclosure related to this research and the invention, for the sake of simplicity, when the data representation of L1 is written as a, the element of D2 corresponding to this data representation a is also written as a. However, the data representation is written in lowercase to distinguish it from the data representation format in uppercase. According to Equation 3, when a certain data expression a, b has a relationship of a⇒b in L1, the relationship of a⇒b is also established in L2. Further, between a certain expression format A and its data expression a, from Equation 3, a ⇒ A is established in L2.

Under the definition of Equation 3, the holomorphic function / predicate of L1 can be extended to the holomorphic function / predicate of L2 as follows. First, the value of the n-term holomorphic function φ in L2 is the one-term predicate of L1, and the subset of D1 corresponding to the one-term predicate is the subset of the function φ in L2, that is, the one-term predicate of L1. It is defined as the set of all values of the function φ in L1 calculated for the original set of all true L1s. Also, the correspondence of L1 to any original set of L1 for which each argument of the predicate, that is, the one-term predicate of L1, is true that the value of the n-term regular predicate ψ in L2 is true. It is defined that the value of the predicate ψ is true. At this time, for the extended holomorphic function / predicate of L1, the equations 4 and 5 corresponding to the equations 1 and 2 in L1 also hold in L2.

∀A∀B ((A ⇒ B) → (φ (…, A,…) ⇒ φ (…, B,…))) (Equation 4)
∀A∀B ((A ⇒ B) → (ψ (…, B,…) → ψ (…, A,…))) (Equation 5)

The relationship between a certain expression format and its data expression corresponds to the relationship between a class and an instance in object-oriented programming, and the extension / inclusion relationship corresponds to an inheritance relationship. From this point of view, the specialization of Equation 5 into an expression for one-argument predicates corresponds to the Liskov Substitution Principle in object-oriented programming. However, in the disclosure related to this research and the device, "class" and "data type" (also simply referred to as "type") are synonymous.

When defining an expression format that expresses a truth value as data, it is important that the predicate can be defined as a function. This indicates that data can be represented only by holomorphic functions without using holomorphic predicates. In addition, multi-valued logic can be expressed depending on how the truth value is defined. For this reason, we will focus on holomorphic functions in the following discussions.

When A ⇒ B in L2, ∀x (A (x) → (B (B <A> (x)) && (x ⇒ B <A> (x))) in L1)
There is at least one map B <A> from A to B that satisfies the condition, and this map B <A> is called an automatic conversion map. When the automatic conversion mapping is implemented, it is possible to automatically convert the representation format of the data. The elements of the autotransformation map and D2 are considered to correspond to the morphism and object in category theory, and the one-term holomorphic function is considered to correspond to the covariant functor.

1.4. Requirements and implementation of DPP This section "1.4." Explains the requirements and implementation of DPP, and the extension / inclusion relationship between data defined in the previous section "1.3. Definition of logical equivalence between data". Based on the above, a method will be described in which DPP automatically converts the data representation format as needed (that is, automatically executes type conversion) and applies it to a pre-registered processing program.

1.4.1. Differences in characteristics between data processing platforms and general object-oriented programming The differences in characteristics between data processing platforms and general object-oriented programming are shown below.

As shown in Table 1, the DPP according to the present disclosure is based on a concept different from general object-oriented programming. In general object-oriented programming, sharing of data structures is a condition in the definition of inheritance relationships. In contrast, DPP does not require sharing of data structures in the definition of inheritance relationships. Instead, the extension / intensional relationship is a condition for establishing the inheritance relationship between classes.

In DPP, users can define inheritance relationships between classes without being restricted by sharing data structures. There is no limit to the number of automatic (implicit) type conversions, the optimal route for type conversion is automatically searched, and the required number of conversions are automatically executed along the searched route. In DPP type conversion, in addition to logically equivalent type conversion (called equivalence cast), type conversion to the extension side (called downcast) and type conversion to the comprehension side (called upcast) Both are automatically executed. However, downcast is executed only when the condition that can be converted to the conversion destination type is defined for each object and the definition is satisfied.

The present inventor described DPP that functions as an interpreter in C ++. As a matter of course, a person skilled in the art can create a similar interpreter in accordance with the description of the present specification, and the data processing platform of the present disclosure implemented by such an interpreter, and an apparatus provided with such an interpreter. , Methods, programs are also included within the scope of the present invention.

The language for describing DPP is not limited to C ++, and may be described in any other language as long as it meets the same requirements as those described in this specification and can be implemented in the same manner. ..

1.4.2. Requirements and Implementation The digital city construction system in the disclosure related to this research and devise is based on the interpreter (DPP) disclosed in the present invention, which has a mechanism for automatically converting the expression format, and a group of element programs for constructing a digital city is accumulated. It is composed of materials, and a digital city is constructed from material data to create the desired data. In implementing this DPP, the following three points are considered as requirements.
(Requirement 1) Provide an interface for instructing the digital city construction system to process.
(Requirement 2) To function as a wrapper for an existing processing program.
(Requirement 3) The processing program can be stored as a library that can be individually developed.

As mentioned in the previous section "1.3.", The relationship between a certain expression format and its data expression corresponds to the relationship between the class and the instance in object-oriented programming, and the extension / inclusion relationship corresponds to the inheritance relationship. According to this correspondence, the user of the digital city construction system will instruct the DPP to process using a kind of object-oriented language. The details of the implementation will be described later, but unlike usual, the language understood by DPP does not need to share the data structure between the inherited classes, and the data structure of each class can be freely designed. In addition, when the function is applied, route search that follows the inheritance relationship and automatic type conversion are performed as needed.

When incorporating an already developed program into DPP, it is inefficient to reimplement the functions of the old program in the new language. In DPP, C ++ language classes and functions are implemented so that they can be handled by wrapping them as DPP classes and functions. This allows DPP to loosely couple the developed data and programs with the disclosure methodology of this study and device.

In DPP, class definitions and processing programs related to the classes are compiled individually and implemented so that they can be put together in a dynamic library. The library is loaded as needed, and the conversion path is searched and automatic conversion is executed according to the inheritance relationship defined in the library. DPP users can freely extend the system by loading their own expression formats and processing programs into a library.

14.3. Implementation of automatic conversion and application method of processing program It is possible to convert the expression format by following the automatic conversion map defined between the expression formats as the conversion path. Although it is possible to convert various routes, it should be noted that, in general, when certain data are converted by different routes, the data representation is not always equivalent. In order for the results of data conversion to be equivalent regardless of the route, the following conditions should be satisfied when the expression format of the conversion destination is L1.

∀x∀y ((A (x) && A (y)) → (∃k ((k ⇒ x) && (k ⇒ y)) → (x ⇒ y)))
An expression format that satisfies this condition is defined as granular. When converting to a non-granular representation format, unnecessary information loss may occur depending on the definition of the automatic conversion map. Many of the existing representations of material data in digital cities are granular, but some may not. Therefore, while implementing the automatic conversion function of the expression format in DPP in consideration of the non-granular expression format, it is appropriate to implement the DPP class in principle.

The DPP class implements the object of the predicate logic L2 defined in the previous section "1.3.", That is, the one-argument predicate of L1, and has internal data in addition to the case where it is a data representation format. May represent no simple attributes. Here, "attribute" refers to a one-argument predicate of L1 that is not a data representation form. The automatic conversion map from the expression format to the attribute is an identity map. Attributes are generally not granular because they are defined across different forms of expression. DPP can also define an ontology description language if it handles only attributes and properly implements holomorphic functions that express the properties of attributes as a concept.

Even if an extension / inclusion relationship is established between the two expression formats, automatic conversion of the expression formats cannot be performed unless a conversion path connecting the two expression formats is prepared. To prevent the user from misunderstanding whether or not automatic conversion is possible, DPP recognizes that the extension / inclusion relationship is established only when the automatic conversion mapping is implemented. At first glance, this is contrary to the theory that the extension / intensional relationship is determined by the definitions of holomorphic functions and regular predicates, but no inconvenience occurs. In fact, the program developer clearly distinguishes between the theoretical definition and the implementation definition so that the extension / comprehension relationship is recognized in the implementation only when the extension / comprehension relationship is theoretically established. By doing so, it is possible to prevent the false recognition that the extension / inclusion relationship is not theoretical but practical.

In a network where the expression format is a node and the automatic conversion mapping is a link, the automatic conversion of the expression format is implemented so that the route that minimizes the cost can be searched and executed. As an example, the automatic conversion of the representation format is executed by searching for the path having the lowest cost based on the Dijkstra method, and the cost is set to 0 when the automatic conversion map is an identity map, and in other cases. Can be 1, but is not limited to this. In addition, in order to improve the efficiency of route search, nodes and links that do not reach the target are eliminated in advance based on the extension / inclusion relationship.

FIG. 26 shows an example of automatic conversion of the expression format based on Equation 4 in the case of the one-term function φ of L1. For φ, a processing program can be implemented for each input representation format, but when the holomorphic function φ <B> with B as the domain is implemented, if A⇒B in DPP, the automatic conversion map B <A> is defined, and φ <B> (B <A> (a)) can be calculated for any data representation of A. It can be seen that the domain of φ <B> is expanded to include A by the automatic conversion of the expression format. On the other hand, if the function φ <A> is implemented, it is φ <A> (a) ⇒ φ <B> (B <A> (a)) from Equation 4. It is possible to calculate φ (a) in two ways, but it is more appropriate to apply the function and then drop the information as needed than to drop the information by automatic conversion and then apply the function. DPP adopts the latter calculation method when φ <A> is defined. This is also the case for general n-term functions, and the method of selecting this implemented function is similar to polymorphism in general object-oriented programming.

1.5. Conclusion on the developed theory and implementation By clearly defining the conditions for equality of two data expressed in different formats and implementing based on that definition, a logical error occurs in the data representation format. It has succeeded in automatic conversion without letting it. By accumulating elemental programs for building digital cities based on DPP, it is considered possible to develop digital city building technology efficiently and continuously.

Data in the new expression format, which is an extension of the old expression format, can be converted to the old expression format under specific conditions, and the old program may be utilized. From the viewpoint of improving the reusability of programs, a flexible data conversion technology is required in which the possibility of automatic conversion is determined depending on the individual data contents. For this reason, DPP further expands the scope of application of the function by checking whether the data expressed in a certain format satisfies a specific condition and executing automatic conversion if the condition is satisfied.

2. Purpose in the Embodiment In the following, the present disclosure relating to the embodiment of the invention includes data expressed in a standard and defined format in order to continuously advance the technology for utilizing the data. It is an object of the present invention to provide a loosely coupled method in which both uniquely formatted data optimized for individual purposes are available at the same time. That is, in this disclosure, instead of standardization that expresses data in a uniform format, loose coupling is realized by abstracting data based on automatic data conversion in the representation format, and heterogeneous data and heterogeneous programs are flexibly linked. The purpose is to provide a method.
Another object of the present invention is to provide a data interpretation method for extracting information from a wide range of data from new data to old materials using such a loosely coupled method.
Furthermore, it is an object of the present disclosure to provide a data integration method that uses such a loosely coupled method to integrate fragmentary information dispersed in a plurality of data to create a model of a data expression target. And.

3. 3. Platforms and Objects for Data Processing In order to achieve the above objectives, the present inventor used the platforms for data processing and the platforms described in "1. Research on Data Processing Platforms". We have come up with the idea of objects that are defined and constructed based on them. In the present disclosure, the platform (functioning as an interpreter) invented by the inventor is referred to as a data processing platform (DPP). Further, an object defined and constructed based on DPP is simply referred to as an object. The characteristics of DPP and objects by the present inventor will be organized and described below.

In order to convert data in one format to data in another desired format, a unique conversion program is usually required. For example, as shown in FIG. 2A, "source 1", "source 2", "source 3" ... "source M" expression format data (that is, M types of expression format data) is targeted. 1 ”,“ Target 2 ”,“ Target 3 ”... It is assumed that the data is converted into data in the expression format of“ Target N ”. In this case, M × N ways (specifically, 3 × 3 = 9 ways in FIG. 2A) conversion programs are required.

Here, as shown in FIG. 2B, the setting of "mediation data" is introduced. That is, conversion from "source 1", "source 2", "source 3" ... "source M" to "target 1", "target 2", "target 3" ... "target N" Suppose that "mediation data" is set as an intermediary. In this case, the conversion program can be converted in M + N ways (3 + 3 = 6 ways in FIG. 2B). That is, it decreases from "M × N street" to "M + N street".

However, in the "mediation data" shown in FIG. 2B, all the components (conversion program, data) depend on the "mediation data" shown in FIG. 2B, and the standardized data "mediation data" is changed. If so, it will be necessary to redevelop the conversion program according to M + N.

Therefore, the inventor of the present disclosure has devised a DPP that performs automatic data conversion as described above.

DPP introduces and defines an object in which type conversion is automatically executed by the optimum conversion path, unlike objects in general object-oriented programming. The inheritance relationship of classes in an object is defined as follows (Condition 1) to (Condition 3).

(Condition 1) The inheritance relationship satisfies the reflection law and the transition law.

(Condition 2) An inheritance relationship between classes is recognized when an extension / inclusion relationship is established.
For example, the first object belongs to the first class with (x, y) coordinates, the second object belongs to the second class with (r, θ) coordinates (polar coordinates), and the first class is Suppose that it is a subclass of the first superclass. If these classes are defined by C ++, there is no inheritance relationship between the first superclass and the second class because of the principle that inheritance relationships cannot be established unless the coordinate representations are the same. On the other hand, when these classes are defined by the DPP that defines the object, inheritance will occur if the extension / inclusion relationship is established, so inheritance between the first superclass and the second class. There will be a relationship.

(Condition 3) Polymorphism based on inheritance relationships between classes with different internal structures is realized by executing automatic route search and automatic data conversion that follow the conversion process defined between the classes.

The above-mentioned "extension / inclusion relationship" corresponds to the "is-a relationship" in object-oriented programming. Further, here, the establishment of the extension / inclusion relationship is described in the above-mentioned "1.3. Definition of logical equivalence between data".

In DPP, all data is treated as an object.

FIG. 3A is a diagram showing another situation of mediation data by automatic data conversion. The data in FIG. 3A, that is, "source 1", "source 2", "source 3", "mediation data 1", "mediation data 2", "mediation data 3", "target 1", "target 2", "Target 3" is all objectified. Each name is a class name (model name).

In FIG. 3A, first, "mediation data 1" is set as an intermediary for conversion from "source 1" and "source 2" to "target 1" and "target 2", and from "source 3" to "source 3". It is assumed that "mediation data 3" is set as an intermediary for conversion to "target 3". Further, it is assumed that the class "mediation data 2" is set between the "mediation data 1" and the "mediation data 3". In this case, for example, conversion from "source 1" and "source 2" to "target 3" can be newly realized via "mediation data 1", "mediation data 2", and "mediation data 3". .. Similarly, the conversion from "source 3" to "target 1" and "target 2" can be newly realized via "mediation data 3", "mediation data 2", and "mediation data 1".

Here, the relationship between "mediation data 1" and "mediation data 2" is an equivalent relationship, and "mediation data 3" is an extension of "mediation data 2". In order to change or extend the mediation data with the old components available, two conversions between "mediation data 1" and "mediation data 2" need to be considered, and "mediation". Two types of conversion may be considered between "data 2" and "mediation data 3". This means that M + N redevelopment will be streamlined to two conversion developments.

In the DPP of the present disclosure, the arrows between the data that are classes (for example, the arrows from the source 1 to the target 1 between the source 1 and the target 1) indicate the inheritance relationship. The class is defined. In the case of source 1 and target 1, as indicated by the arrow, "source 1" is a subclass and "target 1" is a superclass.

Furthermore, DPP can also build an interpreter for automatic data conversion. FIG. 3B is a diagram showing an operation example of the interpreter. First, "mediation data 1" is set as an intermediary for conversion from "source 1" to "target 1", and from "source 2" and "source 3" to "target 2" and "target 3". It is assumed that "mediation data 2" is set as an intermediary for the conversion of, and that there is no mediation for conversion from "source 3" to "target 3". Further, it is assumed that mutual conversion is set between "mediation data 1" and "mediation data 2". In this case, the interpreter plays a role of hiding the complicated processing of the portion G surrounded by the "processing Generate" from the user.

The interpreter internally generates intermediary data as needed and then performs automatic data conversion. For example, consider the conversion from "source 3" to "target 1" in the case shown in FIG. 3B. At this time, a route of "source 3"-> "mediation data 2"-> "mediation data 1"-> "target 1" can be assumed. The interpreter grasps the conversion relationship (that is, inheritance relationship) of each class, and generates necessary mediation data based on the conversion relationship from the actual "source 3" to the "target 1".

The interpreter is configured to assume multiple transformation paths and calculate the cost of the transformation (eg, the number of times the transformation (inheritance) indicated by the arrow is used) for each before the actual transformation. .. For example, consider the conversion from "source 3" to "target 3" in the case shown in FIG. 3B. At this time, the route "source 3"-> "mediation data 2"-> "target 3" or "source 3"-> "mediation data 2"-> "mediation data 1"-> "mediation data 2"-> The route "mediation data 1"-> "target 3" is not unthinkable, but it is clear that the route "source 3"-> "target 3" is the fastest and most efficient. In this way, the interpreter automatically determines the conversion path, which is as efficient and fast as possible.

3.1. Differences in characteristics between DPP and general object-oriented programming The differences in characteristics between DPP and general object-oriented programming are as shown in the above table.

Here, "the expression format is different" will be explained. "Text format" and "binary format" are examples in which the expression formats are different.

Furthermore, for example, if it is image data, there are innumerable expression formats such as png, jpeg, bmp, tif, if it is video data, avi, mpeg, mov, wmv, etc., and if they are different, The expression format is different.

Also, even though it is a text format, it depends on the line feed code.
-There are differences in the expression format in which the line feed code is LF, the expression format in which the line feed code is CR + LF, and the expression format in which the line feed code is CR.

Speaking of C ++ language classes, the following classes A and B have different expression formats because the data storage order is different.
class A {double x; double y;};
class B {double y; double x;};
A programming language is also one of the expression formats for expressing instructions to a computer, and different programming languages such as C ++, C, fortran, and python have different expression formats.

Even if you decide whether to write gender as M, F or male or female, it means that the expression format is decided (that is, different).

3.2. Tree structure in which objects are associated with nodes In this disclosure, data interpretation and data integration are performed by constructing a tree structure in which objects are associated with nodes (an example of a graph). A tree structure generally consists of a node that is a component of the tree structure and a parent-child relationship between two nodes, and each node has at most one node that is the parent of the parent-child relationship. A node that does not have a node that is the parent of a parent-child relationship is specially called a root node, and there is only one node in the tree structure. The tree structure in the present disclosure has only one object associated with each node, and it is possible to associate the same object with nodes having different tree structures. The parent-child relationship of the tree structure in the present disclosure is a binary relation defined by the predicate logic L2 of the data processing platform. In the present disclosure, when an object associated with a tree-structured node is downcast, the parent-child relationship defined in predicate logic L2 for the new data type after the downcast causes a child node for that node. Can occur anew. That is, downcasting of the objects associated with each node of the tree structure can grow the tree structure.

4. [Embodiment 1]
Subsequently, the data interpretation method and the data interpretation device according to the first embodiment will be described.

4.1. Data interpreter configuration

FIG. 1 is a diagram showing a physical configuration of the data interpretation device 2 according to the present embodiment. The data interpretation device 2 includes a control unit 4 corresponding to a hardware processor, a RAM (RandomAccessMemory) 6 corresponding to a memory, a ROM (ReadOnlyMemory) 8 corresponding to a memory, a communication unit 12, and an input unit. It has 14 and an output unit 16. Each of these configurations is connected to each other via the bus 10 so that data can be transmitted and received.

The control unit 4 controls the execution of the program stored in the RAM 6 or the ROM 8, calculates and processes the data. The control unit 4 is an arithmetic unit that executes various programs (for example, a program for data interpretation). The control unit 4 receives various input data from the input unit 14 and the communication unit 12, displays the calculation result of the input data in the output unit 16, stores it in the RAM 6 or ROM 8, and transfers it to an external server through the communication unit 12. To do. The control unit 4 is composed of a CPU (Central Processing Unit) and the like.

The RAM 6 is a storage unit capable of rewriting data, and is composed of, for example, a semiconductor storage element. The RAM 6 stores programs and data such as applications executed by the control unit 4.

The ROM 8 is a storage unit capable of only reading data, and is composed of, for example, a semiconductor storage element. The ROM 8 stores programs and data such as firmware.

The communication unit 12 is a communication interface that connects the data interpretation device 2 to the external network 20.

The input unit 14 receives data input from the user, and is composed of, for example, a keyboard, a mouse, a touch panel, and a scanner. For example, when reading unstructured data such as a 2D-CAD drawing as input data, image data (raster data) can be acquired using a scanner.

The output unit 16 visually displays the calculation result of the control unit 4, and is composed of, for example, an LCD (Liquid Crystal Display).

The program for data interpretation may be stored and provided in a computer-readable storage medium such as RAM 6 or ROM 8, or provided from the external server 24 via the external network 20 connected by the communication unit 12. May be done. It is preferable that the CAD data and the object based on the CAD data are provided from the external server 24 or the like via the external network 20 connected by the communication unit 12. In the data interpretation device 2, various functions such as the acquisition unit 5a and the interpretation unit 5b are realized by the control unit 4 executing the program for data interpretation. It should be noted that these physical configurations are examples and do not necessarily have to be independent configurations. For example, the data interpretation device 2 may include an LSI (Large-Scale Integration) or a super LSI in which a CPU and a RAM 6 or a ROM 8 are integrated.

The control unit 4 is provided with a platform (here, a data processing platform) 5. The platform 5 includes a functional block that includes an acquisition unit 5a and an interpretation unit 5b.

The acquisition unit 5a acquires the input data as an object. The input data may be structured data or unstructured data.

The interpretation unit 5b creates an initial tree structure for the object acquired by the acquisition unit 5a. Further, the interpretation unit 5b interprets the input data as the result of automatically growing the tree structure from the initial tree structure. In this interpretation, the interpretation unit 5b appropriately performs type conversion of the object associated with each node of the tree structure to the extension side or the inclusion side.

4.2. Operation of the data interpreting device FIG. 4 is an example of a general view of the pier structure showing the pier structure, and is composed of CAD data. The data of the general drawing of the pier structure, which is CAD data, includes line segments, curves, character strings, etc. as components, and the collection of components is a "figure" such as a plan view or a front view, and a "table" such as various tables. Can be interpreted as.

4.2.1. Process of interpreting data This is the process of generating a tree structure associated with a node by an object representing an element of the drawing by inputting a design drawing object, and the generated tree structure is used as the interpretation result of the drawing. As shown in FIG. 18, a tree structure in which elements such as line segments, character strings, and circles included in the drawing are all arranged in the same hierarchy is used as the initial tree structure, and the tree structure is sequentially grown. However, if the elements in the drawing data are structured from the beginning, a tree structure that reflects the structure may be used as the initial tree structure. As an example, FIG. 19 shows the process of recognizing a text balloon with a leader as an example of the growth of a tree structure. In FIG. 19, when a circle contains a character string in the drawing (upper row), the two are collectively interpreted as a text balloon (middle row), and when a polygonal line is connected to the balloon, that is the case. The polygonal line is regarded as a leader line (lower). That is, the text balloon is recognized from the inclusion relationship between the circle element and the character string element, and the leader line is recognized from the connection between the text balloon and the line segment element. The parent-child relationship of the tree structure represents a context that specifies how the elements of the drawing are used, so that the line element that is part of the text balloon with a leader is assigned the role of "leader".

4.2.2. Operation for Interpreting the "Title Column" in the Table In the general diagram of the pier structure shown in FIG. 4, the procedure for interpreting the "Title Column" shown in FIG. 5 will be described. The CAD drafting standard (Ministry of Land, Infrastructure, Transport and Tourism) stipulates that the "title column" should be entered in the lower right corner of the general pier structure drawing. Also in the example of the general view of the pier structure shown in FIG. 4, it is provided in the lower right corner. Further, the "title column" is composed of a line and a character string in CAD data.

First, in the CAD data "Pier structure general diagram", the data that is a collection of lines is converted into an object (the class name is, for example, "LineBuf2D"). FIG. 6 is a diagram showing an object (class name “LineBuf2D”) composed of lines in the “general view of pier structure”. As objects, 16 objects from "A" to "P" are shown.

Next, as shown in Fig. 6, from the objects of a set of lines (class name "LineBuf2D"), those that cannot be interpreted as a set of cells are excluded from the candidates for the "title column". Here, a class called "CellSet" is defined for the set of cells, so that the downcast from the object of the set of lines (class name "LineBuf2D") to the subclass "CellSet" is automatically executed. FIG. 7 is a diagram showing that an object of a group of lines (class name “LineBuf2D”) is downcast to the subclass “CellSet”, and the candidates for the “title block” are the remaining eight objects. Objects "A", "B", "C", "D", "E", "F", "K", and "L" are candidates for the "title block".

In addition, when excluding those that cannot be interpreted as a set of cells from the object of a set of lines (class name "LineBuf2D"), a function for downcasting from the class "LineBuf2D" to the subclass "CellSet" is defined in advance. I will do it. Here, a function defined in advance for downcasting from a superclass to a subclass is referred to as an input function. Those that fail to downcast will be excluded from the "title block" candidates. The inheritance relationship between the subclass "CellSet" and the class "LineBuf2D" here depends on the extension / inclusion relationship that if it is interpreted as a set of cells "CellSet", it must also be interpreted as a set of lines "LineBuf2D" (described above). (See condition 2).

In addition, a value that indicates how likely it is to downcast from a superclass to a subclass in excluding an object of a collection of lines (class name "LineBuf2D") that cannot be interpreted as a set of cells (eg, cells). A value that indicates the percentage of probability that an object interpreted as a set of cells is actually a set of cells), and accuracy can be given to the object when converting to a subclass (when executing an input function). It is also possible to refer to the accuracy given to the superclass when calculating the accuracy.

Next, as shown in FIG. 8A, downcasting to the subclass "Table" is attempted for the object of the class "CellSet". For the input function in this case, CAD data elements (lines, character strings, etc.) are input together with the objects of the superclass "CellSet", and the elements included in each cell of the cell set are extracted. It is possible to define an input function so that downcast is successful when a certain number of character strings etc. are input to the object of class "CellSet", and it is downcast to the class of "Table". The object will be interpreted as "Table".

Next, as shown in FIG. 8B, it is checked whether a predetermined item, here, an item of "drawing name" exists in the object of the class "Table". If it exists, it will be downcast to an object of class "title block" and will be interpreted as "title block". At this time, the downcast is a function that determines from the internal data of the class whether it is possible to downcast in advance in the class (called is function) and a function that executes the actual downcast (cast function) regardless of the input function. Is executed based on. Here, the downcast by the is function and the cast function is called the downcast by analysis / classification. The "title block" is interpreted as described above.

Here, the operation of interpreting the "title column", which is a table, will be briefly explained from the viewpoint of growing the tree structure. FIG. 21 shows the process of recognizing the “title column” defined in the CAD drafting standard (Ministry of Land, Infrastructure, Transport and Tourism). In order to recognize the "title column", first, as shown in FIG. 21 (1), a group of connected line segments is extracted, and it is determined from the arrangement status of the line segments whether or not it is a "table framework". .. As shown in FIG. 21 (2), when the "table framework" is determined, the information of each cell of the table is recorded in the object expressing it. Using this cell information, it is further investigated from the drawing whether a character string is arranged in the cell, and if the character string is arranged, it is determined to be a "table" (FIG. 21 (3)), and the cell is determined. Stores a character string as information of. As shown in Fig. 21 (4), the "table" is recognized as the "title column" if the conditions such as "construction name" as a cell item are satisfied for the table of the drawing according to the CAD drafting standard. be able to.

4.2.2. Operation for Interpreting the "Pier Front View" in FIG. 4 Next, in the bridge pier structure general diagram shown in FIG. 4, a procedure for interpreting the "pier front view" in the figure will be described. In FIG. 4, a “front view of the pier” is provided at the upper center.

First, in the CAD data "Pier structure general diagram", the data that is a collection of lines is converted into an object (class name "LineBuf2D"). FIG. 6 is a diagram showing an object composed of lines in the “general view of pier structure”. As objects, 16 objects from "A" to "P" are shown.

Next, in excluding those that cannot be interpreted as the figure "View" with dimension values from the object of a collection of lines (class name "LineBuf2D"), down from the class "LineBuf2D" for the subclass "View". Define the function to cast in advance. Those that fail to downcast will be excluded from the candidates that will be interpreted as "View". The inheritance relationship between the subclass "View" and the class "LineBuf2D" here is an extension / inclusion relationship that must be interpreted as a group of lines "LineBuf2D" if it is interpreted as a figure "View" with dimension values. (See (Condition 2) above). FIG. 9 is a diagram showing the remaining eight cells after excluding those that are not the subclass “View” from the object of a group of lines (class name “LineBuf2D”). The cells "G", "H", "I", "J", "M", "N", "O" and "P" are left.

In addition, when downcasting from an object of a collection of lines (class name "LineBuf2D") to the figure "View" with dimension values, a value that indicates how probable the downcast from the superclass to the subclass is. (For example, a value that indicates what percentage of the probability that an object interpreted as a figure with dimensional values is actually a figure with dimensional values), accuracy can be given to the object when converting to a subclass.

To find out if an object is a "pier front view", refer to a given item in the object's internal data, here the layer, and see if there are any child elements of the object that belong to the main structure (D-STR) layer. Analyze and classify. If not all elements of an object belong to the main structure (D-STR) layer, the object is excluded from the "Pier front view" candidates. In FIG. 10, among the eight objects of the class name View shown in FIG. 9, those that do not belong to the main structure (D-STR) layer are excluded, and “H”, “I”, “J”, Seven are shown with "M", "N", "O" and "P".

In downcasting using the input function (called downcasting by inputting information), it is possible to judge whether or not downcasting is possible by using additional information in addition to the unique internal data that each object has. As shown in FIG. 11, a character string as a title is input from CAD data to an object of the class "View", and it is interpreted as a "pier front view". As described above, the drawing "front view of the pier" is interpreted.

4.2.4. Summary of operation for interpreting drawings In the data interpretation device and data interpretation method according to this embodiment, the meaning and contents of 2D-CAD drawings are recognized step by step.

For various views such as front views and plan views, pay attention to the lines as shown in FIGS. 13 (1) and 13 (2). That is, the data that is a collection of lines is made into an object (class name "LineBuf2D"). Next, as shown in FIGS. 13 (2), 13 (3), and 13 (4), after inputting dimensional values and the like from the drawing, it is interpreted as an object with the class name "View", and further. Interpret as an object with the class name "front view of pier". Furthermore, information that the height of the pillar of the pier is 11 m is obtained from the projection surface of the dimensional value and the internal data of "View".

For various tables, pay attention to the lines as shown in FIGS. 14 (1) and 14 (2). That is, the data that is a collection of lines is made into an object (class name "LineBuf2D"). Next, as shown in FIGS. 14 (2) and 14 (3), it is interpreted as an object having the class name “CellSet”. Next, as shown in FIGS. 14 (3) and 14 (4), after inputting the cell contents such as a character string from the drawing, it is interpreted as an object of the class name "Table", and further, the class Interpreted as an object with the name "substructure coordinates".

As shown in FIG. 15, in various tables, an object of a set of lines (class name "LineBuf2D") is interpreted as an object of a set of cells (class name "CellSet"), and the contents are further contained in a plurality of cells. It is interpreted as a filled object (class name "Table") or an object containing only one cell (class name "Cell"). Similarly, as shown in FIG. 15, in various figures, an object of a collection of lines (class name "LineBuf2D") is interpreted as an object (class name "View") that is a diagram with dimension values. Furthermore, it is interpreted as an object having an item peculiar to the "front view of the bridge pier" (class name "front view of the bridge pier") and an object having an item peculiar to the "side view of the pier" (class name "side view of the pier").

As shown in FIG. 16, as a recognition method for 2D-CAD drawings, two methods are set in this embodiment. (1) "input of information" and (2) "analysis / interpretation".

As shown in FIG. 16 (1) as an example, the information on the drawing is input as additional information from the input data to the object (class name "CellSet") of the set of cells. It can be interpreted as an object with the class name "Table".

Further, as shown in FIG. 16 (2) as an example, in the object of the class name "Table", by analyzing and classifying the items etc. and downcasting, the object and the class of the class name "title column" An object with the name "Structural Height Table" and an object with the class name "Coordinate Table" can be interpreted.

Note that FIG. 27 is an example of a script for interpreting the 2D-CAD drawing "006_P2 pier structure general diagram.dxf". This script is an example of a language understood by the data processing platform according to the present disclosure. Of course, the data processing platform of the present disclosure may be an interpreter other than the interpreter created by the present inventor as long as the requirements described above are satisfied. The script may also be in a language understood by the other interpreter.

5. [Embodiment 2]
The data integration device 2'according to the present embodiment integrates fragmentary information distributed in a plurality of data to create a model of data expression target.

The data integration device according to the second embodiment will be described with reference to FIG.

5.1. Data integration device configuration

FIG. 22 is a diagram showing a physical configuration of the data integration device 2'according to the present embodiment. The data integration device 2'is input to a control unit 4 corresponding to a hardware processor, a RAM (RandomAccessMemory) 6 corresponding to a memory, a ROM (ReadOnlyMemory) 8 corresponding to a memory, and a communication unit 12. It has a unit 14 and an output unit 16. Each of these configurations is connected to each other via the bus 10 so that data can be transmitted and received. The communication unit 12 is a communication interface for connecting the data integration device 2'to the external network 20, and the data integration device 2'also connects to the external server 24 via the external network 20 connected by the communication unit 12. The RAM 6, ROM 8, communication unit 12, input unit 14, output unit 16, and bus 10 are the same as those according to the first embodiment shown in FIG.

The control unit 4 is provided with a platform (here, a data processing platform) 5. The platform 5 includes a functional block that includes an acquisition unit 5a, an interpretation unit 5b, and an integration unit 5c.

The acquisition unit 5a acquires the input data as an object. The input data may be structured data or unstructured data.

Interpretation unit 5b creates an initial tree structure for the object. Further, the interpretation unit 5b interprets the input data as the result of automatically growing the tree structure from the initial tree structure. In this interpretation, the interpretation unit 5b appropriately performs type conversion of the object associated with each node of the tree structure to the extension side or the inclusion side.

The integration unit 5c creates an initial tree structure for each representation target of the object acquired by the acquisition unit 5a. In addition, the integration unit 5c causes the object acquired by the acquisition unit 5a to interpret the interpretation unit 5b as appropriate, and reads the fragmentary information to be expressed. Further, the integration unit 5c gives one or a plurality of fragmentary information to the initial tree structure as additional information, and constructs the result of automatically growing the tree structure from the initial tree structure as integrated data. The integrated data is a model to be represented. In the construction of the integrated data, the integration unit 5c appropriately performs type conversion of the object associated with each node of the tree structure to the extension side or the inclusion side.

With the above configuration, the data integration device 2'according to the present embodiment integrates a plurality of fragmentary information extracted from a plurality of data as materials to construct desired data.

Further, the data integration device 2'according to the present embodiment automatically converts the data structure of objects having different representation formats, automatically searches for the type conversion route, and automatically configures the integrated data.

5.2. Operation of data integration device The flow of the digital bridge automatic construction method according to the present disclosure is shown in FIG. The input data group is interpreted individually, and a plurality of information is extracted from the interpretation result. A digital bridge is constructed by grouping and integrating information for each object of expression. The process of automatic construction of digital bridges consists of the following three.
(1) Process of interpreting data (2) Information extraction process (3) Identification / integration process Note that the first embodiment is an example including (1) and (2), and the second embodiment is (1). Including up to (3).

5.2.1. (1) Process of interpreting data The process of interpreting data is explained in "4.2.0. Process of interpreting data".

5.2.2. (2) Information extraction process The actual object expressed in the drawing is identified from the interpretation result of the drawing, and the information is summarized as a set of expressions related to the object. Here, this process is simplified and the names of the objects such as "P1 pier" and "A2 pier" are adopted as the objects to identify the object.

5.2.2. (3) Identification / integration process The integration of multiple pieces of information obtained in the information extraction process is performed by creating one graph from multiple pieces of information. This graph includes the expression objects (for example, "P1 pier" and "A2 pier") identified from the information as a part of the graph, and the information about each expression object is also aggregated and integrated as a part of the graph. .. In the process of this integration, automatic structuring is carried out by growing the tree structure as in the interpretation of the drawing. The tree structure that is the target of automatic structuring is a part of the graph, and the parent-child relationship of the tree structure can be the relationship between all and parts of the nodes (for example, the relationship between the pier and its foundation). The initial tree structure may be a single node that abstractly represents the object of representation (eg, an object associated with a node if only known to be a pier). The growth of the tree structure is performed by creating more detailed objects on the extension side from the objects on the inclusion side according to the extension / inclusion relationship between the objects. This is equivalent to a downcast in object-oriented programming, and a normal downcast that considers only the internal data of the object cannot be executed properly due to lack of information. However, in this process, it may be appropriately executed by referring to a part of the graph reflecting the information extracted from the drawing. The more detailed object created in this case can be regarded as an integration of the information represented as a graph. In addition, since the tree structure (and the graph including it) grows according to the created object, downcasting according to the graph at that time is tried for each growth. In addition, in order to create a 3D model object, the information extracted from the drawing may not be enough. In this case, for example, the graph may be modified by engineering knowledge or some estimation technique.

In the information extraction process, information is obtained as a collection of natural language-style sentences such as "The height of the pier with the name:" P1 ": is: Q (" 10m ") :;". In order to integrate the contents of a plurality of sentences, each sentence is represented by a graph, the nodes of each graph are identified, and the contents are integrated into one graph. However, some sentences may describe a rule for modifying the integrated graph without being represented by a graph, and the graph may be modified as appropriate by applying this rule.

5.24.4 Application to 2D CAD drawings 2D CAD (DXF) in which drawing elements such as line segments and character strings are recorded in vector format for the purpose of examining the digital bridge automatic construction method according to the present disclosure. We tried automatic interpretation and automatic construction of the expression target for the drawing of the format). FIG. 20 shows an example in which a three-dimensional model of a pier was automatically constructed by trial. As a result of interpretation of the drawings, "front view of pier", "plan view of pier", and "side view of pier" are interpreted. The projection plane of the structure is automatically created from the "front view of the pier", the "plan view of the pier", and the "side view of the pier", and a three-dimensional model is automatically created from the projection plane of the structure. FIG. 12A is a view showing how the projection plane of the structure is automatically created from the front view, the plan view, and the side view, and FIG. 12B is a view in which a three-dimensional model is automatically created from the projection plane of the structure. It is a figure which shows the state.

6. Other Embodiments As described above, Embodiments 1 and 2 have been described as examples of the techniques disclosed in the present application. However, the technique in the present disclosure is not limited to this, and can be applied to embodiments in which changes, replacements, additions, omissions, etc. are made as appropriate.

In addition, an attached drawing and a detailed explanation were provided to explain the embodiment. Therefore, among the components described in the attached drawings and the detailed description, not only the components essential for solving the problem but also the components not essential for solving the problem in order to exemplify the above technology. Can also be included. Therefore, the fact that these non-essential components are described in the accompanying drawings or detailed description should not immediately determine that those non-essential components are essential.

Further, since the above-described embodiment is for exemplifying the technology in the present disclosure, various changes, replacements, additions, omissions, etc. can be made within the scope of claims or the equivalent thereof.

This application is based on Basic Application No. 2019-139150 filed in Japan on July 29, 2019, the entire contents of which are incorporated herein by reference.

2 ... Data interpretation device, 2'... Data integration device, 4 ... Control unit, 5 ... Platform, 5a ... Acquisition unit, 5b ... Interpretation unit, 5c ... Integration unit , 6 ... RAM, 8 ... ROM, 10 ... Bus, 12 ... Communication section, 14 ... Input section, 16 ... Output section, 20 ... External network, 24 ... -External server.

Claims (8)

1. A data interpreter with a platform that automatically performs type conversion of objects.
   The platform is provided in the control unit of the data interpretation device, and has an acquisition unit and an interpretation unit.
   The acquisition unit acquires the input data as an object of the platform;
   The interpreting unit creates an initial graph for the object and automatically grows the graph from the initial graph while appropriately performing type conversion of the object associated with each node of the graph to the extension side or the inclusion side. Interpret by
   A data interpreter that operates the control unit.
2. The interpretation unit
   The graph is added by executing downcasting, which is a type conversion of the object to the extension side based on the extension / inclusion relationship between the objects, and adding a node associated with the object after the downcast to the graph. The data interpretation device according to claim 1, which is automatically grown.
3. It is a data interpretation method using a platform that automatically executes type conversion of objects.
   The platform is provided in the control unit of the computer and has an acquisition unit and an interpretation unit.
   The step in which the acquisition unit acquires the input data as an object of the platform;
   The interpreting unit creates an initial graph for the object and automatically grows the graph from the initial graph while appropriately performing type conversion of the object associated with each node of the graph to the extension side or the inclusion side. Steps to interpret by
   How to interpret the data.
4. A program that a computer runs
   In a platform that is provided in the control unit of the computer, has an acquisition unit and an interpretation unit, and automatically executes type conversion of objects.
   The step in which the acquisition unit acquires the input data as an object of the platform;
   The interpreting unit creates an initial graph for the object and automatically grows the graph from the initial graph while appropriately performing type conversion of the object associated with each node of the graph to the extension side or the inclusion side. Steps to interpret by
   A program that operates the control unit to do so.
5. A data integration device with a platform that automatically executes type conversion of objects.
   The platform is provided in the control unit and has an acquisition unit and an interpretation unit.
   The acquisition unit acquires the input data as an object of the platform;
   The interpreter creates an initial graph for the object and automatically grows the graph from the initial graph while appropriately performing type conversion of the object associated with each node of the graph to the extension side or the inclusion side. To construct integrated data that integrates one or more of the above objects;
   A data integration device that operates the control unit.
6. It is a data integration method using a platform that automatically executes type conversion of objects.
   The platform is provided in the control unit of the computer and has an acquisition unit and an interpretation unit.
   The step in which the acquisition unit acquires the input data as an object of the platform;
   The interpreter creates an initial graph for an object and automatically grows the graph from the initial graph while appropriately performing type conversion of the object associated with each node of the graph to the extension side or the inclusion side. To construct integrated data that integrates one or more of the above objects;
   How to integrate data.
7. A program that a computer runs
   In a platform that is provided in the control unit of the computer, has an acquisition unit and an interpretation unit, and automatically executes type conversion of objects.
   The step in which the acquisition unit acquires the input data as an object of the platform;
   The interpreter creates an initial graph for an object and automatically grows the graph from the initial graph while appropriately performing type conversion of the object associated with each node of the graph to the extension side or the inclusion side. To construct integrated data that integrates one or more of the above objects;
   A program that operates the controls of a computer to do so.
8. A platform that automatically converts the data representation format
   A plurality of programs having a predetermined element program and having inputs and outputs of arbitrary expression formats are loosely coupled via data by automatic conversion of the expression format, and the expression target of the integrated data is a city or a structure. There is a digital city building platform.

Images