WO2022168681A1 - データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システム - Google Patents

データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システム Download PDF

Info

Publication number
WO2022168681A1
WO2022168681A1 PCT/JP2022/002713 JP2022002713W WO2022168681A1 WO 2022168681 A1 WO2022168681 A1 WO 2022168681A1 JP 2022002713 W JP2022002713 W JP 2022002713W WO 2022168681 A1 WO2022168681 A1 WO 2022168681A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
information
graph
objects
platform
Prior art date
Application number
PCT/JP2022/002713
Other languages
English (en)
French (fr)
Inventor
英之 大谷
Original Assignee
国立研究開発法人理化学研究所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 国立研究開発法人理化学研究所 filed Critical 国立研究開発法人理化学研究所
Priority to JP2022579469A priority Critical patent/JPWO2022168681A1/ja
Publication of WO2022168681A1 publication Critical patent/WO2022168681A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/12—Geometric CAD characterised by design entry means specially adapted for CAD, e.g. graphical user interfaces [GUI] specially adapted for CAD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/13—Architectural design, e.g. computer-aided architectural design [CAAD] related to design of buildings, bridges, landscapes, production plants or roads
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/40—Processing or translation of natural language
    • G06F40/55—Rule-based translation
    • G06F40/56—Natural language generation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services

Definitions

  • the present invention relates to a data integration device, a data integration method and program, and a digital city construction system.
  • Non-Patent Document 1 Since the 1980s, many studies have been conducted to automatically construct 3D models from design drawings (Non-Patent Document 1). , The failure to interpret the part spread to the whole, and the three-dimensionalization collapsed, and there was a difficulty that it was not possible to deal with complicated drawings.
  • JP 2011-123644 A JP-A-04-2315142 JP-A-04-030265 JP-A-04-275684 JP 2018-109977 A
  • Unstructured data refers to data that is basically expressed so that humans can see and interpret it, and from which computers cannot extract information as it is.
  • a 2D-CAD drawing is unstructured data and consists of elements such as lines, curves, and character strings, but it does not necessarily mean that the group of elements is a "figure” or a “table”. is not explicitly described, and humans visually interpret it as a "figure” or “table” and read the information.
  • unstructured data includes images with pixels as elements and point cloud data with points as elements.
  • data that is not called unstructured data may also be regarded as unstructured data if necessary information cannot be directly extracted. There is a need for a technology that allows a computer to automatically interpret the meaning of unstructured data based on the element data and the relationship between the elements (including the positional relationship) to read fragmentary information.
  • Diagrams and tables included in 2D-CAD drawings represent fragmentary information about objects in physical space (for example, certain structures) that are to be expressed in 2D-CAD drawings. It is neither the object itself (that is, the object in physical space) nor the model of the object of expression.
  • model refers to the counterpart in virtual space of the object to be represented.
  • fragmentary information refers to information that is not necessarily sufficient for creating a model to be represented and may be integrated with other information to create a model to be represented.
  • the present invention simultaneously combines both data expressed in a standardized format and data in a unique format optimized for individual purposes. It provides a loosely coupled way of becoming available. It also provides a data interpretation device, method, and program for extracting information from a wide range of data, from new data to old materials. Furthermore, the present invention provides a data integration device, method, and program for creating a model of a data representation target by integrating fragmentary information dispersed in a plurality of data. It also provides a digital city platform.
  • the elements of the drawing are not only assembled bottom-up, but also by automatically identifying the context of the figure, the meaning matching the figure is estimated top-down, and information is retrieved from the drawing according to the meaning.
  • a drawing interpretation method for extraction is disclosed. Specifically, this is achieved by changing (automatically structuring) a graph in which drawing elements are associated with nodes, based on the relationships between the constituent elements of the graph.
  • This method is a robust method that does not automatically structure the graph even if the interpretation fails.
  • this automatic structuring method is also adopted for the automatic construction of 3D models. This makes it possible to flexibly and automatically construct a three-dimensional model with different degrees of detail according to the accuracy of drawing interpretation.
  • the 3D model automatically constructed by the method of this research organizes information based on the relationship between the constituent elements of the graph, and holds a wide variety of information such as the internal structure and physical properties of the structure as well as its shape. Therefore, it can be expected to be applied to various purposes.
  • an interpreter capable of object-oriented programming is constructed in order to execute automatic type conversion based on the relationship between the superordinate concept and the subordinate concept between the objects that constitute the graph.
  • objects are appropriately converted from higher-level objects to more detailed lower-level objects based on their internal data and graph structure (downcasting). ).
  • downcasting which cannot be properly executed due to lack of information, supplements information from the structure of the graph and the held data of the object group that is the constituent element of the graph. It is possible.
  • a data integration device provided with a platform for automatically executing object type conversion, wherein the platform is provided in a control unit of the data integration device and has an interpretation unit and an integration unit, and the interpretation generating linguistic information in which objects are associated with words from a graph representing relationships between objects of the platform;
  • the data integration device wherein the integration unit holds the information and executes creation and conversion of the graph to reflect the information; and causes the control unit to operate.
  • the integrating unit reflects language format information input by a user in the graph, so that the information generated by the interpreting unit and the The data integration device according to [1], which integrates information in language form input by a user.
  • the interpreting unit converts the constituent elements of the graph representing the relationship between the objects of the platform into a type of a lower-level concept based on the relationship between the upper-level concept and the lower-level concept between the objects.
  • the data integration device according to [1] or [2], which transforms the structure of the graph as follows.
  • the integration unit performs an inference process on the linguistic information held by the integration unit, taking into consideration the relationship between the superordinate concept and the subordinate concept between objects, and
  • the data integration device according to any one of [1] to [3], which converts the information stored in the data integration device.
  • the control unit generates an output to a user according to a natural language or a natural language-similar word or sentence input by a user, wherein the information in the language format is similar to a natural language
  • the data integration device according to any one of [4] to [4].
  • a data integration method using a platform that automatically executes object type conversion wherein the platform is provided in a control unit of a computer and has an interpretation unit and an integration unit, and the interpretation unit generating, from a graph representing relationships between objects of the platform, information in linguistic form in which objects are associated with words;
  • a data integration method that performs the steps of creating and transforming a .
  • a program executed by a computer which is provided in a control unit of the computer, has an interpreter and an integrator, and automatically executes object type conversion, wherein the interpreter is an object of the platform generating information in linguistic form in which objects are associated with words from a graph representing relationships between a program for operating a controller of said computer to perform;
  • a system comprising a platform for automatically executing type conversion of objects and an element program, wherein the platform performs type conversion path search and automatic execution based on the relationship between superordinate concepts and subordinate concepts between objects, A digital city construction system that realizes loose coupling between element programs by abstracting the program input format and expanding the scope of application.
  • the platform is provided in the control unit of the system and has an interpreter and an integrator.
  • the present invention realizes a data processing platform that 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 data expressed in a standardized format and data in a unique format optimized for individual purposes, and accumulate programs to utilize the data. Technology can be continuously upgraded.
  • using the data processing platform it is possible to realize a data interpretation device, data interpretation method, and program for extracting information from a wide range of data, from new data to old materials.
  • a data processing platform it is possible to realize a data integration device, a data integration method, and a program that integrate fragmentary information distributed in a plurality of data and create a model of a data representation target. .
  • FIG. 1 is a diagram showing a physical configuration of a data interpretation device according to Embodiment 1;
  • FIG. Schematic diagram showing conversion of data in representation formats of “source 1,” “source 2,” and “source 3” into data in representation formats of “target 1,” “target 2,” and “target 3.” is. Schematically shows setting of "intermediary data” as an intermediary for conversion from “source 1", “source 2", and “source 3” to "target 1", “target 2", and “target 3". It is a diagram.
  • FIG. 10 illustrates another situation of intermediary data with automatic data conversion;
  • FIG. 4 is a diagram showing an example of automatic data conversion in the interpreter of the present invention; It is an example of a bridge pier structure general drawing showing a pier structure, which is composed of CAD data.
  • FIG. 4 is a diagram showing an object (class name “LineBuf2D”) composed of lines in the “bridge pier structure general drawing”.
  • FIG. 10 is a diagram showing that objects that are not subclass “CellSet” are excluded from line collection objects (class name “LineBuf2D”), and six objects are interpreted as "CellSet”;
  • FIG. 10 is a diagram showing that a character string or the like extracted from CAD data is input to an object of class "CellSet” and interpreted as a class of "Table”.
  • FIG. 10 is a diagram showing that an object of class 'Table' is analyzed and classified for the existence of an item of 'title block', and if it exists, it is interpreted as an object of class 'title block';
  • FIG. 10 is a diagram showing that objects that are not subclass "View” are excluded from line collection objects (class name "LineBuf2D"), and eight objects are interpreted as "View”.
  • FIG. 10 is a diagram showing the remaining 7 cells after those that do not belong to the main structure (D-STR) layer are excluded from the 8 objects with the class name View shown in FIG. 9; Enter a title character string extracted from CAD data for an object of class "View", and create an object with the class name "Pier front view” that has items specific to "Pier front view”.
  • FIG. 10 is a diagram showing that an object of class 'Table' is analyzed and classified for the existence of an item of 'title block', and if it exists, it is interpreted as an object of class 'title block';
  • FIG. 10 is a diagram showing interpreting that there is;
  • FIG. 4 is a diagram showing how information on a structure is automatically extracted from a front view, a plan view, and a side view;
  • FIG. 4 is a diagram showing how a three-dimensional model is automatically created from information on a structure;
  • FIG. 10 is a diagram showing that the "front view of the pier” included in the 2D-CAD drawing is recognized step by step.
  • FIG. 10 is a diagram showing that the "substructure coordinate table" included in the 2D-CAD drawing is recognized step by step.
  • FIG. 4 is a diagram showing that the steps for 2D-CAD drawing recognition are hierarchical in the data interpretation device and data interpretation method according to the present disclosure;
  • FIG. 11 shows an initial graph for drawing interpretation
  • FIG. 10 is a diagram showing an example of automatic structuring of a graph in drawing interpretation
  • FIG. 10 is a diagram showing automatic construction of a digital pier based on a two-dimensional CAD drawing
  • FIG. 11 shows an initial graph for drawing interpretation
  • FIG. 10 is a diagram showing an example of automatic structuring of a graph in drawing interpretation
  • FIG. 10 is a diagram showing automatic construction of a digital pier based on a two-dimensional CAD drawing
  • FIG. 10 is a diagram showing a physical configuration of a data integration device according to Embodiment 2; FIG. It is a figure which shows the implementation method of data processing in the case of developing individually.
  • FIG. 4 is a diagram showing how data processing is implemented when using a standard format
  • FIG. 10 is a diagram illustrating how data processing is implemented when automatic conversion is used
  • 1 is a diagram showing a star-shaped network centered on a standard representation format as an example of the topology of a network formed by representation formats and conversion paths
  • FIG. FIG. 2 is a diagram showing a free network based on automatic conversion of expression formats as an example of a topology of a network formed by expression formats and conversion paths;
  • FIG. 2 is a diagram showing the form of a fixed digital city according to a standard form
  • 1 is a diagram illustrating the form of a digital city building system with development sustainability
  • FIG. 10 is a diagram showing an example of automatic conversion of expression format for the unary function ⁇ of L1; This is an example of a script for interpreting the 2D-CAD drawing "006_P2 pier structure general drawing.dxf".
  • FIG. 11 is a diagram (part 1) showing an example of a graph in which the contents of each language expression are integrated
  • FIG. 12 is a diagram (part 2) showing an example of a graph in which the contents of each language expression are integrated
  • FIG. 10 is a diagram for explaining an example of an automatic structuring process of a graph that integrates the contents of each linguistic expression;
  • the data processing platform is related to the research of the present inventor and functions as an interpreter for constructing a digital city.
  • the expression format of data can be changed flexibly as long as the meaning and content of the data are the same.
  • a mechanism for automatically changing the expression format it can be applied to data expressed in different formats. For example, if a program that calculates the distance between two points on a two-dimensional plane represented by a Cartesian coordinate system is given a point represented by another coordinate system such as a polar coordinate system, the automatic coordinate system By converting, one program can be commonly used for multiple representation formats. If this mechanism can be realized for general use, it will be possible to easily create an information extraction program that does not depend on the expression format, and it will also be easy to replace data and programs.
  • an interpreter (called a data processing platform (DPP)) with a mechanism for automatically converting expression formats is constructed, and element programs for constructing a digital city are accumulated as its library.
  • DPP data processing platform
  • Platform refers to something that functions as a foundation for aggregating and linking element programs.
  • DPP data processing platform
  • platform also means that the DPP functions as a base for integrating and linking element programs.
  • the purpose of the disclosure related to this research and idea is to define the logical equivalence between data with different expression formats and to present an automatic conversion method for expression formats according to the definition. .
  • data sharing is done in a format defined by a standardization organization, and is often human-readable text format data, but in high-performance computing, binary format is usually adopted, and the whole can be read and written at high speed. Homogeneous data are often arranged in a row.
  • searching data stored for a long period of time it is common to access only a part of the data, and a data structure can be selected based on the unity of the meaning and content of the search target.
  • Even data with equivalent meanings and contents are used in various forms of expression according to various processing purposes, determined and used by the subject of calculation and the subject of data management.
  • FIGS. 23A-23C are diagrams showing three ways of implementing data processing. Arrows represent conversion of data representation format.
  • FIG. 23A is the case of individual development
  • FIG. 23B is the case of using the standard format
  • FIG. 23C is the case of using automatic conversion.
  • F(X i , Y j ) represents a function that inputs data x i of expression format X i and data y j of expression format Y j and performs predetermined data processing.
  • i ⁇ i' the expression forms of X i and X i' are different.
  • j ⁇ j' the expression forms of Y j and Y j' are different.
  • FIG. 24 shows the topology of the network created by the expression format and the conversion path.
  • FIG. 24A is a star-shaped network centered on standard expressions
  • FIG. 24B is a free network based on automatic conversion of expressions.
  • a methodology based on a standard representation restricts the topology of this network to a star shape centered on the standard representation, as shown in Figure 24A. Plays the role of data format.
  • the network topology configuration is free, and the position where data and programs are connected is also free (see FIG. 24B).
  • data that is not directly linked to a program is automatically linked indirectly by automatic conversion, so data and programs can be easily replaced.
  • this network can grow by adding new representations and processing programs.
  • star-shaped topologies can be formed, but the central representation is naturally bottom-up, unlike the standard representation, which is defined top-down. It is a de facto standard expression format determined by
  • Digital city building system 1.2.4.1. Definition of a digital city
  • the structures that make up a city have a long service life, while research and development progresses rapidly. For this reason, it is assumed that data generated at each stage of design, construction, and maintenance will be accumulated and used for multiple purposes by applying technologies that will be developed later. In fact, a huge amount of data is stored for existing structures, and effective use of the data is being promoted.
  • One example is the estimation of damage from earthquakes and tsunamis using numerical simulations.
  • it is necessary to express a model of the city with a suitable degree of detail on a computer. It is constructed by integrating knowledge about its components into data that represents it. In the present study and proposed disclosure, this model of the city as integrated knowledge is defined as the digital city.
  • a digital city is used as an information source for creating target data, such as input data for numerical simulations.
  • a binary predicate ⁇ is defined as satisfying the following reflexive and transitive laws. However, ⁇ is a logical symbol.
  • n-ary function ⁇ and the n-ary predicate ⁇ of L1 are said to be regular if they satisfy the following two conditions.
  • HasRoof(a) is a regular unary predicate representing the attribute "a has a roof”
  • HasRoof(y) is a regular unary predicate representing the attribute "a has a roof”
  • the identity function is a regular function, and the predicate that always returns true and the predicate that always returns false are regular predicates.
  • Cartesian2D a representation format that expresses points on a two-dimensional plane in a Cartesian coordinate system
  • Polar2D a representation format that expresses points on a two-dimensional plane in a polar coordinate system.
  • the Cartesian2D data representation is a pair of x and y coordinates (x, y)
  • the Polar2D data representation is a pair of radius 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.
  • the x-coordinate and y-coordinate survey as a holomorphic function that associates a real number representation format Real data representation with a point on a two-dimensional plane
  • the Polar2D data representation is a subordinate concept of the Cartesian2D data representation
  • the x-coordinate and y-coordinate survey results for the two data representations are equivalent from Equation 1, ie, the two data representations represent the same point.
  • Cartesian2D_RGB that expresses a colored point on a two-dimensional plane as a set of x and y coordinates and RGB values (x, y, r, g, b).
  • Surveying the x and y coordinates is also possible for the Cartesian2D_RGB data representation, and if the Cartesian2D_RGB data representation is a subordinate concept of the Cartesian2D data representation, then for the two data representations as in the previous example The two data representations represent the same point where the x- and y-coordinate survey results are equivalent.
  • unary predicates A and B in L1 have a superordinate concept/subordinate concept relationship in L2 as A and B satisfying the following relational expression in L1.
  • the holomorphic functions and holomorphic predicates of L1 can be expanded to holomorphic functions and holomorphic predicates of L2 as follows.
  • the value of the n-ary holomorphic function ⁇ in L2 is the unary predicate of L1, the subset of D1 corresponding to that unary predicate, and each argument of the function ⁇ in L2, i.e. the unary predicate of L1, Define it as the set of all values of the function ⁇ in L1 computed for the set of all L1 elements that are true.
  • predicates are functions when defining a representation format that expresses truth values as data. This shows that data can be expressed only by regular functions without using regular predicates. Also, multi-valued logic can be expressed depending on how truth values are defined. For this reason, the following discussion focuses on holomorphic functions.
  • DPP automatically converts the data representation format as necessary (that is, automatically executes type conversion), and describes how to apply it to a pre-registered processing program.
  • the DPP according to the present disclosure is based on a concept different from general object-oriented programming.
  • general object-oriented programming sharing of data structures is a condition in the definition of inheritance relationships.
  • DPP does not require sharing of data structures in the definition of inheritance relationships. Instead, it is a condition for the inheritance relationship between classes to be established that there is a relationship between a superordinate concept and a subordinate concept.
  • DPP In DPP, users can define inheritance relationships between classes without being restricted by the sharing of data structures. There is no limit to the number of automatic (implicit) type conversions, the optimal path for type conversion is automatically searched, and the necessary number of conversions are automatically performed along the searched path.
  • DPP type conversion in addition to logically equivalent type conversion (called equivalence cast), type conversion to the lower concept side (called downcast) and type conversion to the higher concept side (upcast) are automatically executed.
  • downcasting is performed only when the conditions for converting to the conversion destination type are defined for each object and the definition is satisfied.
  • DPP is not limited to C++, but may be written in any other language as long as it satisfies the requirements equivalent to those described in this specification and allows equivalent implementation. .
  • the digital city construction system disclosed in this research and idea is based on the interpreter (DPP) disclosed in this invention, which has a mechanism for automatically converting expression formats, and accumulates a group of element programs for constructing a digital city. It is composed by building a digital city from material data and creating objective data.
  • DPP interpreter
  • This DPP consider the following three points as requirements.
  • (Requirement 1) Provide an interface for instructing processing to the digital city construction system.
  • (Requirement 2) Function as a wrapper for existing processing programs.
  • the relationship between a certain representation format and its data representation corresponds to the relationship between classes and instances in object-oriented programming, and the relationship between superordinate concepts and subordinate concepts corresponds to the inheritance relationship.
  • the user of the digital city construction system will use a kind of object-oriented language to instruct the DPP to process.
  • Implementation details will be described later, but unlike normal languages understood by DPP, there is no need to share data structures between classes that are in an inheritance relationship, and the data structures of individual classes can be freely designed.
  • a path search that traces the inheritance relationship and an automatic type conversion are performed as necessary.
  • DPP When incorporating an already developed program into DPP, it is inefficient to reimplement the functions of the old program in a new language.
  • DPP implements C++ language classes and functions by wrapping them as DPP classes and functions. This allows DPP to loosely link already-developed data and programs with the methodology disclosed in this research and invention.
  • DPP class definitions and processing programs related to those classes are individually compiled and implemented in a dynamic library.
  • the library is loaded as required, and a conversion path search and automatic conversion are executed according to the inheritance relationship defined in the library.
  • DPP users can freely expand the system by creating a library of their own expression formats and processing programs and loading them.
  • the DPP class implements the object of the predicate logic L2 defined in the previous section ⁇ 1.3.'', that is, the unary predicate of L1.
  • attribute refers to a unary predicate of L1 that is not a representation of data.
  • An identity map is used as an automatic conversion map from representational forms to attributes. Attributes are generally not granular because they are defined across a variety of representations. If only attributes are handled and a regular function that expresses the properties of attributes as a concept is appropriately implemented, DPP may be able to define an ontology description language.
  • automatic conversion of expressions is implemented so that the route with the lowest cost can be searched and executed.
  • the automatic conversion of the expression format is performed by searching for the path with the minimum cost based on Dijkstra's method, and if the automatic conversion map is the identity map, the cost is set to 0, and in other cases can be 1, but is not limited to this.
  • nodes and links that do not lead to the goal are eliminated in advance based on the relationship between the superordinate concept and the subordinate concept.
  • Fig. 26 shows an example of automatic conversion of the expression format based on Equation 4 for the unary function ⁇ of L1.
  • a processing program can be implemented for each representation format of the input, but when a holomorphic function ⁇ B> whose domain is B is implemented, in DPP, if A ⁇ B, then the automatic conversion map B ⁇ A ⁇ is defined, and for any data representation a of A, we can compute ⁇ B ⁇ (B ⁇ A ⁇ (a)). It can be considered that the domain of ⁇ B> is expanded to include A by the automatic conversion of the expression form.
  • the function ⁇ A> is implemented, from Equation 4, ⁇ A>(a) ⁇ ⁇ B>(B ⁇ A>(a)).
  • DPP adopts the latter calculation method if ⁇ A> is defined. This is the same for general n-ary functions, and the method of selecting this implemented function is similar to polymorphism in general object-oriented programming.
  • data in a new expression format that is an extension of the old expression format can be converted to the old expression format, and old programs can be used.
  • a flexible data conversion technology that determines the possibility of automatic conversion depending on the contents of individual data is required. For this reason, DPP checks whether data expressed in a certain format satisfies specific conditions, and if so, performs automatic conversion to further expand the scope of application of functions.
  • the present disclosure provides data expressed in a standardized format, and
  • the objective is to provide a loosely coupled method in which both proprietary formats optimized for their respective purposes are available simultaneously. That is, the present disclosure realizes loose coupling by abstraction of data based on automatic data conversion of expression format instead of standardization that expresses data in a uniform format, and flexibly links heterogeneous data and heterogeneous program groups.
  • the purpose is to provide a method. It is also an object to provide a data interpretation method for extracting information from a wide range of data, from new data to old material, using such loosely coupled methods.
  • a further object of the present disclosure is to provide a data integration method that uses such a loosely coupled method to create a model of a data representation target by integrating fragmentary information distributed in multiple data.
  • DPP Unlike objects in general object-oriented programming, DPP introduces and defines objects for which type conversion is automatically executed through the optimal conversion path. Class inheritance relationships in objects are defined as follows (Conditions 1) to (Conditions 3).
  • (Condition 2) An inheritance relationship between classes is recognized when the relationship between the superordinate concept and the subordinate concept is established. For example, a first object belongs to a first class with (x, y) coordinates, a second object belongs to a second class with (r, ⁇ ) coordinates (polar coordinates), and the first class is Assume the situation of being a subclass of a first superclass. If these classes are defined by C++, there is no inheritance relationship between the first superclass and the second class, based on the principle that an inheritance relationship cannot exist unless the coordinate expressions are the same. On the other hand, if these classes are defined by the DPP that defines the objects, an inheritance relationship will occur if the relationship between the superordinate concept and the subordinate concept is established, so the first superclass and the second class There is an inheritance relationship between them.
  • FIG. 3A is a diagram showing another situation of mediation data by automatic data conversion.
  • the data in FIG. 3A i.e., "Source 1", “Source 2", “Source 3”, “Intermediate Data 1”, “Intermediate Data 2”, “Intermediate Data 3", "Target 1", “Target 2", “Target 3” is all objectified.
  • Each name is a class name (type name).
  • intermediate data 1 is set as a medium for conversion from “source 1” and “source 2” to “target 1” and “target 2", and from “source 3” to "
  • “intermediary data 3” is set as an intermediary for conversion to "target 3”.
  • a class "intermediate data 2" is set between “intermediate data 1" and “intermediate data 3”.
  • conversion from “source 1” and “source 2” to “target 3” can be newly realized via “intermediate data 1”, “intermediate data 2” and “intermediate data 3”.
  • conversion from “source 3" to "target 1” and “target 2” can be newly realized via “intermediate data 3", “intermediate data 2” and “intermediate data 1".
  • intermediate data 1 and “intermediate data 2” is an equivalent relationship
  • intermediate data 3 is an extension of "intermediate data 2”.
  • two conversions should be considered between the "intermediate data 1" and the "intermediate data 2".
  • Two conversions may be considered between "Data 2" and "Intermediate data 3" as well. This means that M+N redevelopments are streamlined to develop 2 transformations.
  • each class is defined.
  • source 1 is the subclass and “target 1” is the superclass, as indicated by the arrows.
  • FIG. 3B is a diagram illustrating an operation example of the interpreter;
  • "intermediary data 1" is set as a medium for conversion from “source 1” to “target 1", and from “source 2" and “source 3” to “target 2" and “target 3”
  • “intermediary data 2” is set as an intermediary for conversion from “source 3” to “target 3” and that no intermediary is set for conversion from “source 3” to “target 3”.
  • mutual conversion is set between “intermediate data 1" and "intermediate data 2”.
  • the interpreter plays a role of hiding from the user the complicated processing of the portion G enclosed by "Processing Generate”.
  • the interpreter generates intermediate data internally as necessary 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"->"intermediate data 2"->"intermediate data 1"->"target 1" can be assumed.
  • the interpreter grasps the conversion relationship (that is, the inheritance relationship) of each class, and generates necessary mediation data based on this when actually converting from "source 3" to "target 1".
  • the interpreter is configured to assume multiple transformation paths and compute the cost of the transformation (e.g., the number of times the transformation (inheritance) indicated by the arrow) was used for each one before the actual transformation. .
  • the path “intermediate data 1"->"target 3” could also be envisioned, it is clear that the path "source 3"->"target 3" is the fastest and most efficient.
  • the interpreter attempts to automatically determine the conversion path that is as efficient and fast as possible.
  • classes A and B have different representation formats because the order in which data is stored is different.
  • class A ⁇ double x; double y; class B ⁇ double y; double x;
  • a programming language is also one of the forms of expression for expressing instructions to a computer, and different programming languages such as C++, C, fortran, and python have different forms of expression.
  • a graph generally consists of nodes, which are constituent elements of the graph, and links connecting two nodes.
  • a graph in this disclosure has only one object associated with each node and each link, and each link has a direction.
  • Each link of the graph in this disclosure corresponds to a binary relation defined in the predicate logic L2 of the data processing platform, and the orientation of each link distinguishes the nodes at both ends of the link.
  • automatic structuring may occur according to the new object after the downcast. That is, the downcasting of the objects associated with each component of the graph provides a starting point for automatically interpreting and integrating the data.
  • FIG. 1 is a diagram showing the physical configuration of the data interpretation device 2 according to this embodiment.
  • the data interpretation device 2 includes a control unit 4 equivalent to a hardware processor, a RAM (Random Access Memory) 6 equivalent to a memory, a ROM (Read Only Memory) 8 equivalent to a memory, a communication unit 12, an input unit 14 and an output unit 16 . These components are connected to each other via a bus 10 so that data can be sent and received.
  • the control unit 4 controls the execution of programs stored in the RAM 6 or ROM 8 and performs data calculation and processing.
  • the control unit 4 is an arithmetic device that executes various programs (for example, programs 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 on the output unit 16, stores it in the RAM 6 and ROM 8, and transfers it to an external server through the communication unit 12. or
  • the control unit 4 is configured by a CPU (Central Processing Unit) and the like.
  • the RAM 6 is a data rewritable storage unit, and is composed of, for example, a semiconductor memory element.
  • the RAM 6 stores programs such as applications executed by the control unit 4 and data.
  • the ROM 8 is a storage unit from which data can only be read, and is composed of, for example, a semiconductor memory element.
  • the ROM 8 stores programs such as firmware and data.
  • 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, mouse, touch panel, and scanner.
  • a scanner can be used to acquire image data (raster data).
  • the output unit 16 visually displays the calculation result by the control unit 4, and is configured by, for example, an LCD (Liquid Crystal Display).
  • LCD Liquid Crystal Display
  • a program for data interpretation may be stored in a computer-readable storage medium such as RAM 6 or ROM 8 and provided, or may be provided from an external server 24 via an external network 20 connected by the communication unit 12.
  • may be CAD data and objects based on the CAD data are preferably provided from an external server 24 or the like via an external network 20 connected by the communication unit 12 .
  • various functions such as the acquisition section 5a and the interpretation section 5b are realized by the control section 4 executing a program for data interpretation. It should be noted that these physical configurations are examples, and do not necessarily have to be independent configurations.
  • the data interpretation device 2 may comprise an LSI (Large-Scale Integration) in which the CPU and the RAM 6 or ROM 8 are integrated, or a super LSI.
  • LSI Large-Scale Integration
  • a platform (here, a data processing platform) 5 is provided in the control unit 4 .
  • the platform 5 comprises functional blocks including an acquirer 5a and an interpreter 5b.
  • the acquisition unit 5a acquires input data as an object.
  • the input data may be structured data or unstructured data.
  • the interpretation unit 5b creates an initial graph for the objects acquired by the acquisition unit 5a. Further, the interpreting unit 5b interprets the input data as a result of automatically structuring the graph from the initial graph. In this interpretation, the interpreting unit 5b appropriately executes type conversion to the subordinate concept side or the superordinate concept side of objects associated with each node and each link of the graph.
  • FIG. 4 is an example of a pier structure general drawing showing a pier structure, which is composed of CAD data.
  • the data of the pier structure general drawing, which is CAD data includes line segments, curves, character strings, etc. as constituent elements. ” can be interpreted as
  • FIG. 6 is a diagram showing an object (class name “LineBuf2D") composed of lines in the "bridge pier structure general drawing”. 16 objects from “A” to "P” are shown as objects.
  • LineBuf2D line collection object
  • a value that indicates how likely it is to downcast from a superclass to a subclass e.g., cell A value that indicates the percentage probability that an object interpreted as a set is actually a set of cells
  • the probability can be given to the object when converting to a subclass (when executing the input function). It is also possible to refer to the accuracy assigned to the superclass when calculating the accuracy.
  • FIG. 21 shows the process of recognizing the "title block” defined in the CAD drafting standards (Ministry of Land, Infrastructure, Transport and Tourism).
  • Fig. 21 (1) a group of connected line segments is extracted, and it is determined whether it is a "framework of a table” from the arrangement of the line segments. .
  • FIG. 21(2) when it is determined to be a "framework of a table", the information of each cell of the table is recorded in the object representing it. Using this cell information, it is further checked from the drawing whether a character string is placed in the cell.
  • FIG. 6 is a diagram showing an object composed of lines in the "bridge pier structure general drawing". 16 objects from “A” to "P” are shown as objects.
  • FIG. 9 is a diagram showing the remaining 8 cells after excluding those that are not subclass "View” from the line collection object (class name "LineBuf2D").
  • the 'G', 'H', 'I', 'J', 'M', 'N', 'O' and 'P' cells are left.
  • downcasting using the input function (referred to as downcasting by inputting information) it is possible to determine whether downcasting is possible using additional information in addition to the unique internal data of each object.
  • a title string is input from CAD data and interpreted as "front view of bridge pier”.
  • the "bridge pier front view” which is a drawing, is interpreted.
  • FIGS. 13(1) and 13(2) For various drawings such as a front view and a plan view, attention is paid to lines as shown in FIGS. 13(1) and 13(2). That is, objectization (class name "LineBuf2D") is performed for data that is a collection of lines. Next, as shown in FIGS. 13(2), 13(3) and 13(4), after inputting dimension values etc. from the drawing, it is interpreted as an object with the class name "View”, and further It is interpreted as an object with the class name "Pier front view”. Furthermore, the information that the height of the pier pillar is 11m is obtained from the dimension value and the projection surface of the internal data of "View".
  • objectization class name "LineBuf2D”
  • FIGS. 13(2), 13(3) and 13(4) after inputting dimension values etc. from the drawing, it is interpreted as an object with the class name "View”, and further It is interpreted as an object with the class name "Pier front view”. Furthermore, the information that the height of the pier pillar is 11m is obtained from the dimension value
  • objectization (class name "LineBuf2D") is performed for data that is a collection of lines.
  • FIGS. 14(2) and 14(3) it is interpreted as an object with the class name "CellSet”.
  • FIGS. 14(3) and 14(4) after inputting the contents of the cell such as a character string from the drawing, it is interpreted as an object with the class name "Table”.
  • a line collection object (class name “LineBuf2D”) is interpreted as a cell set object (class name “CellSet”), and furthermore, multiple cells have contents.
  • a filled object (class name “Table”) or an object containing only one cell (class name “Cell”).
  • a collection of lines object (class name “LineBuf2D”) is interpreted as a figure object (class name “View”) with dimension values.
  • it is interpreted as an object having items specific to "pier front view” (class name “pier front view”) or an object having items specific to "pier side view” (class name “pier side view”).
  • Fig. 27 is an example of a script for interpreting the 2D-CAD drawing "006_P2 pier structure general drawing.dxf".
  • This script is an example of a language understood by the data processing platform of the present disclosure.
  • the data processing platform of the present disclosure may be any interpreter other than the interpreter created by the present inventors, as long as it satisfies the requirements described above.
  • the script may also be in a language understood by the other interpreter.
  • a data integration device 2' integrates fragmentary information dispersed in a plurality of data to create a model of a data representation target.
  • a data integration device according to Embodiment 2 will be described with reference to FIG.
  • FIG. 22 is a diagram showing the physical configuration of a data integration device 2' according to this embodiment.
  • the data integration device 2' includes a control unit 4 equivalent to a hardware processor, a RAM (Random Access Memory) 6 equivalent to a memory, a ROM (Read Only Memory) 8 equivalent to a memory, a communication unit 12, an input It has a section 14 and an output section 16 . These components are connected to each other via a bus 10 so that data can be sent and received.
  • the communication unit 12 is a communication interface that connects the data integration device 2 ′ to the external network 20 , and the data integration device 2 ′ is also connected to the external server 24 via the external network 20 connected by the communication unit 12 .
  • These RAM 6, ROM 8, communication section 12, input section 14, output section 16, and bus 10 are the same as those according to the first embodiment shown in FIG.
  • a platform (here, a data processing platform) 5 is provided in the control unit 4 .
  • the platform 5 comprises functional blocks including an acquisition unit 5a, an interpretation unit 5b and an integration unit 5c.
  • the acquisition unit 5a acquires input data as an object.
  • the input data may be structured data or unstructured data.
  • the interpretation unit 5b creates an initial graph for each object acquired by the acquisition unit 5a, automatically structures the graph from the initial graph, and interprets the input data.
  • the interpreting unit 5b appropriately executes type conversion of the objects associated with each node and each link of the graph to the lower concept side or the higher concept side, and also determines the relationship between the objects according to the type conversion. Vary the structure of the graph it represents.
  • a linguistic expression is generated as a result of the interpretation (type conversion and graph structure change) and sent to the integration unit 5c.
  • the integration unit 5c receives the language expression sent from the interpretation unit 5b and holds it as information. Also, the integration unit 5c refines information based on inference processing. Further, the integration unit 5c executes graph conversion according to the linguistic expression to reflect information in the graph (integration of information by graph conversion). Graphs that have undergone conversion processing according to linguistic expressions have the aspect of integrated data that integrates information. The integrated data (model of the representation target) for the representation target of the input data is generated as this graph (the object group constituting the graph and the entire structure of the graph). The integration unit 5c refines the information based on the inference processing based on the relationship between the superordinate concept and the subordinate concept of the object corresponding to each word of the linguistic expression. In addition, integration of information by transforming the graph is executed based on the relationship between the superordinate concept and the subordinate concept of the object associated with each node and each link of the graph.
  • the data integration device 2' integrates a plurality of pieces of fragmentary information extracted from a plurality of data as materials to construct desired data.
  • the data integration device 2' automatically converts the data structures of objects with different representation formats, automatically searches for the path of type conversion, and further automatically configures integrated data.
  • FIG. 5 Operation of Data Integration Apparatus
  • Data entered in the input section e.g., design drawings, etc.
  • the input section e.g., design drawings, etc.
  • multiple Information verbal expressions
  • Extracted information and information input at the input unit are appropriately refined by inference processing and integrated by graph conversion according to the information (language expression) to create a three-dimensional bridge.
  • a digital bridge such as a model is constructed and output from the output unit.
  • the process of automatic digital bridge construction includes the following three steps.
  • the linguistic expression is information expressed in a linguistic format similar to natural language.
  • Information extraction process Information is extracted in a linguistic format similar to natural language from graphs obtained as a result of interpreting multiple input data including drawings. For example, from the structure of the graph and the internal data of the objects that make up the graph, we identify the actual object represented by the drawing, and summarize the linguistic expression as a description of that object. For example, the following linguistic expression is extracted as a linguistic expression having a subject for specifying an object and a predicate representing the nature of the object.
  • Def there is a bridge; Def: Bridge has piers; Def: The bridge is named: "P1":; Def: The pier whose name is:"P1":is height:"Q(13m)":;
  • information is obtained as a set of linguistic expressions such as "Def: The name is:"P1": The height of the pier is: Q("13m"):” .
  • the node of the graph corresponding to the subject of the linguistic expression is identified, and the transformation of the graph corresponding to the predicate is given.
  • the linguistic expressions there may be those that describe the existence of specific nodes and those that describe the content of modifying the graph according to certain rules, and the graph is transformed according to each linguistic expression. .
  • the graph transformation corresponding to a certain linguistic expression is not defined, the information can be ignored and the graph transformation can be implemented later.
  • FIGS. 28A and 28B show the result of integrating the content of each language expression extracted in the information extraction process into one graph.
  • Fig. 28A is the result of integrating the following linguistic expressions into one graph.
  • FIG. 28B is the result of integrating the following linguistic expressions into one graph.
  • Def there is a bridge; Def: Bridge has piers; Def: The bridge is named: "P1”:; Def: The pier whose name is:"P1":is height:"Q(13m)”:; Def: beams on piers; Def: Beam height is: "Q(3m)”:;
  • the link portion of the graph expresses the relationship between nodes (for example, "part”, "name”, "height”, etc.).
  • linguistic expressions integrated by graph conversion need to be those extracted in the information extraction process, and linguistic expressions that are input by the user or other programs, etc., may be included.
  • the content of the linguistic expression may be engineering knowledge or some inference or presumption based on engineering knowledge.
  • a graph that integrates the contents of each linguistic expression is obtained by sequentially executing the transformation of the graph according to the linguistic expression.
  • the graph obtained in this way it is possible to output a 3D model of the structure represented by this graph.
  • the linguistic expression can use not only information extracted from drawings, but also linguistic expressions input from users or other programs. It is also possible to create a modified three-dimensional model. Therefore, for example, it is possible to obtain a three-dimensional model of an arbitrary structure by changing some elements of a CAD drawing of an existing structure.
  • FIG. 20 shows an example in which a three-dimensional model of a bridge pier is automatically constructed by trial.
  • FIG. 12A is a diagram showing how structure information is automatically extracted from the front view, plan view, and side view
  • FIG. 12B shows how a 3D model is automatically created from the structure information.
  • FIG. 10 shows.
  • Embodiments 1 and 2 have been described as examples of the technology disclosed in the present application. However, the technology in the present disclosure is not limited to this, and can be applied to embodiments in which modifications, replacements, additions, omissions, etc. are made as appropriate.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Geometry (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • Architecture (AREA)
  • Evolutionary Computation (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Artificial Intelligence (AREA)
  • Civil Engineering (AREA)
  • Structural Engineering (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一実施形態に係るデータ統合装置は、オブジェクトの型変換を自動実行するプラットフォームを備えた制御部と、獲得部、解釈部、統合部を有する。前記獲得部は、各データをプラットフォームのオブジェクトが構成要素であるグラフ、あるいは、オブジェクトが単語に関連付けられた言語形式の情報の集まりとして獲得する。前記解釈部は、グラフの構成要素をより下位概念側の型へ変換する解釈処理を実行する。前記統合部は、前記解釈過程で生成された情報と前記獲得部で獲得した情報を保持してグラフに反映させる統合処理を実行する。前記データ統合装置は、前記制御部が前記解釈処理と前記統合処理を繰り返し自動実行させることで動作する。

Description

データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システム
　本発明は、データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システムに関する。
　科学技術基本計画のSociety5.0が前提とするサイバー空間とフィジカル空間の高度な融合を現実的なコストで実現していくためには、新規構造物に対して新しい試みを実施していくだけでなく、古いインフラ構造物に対して膨大に蓄積されてきた設計図面等の資料を活用していくことが不可欠である。しかし、古い資料は基本的に人間が目で見て解釈するように表現されているため、広域かつ高解像度なシミュレーションへの活用には莫大なコストが必要となる。
　１９８０年代以降に、設計図面から３次元モデルを自動構築する研究は数多くなされてきたが（非特許文献１）、図面の要素（線や文字）をボトムアップに組み上げていく手法に頼っていたために、部分の解釈失敗が全体に波及して３次元化が破綻し、複雑な図面に対応できない困難があった。
　近年は、図面をCADシステムに取り込んで半自動で３次元化を行う技術が主流となっている。しかし、この技術の利用にはCADシステムと設計図面の両方の知識をもつ技術者が必要であり、多数の構造物の３次元化にはやはり膨大なコストを要する。
特開２０１１－１２３６４４号公報 特開平０４－２３１５１４２号公報 特開平０４－０３０２６５号公報 特開平０４－２７５６８４号公報 特開２０１８－１０９９７７号公報
「機械図面自動認識システム」、精密工学会誌、Vol.60,No.4, p524-529,1994 「地震応答解析モデルの堅牢な自動構築のための床形状判読手法の開発」、土木学会論文集Ａ１（構造・地震工学）、Vol.70,No.4（地震工学論文集第33巻）,I_1124-I_1131,2014 「特集　第２章　画像理解」、電気学会雑誌、１０５巻、５号、４０９－４１１頁、昭和６０年 「画像・映像の認識と理解のこれまでとこれから」、情報処理、Ｖｏｌ．５６、Ｎｏ．７、６２８－６３３頁、２０１５年７月 「異種ＧＩＳデータに記録された構造物の３Ｄ形状と属性情報の自動関連付け」、土木学会論文集Ａ２（応用力学）、Vol.70,No.2（応用力学論文集Vol.17）,I_631-I_639,2014
　設計図面を自動解釈して３次元モデルを自動構築する技術は古くから開発されてきているが、完全な情報抽出が難しく３次元モデルの汎用的で堅牢（ロバスト）な自動構築は実用化されていない。不完全な図面の自動解釈結果に対しても柔軟かつ堅牢に３次元モデルが構築できる汎用的な方法論が求められている。さらに、その３次元モデルは、多目的な用途、例えば高解像度な数値シミュレーションに使用可能であることが求められている。
　基本的に人間が目で見て解釈するように表現されていて、コンピュータがそのままでは情報を抽出できないデータを、「非構造化データ」と称する。例えば、2D-CAD図面は非構造化データであり、線や曲線、文字列等の要素から構成されているが、必ずしも要素の集まりがもつ「図」であるとか「表」であるなどの意味が明示的に記述されておらず、人間は目で見て「図」や「表」であると解釈し情報を読み取る。非構造化データには、2D-CAD図面の他に、ピクセルを要素とする画像や、点を要素とする点群データがある。また、一般に、非構造化データと呼ばれないデータについても必要な情報が直接抽出できない場合には非構造化データとみなしてよい。非構造化データを、その要素のデータと要素間の関係（位置関係を含む）に基づいてコンピュータが意味を自動的に解釈して断片的な情報を読み取る技術が求められている。
　2D-CAD図面に含まれる図や表は、2D-CAD図面で表現しようとするフィジカル空間の対象（例えば、ある構造物）の断片的な情報を表現したものであり、2D-CAD図面の表現対象そのもの（すなわち、フィジカル空間の対象）ではなく、表現対象の模型でもない。ここで、「模型」は表現対象のバーチャル空間における対応物を称している。また、「断片的な情報」は、必ずしも表現対象の模型を作成するために十分でなく、他の情報と統合して表現対象の模型を作成してもよい情報のことを称している。ある対象（例えば、構造物）について、低いコストでその対象の模型を作成するためには、個別の目的に応じて作成される、新規なデータから古い資料（データの一種）までの複数かつ異種のデータを活用することが求められ、複数のデータに分散している断片的な情報を統合して表現対象の模型を作成する技術が必要とされる。
　データ爆発といわれる急激なデータの増加と、数十年続いている計算機性能の指数関数的な向上に対応して、データを活用する技術を持続的に高度化していくためには、プログラムの高い再利用性が必要である。しかし、一般に、個別開発されるプログラムは個々の目的に最適化された独自の形式のデータを読み書きし、プログラムの間の連携のために、素朴にはプログラムの組み合わせの数だけのデータ変換プログラムが必要となる。これは再利用のコストが著しく高いことを意味し、素朴な対処で持続的に技術を高度化することは実現不可能である。この問題に対しては、標準の表現形式を定める対処が一般的であるが、表現形式を一律的かつ固定的に定めると、データ提供者およびデータ利用者が、データ形式を独自に工夫することを制限する。また、固定的な表現形式にすべてのプログラムが依存するために、技術が硬直化する。
　本発明は、データを活用するための技術を持続的に高度化するために、標準と定められた形式で表現されたデータと、個々の目的に最適化された独自形式のデータの両方が同時に利用可能となる疎結合の方法を提供する。また、新規なデータから古い資料までの幅広いデータから情報を抽出するためのデータ解釈装置、方法及びプログラムを提供する。更に、複数のデータに分散している断片的な情報を統合してデータの表現対象の模型を作成するデータ統合装置、方法及びプログラムを提供する。また、デジタル都市プラットフォームも提供する。
　本開示においては、課題を解決するための手段の一例として、２次元設計図面を堅牢に自動解釈し、解釈結果の精度に応じて異なる詳細度の３次元モデルを柔軟に自動構築するための手法を提示する。
　本願においては、図面の要素をボトムアップに組み上げるだけでなく、図形のコンテキストを自動的に特定することで、図形に適合する意味付けをトップダウンに推定しその意味付けに応じて図面から情報を抽出する図面解釈方法を開示している。これは、具体的には、図面の要素がノードに関連付けられたグラフを、グラフの構成要素間の関係に基づいて変化（自動構造化）させていくことで実現する。
　この方法は、もし解釈に失敗しても、グラフが自動構造化しない、つまり解釈の精度が向上しないだけで全体が破綻することのない堅牢な手法である。本研究では、この自動構造化手法を３次元モデルの自動構築でも採用する。これにより、図面の解釈の精度に応じて柔軟に詳細度の異なる３次元モデルを自動構築することが可能となる。本研究の手法で自動構築される３次元モデルは、グラフの構成要素間の関係に基づいて情報が整理されており、その形状だけでなく、構造物の内部構造や物性など多岐にわたる情報が保持され得るため、多目的な用途への応用が期待できる。
　また、本発明では、グラフの構成要素となるオブジェクト間の上位概念・下位概念の関係に基づいて自動的な型変換を実行するため、オブジェクト指向プログラミングが可能なインタプリタを構築する。データの解釈時およびデータの統合時に、オブジェクトは、自身の保持する内部データとグラフの構造に基づいて、適宜、より詳細な下位概念側のオブジェクトに上位概念側のオブジェクトから変換される（ダウンキャスト）。一般的なオブジェクト指向プログラミングにおいては、情報が足りないために適切な実行ができないダウンキャストが、グラフの構造とグラフの構成要素であるオブジェクト群の保持データから情報を補うことで、本発明の手法では可能である。
　すなわち、本発明は以下のとおりである。
［１］オブジェクトの型変換を自動実行するプラットフォームを備えたデータ統合装置であって、前記プラットフォームは、前記データ統合装置の制御部に設けられ、解釈部及び統合部を有しており、前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成し；
　前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行する；ように前記制御部を動作させる、データ統合装置。
［２］前記統合部は、前記解釈部により生成される前記情報に加えて、ユーザにより入力された言語形式の情報を、前記グラフに反映させることで、前記解釈部により生成される情報と前記ユーザにより入力された言語形式の情報とを統合する、［１］に記載のデータ統合装置。
［３］前記解釈部は、前記プラットフォームのオブジェクト間の関係を表すグラフに対して、オブジェクト同士の上位概念・下位概念の関係に基づいて、グラフの構成要素がより下位概念側の型へ変換されるように前記グラフの構造を変換する、［１］又は［２］に記載のデータ統合装置。
［４］前記統合部は、前記統合部が保持している言語形式の情報に対して、オブジェクト同士の上位概念・下位概念の関係を考慮した推論処理を実行し、前記統合部が保持している情報の変換を行う、［１］乃至［３］の何れか一項に記載のデータ統合装置。
［５］前記制御部は、前記言語形式の情報が自然言語類似であり、ユーザにより入力された自然言語あるいは自然言語類似の単語あるいは文に応じて、ユーザへの出力を生成する、［１］乃至［４］の何れか一項に記載のデータ統合装置。
［６］オブジェクトの型変換を自動実行するプラットフォームを用いたデータ統合方法であって、前記プラットフォームは、コンピュータの制御部に設けられ、解釈部及び統合部を有しており、前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成するステップと；前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行するステップ；を実行する、データ統合方法。
［７］コンピュータが実行するプログラムであって、当該コンピュータの制御部に備えられ、解釈部及び統合部を有し、オブジェクトの型変換を自動実行するプラットフォームにおいて、前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成するステップと；前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行するステップ；を行うように前記コンピュータの制御部を動作させる、プログラム。
［８］オブジェクトの型変換を自動実行するプラットフォームと要素プログラムを備えたシステムであって、前記プラットフォームは、オブジェクト同士の上位概念・下位概念の関係に基づく型変換の経路探索と自動実行により、要素プログラムの入力形式を抽象化して適用範囲を拡大することで要素プログラム間の疎結合を実現している、デジタル都市構築システム。
［９］前記プラットフォームは、前記システムの制御部に備えられ、解釈部及び統合部を有しており、前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成し；前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行する；ように前記制御部を動作させる、［８］に記載のデジタル都市構築システム。
［１０］前記プラットフォームの前記解釈部及び統合部により統合されたデータの表現対象が都市又は構造物である、［８］又は［９］に記載のデジタル都市構築システム。
　本発明は、データの表現形式をデータの意味に基づいて自動変換することでプログラムの適用範囲を拡大させ、プログラムの再利用性を向上させることが可能なインタプリタであるデータ処理プラットフォームを、実現することができる。データ処理プラットフォームは、標準と定められた形式で表現されたデータと、個々の目的に最適化された独自形式のデータの両方が同時に利用可能であり、データを活用するためのプログラムを蓄積して技術を持続的に高度化することができる。
また、データ処理プラットフォームを用いて、新規なデータから古い資料までの幅広いデータから情報を抽出するためのデータ解釈装置、データ解釈方法及びプログラムを、実現することができる。
更に、データ処理プラットフォームを用いて、複数のデータに分散している断片的な情報を統合してデータの表現対象の模型を作成するデータ統合装置、データ統合方法及びプログラムを、実現することができる。
実施の形態１に係るデータ解釈装置の物理的な構成を示す図である。 「ソース１」、「ソース２」、「ソース３」の表現形式のデータを、「ターゲット１」、「ターゲット２」、「ターゲット３」の表現形式のデータに変換することを模式的に示す図である。 「ソース１」、「ソース２」、「ソース３」から、「ターゲット１」、「ターゲット２」、「ターゲット３」への変換の媒介として、「媒介データ」を設定することを模式的に示す図である。 自動データ変換による媒介データの別の状況を示す図である。 本発明のインタプリタにおけるデータ自動変換の例を示す図である。 CADデータにより構成されている、橋脚構造を示す橋脚構造一般図の例である。 橋脚構造一般図における「表題欄」を示す図である。 「橋脚構造一般図」において線で構成されるオブジェクト（クラス名「LineBuf2D」）を示す図である。 線の集まりのオブジェクト（クラス名「LineBuf2D」）からサブクラス「CellSet」でないものが除外され、６個のオブジェクトが「CellSet」であると解釈されたことを示す図である。 クラス「CellSet」のオブジェクトに対して、CADデータから抽出した文字列等を入力し、「Table」のクラスに解釈されることを示す図である。 クラス「Table」のオブジェクトにおいて、「表題欄」の項目が存在するか分析及び分類し、存在すればクラス「表題欄」のオブジェクトに解釈されることを示す図である。 線の集まりのオブジェクト（クラス名「LineBuf2D」）からサブクラス「View」でないものが除外され、８個のオブジェクトが「View」であると解釈されたことを示す図である。 図９に示す８個のクラス名Viewのオブジェクトのうち、主構造物（D-STR）レイヤに属していないものが除外されて、残りの７個のセルを示す図である。 クラス「View」のオブジェクトに対して、CADデータから抽出した、表題となる文字列を入力し、「橋脚正面図」特有の項目を持つものを、クラス名が「橋脚正面図」であるオブジェクトであると解釈することを、示す図である。 正面図、平面図、及び側面図から、構造物の情報が自動抽出される様子を示す図である。 構造物の情報から３次元モデルが自動作成される様子を示す図である。 2D-CAD図面に含まれる「橋脚正面図」が段階的に認識されることを示す図である。 2D-CAD図面に含まれる「下部工座標表」が段階的に認識されることを示す図である。 本開示に係るデータ解釈装置及びデータ解釈方法では、2D-CAD図面認識のための段階が階層化していることを示す図である。 本開示では、2D-CAD図面の認識手法として、主として（１）「情報の入力」と、（２）「分析・解釈」との、二通りが設定されていることを示す図である。 デジタル橋梁自動構築手法の流れを示す図である。 図面解釈のための初期グラフを示す図である。 図面解釈におけるグラフの自動構造化例を示す図である。 ２次元CAD図面に基づくデジタル橋脚の自動構築を示す図である。 表題欄の認識過程を示す図である。 実施の形態２に係るデータ統合装置の物理的な構成を示す図である。 個別に開発する場合のデータ処理の実装方法を示す図である。 標準形式を利用する場合のデータ処理の実装方法を示す図である。 自動変換を利用する場合のデータ処理の実装方法を示す図である。 表現形式と変換経路がつくるネットワークのトポロジーの一例として標準の表現形式を中心とする星形のネットワークを示す図である。 表現形式と変換経路がつくるネットワークのトポロジーの一例として表現形式の自動変換に基づく自由なネットワークを示す図である。 標準形式による固定化されたデジタル都市の形態を示す図である。 開発持続可能性を備えるデジタル都市構築システムの形態を示す図である。 表現形式の自動変換の例をL1の一項関数φの場合について示す図である。 2D-CAD図面「006_P2橋脚構造一般図.dxf」を解釈するためのスクリプトの例である。 各言語表現の内容を統合したグラフの一例を示す図（その１）である。 各言語表現の内容を統合したグラフの一例を示す図（その２）である。 各言語表現の内容を統合したグラフの自動構造化過程の一例を説明するための図である。
　以下、適宜図面を参照しながら、実施の形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になるのを避け、当業者の理解を容易にするためである。
　なお、発明者は、当業者が本開示を十分に理解するために添付図面および以下の説明を提供するのであって、これらによって特許請求の範囲に記載の主題を限定することを意図するものではない。
１．データ処理プラットフォームの研究
　はじめに、データ処理プラットフォーム（Data Processing Platform：DPP）について、「１．１．研究の目的と内容」、「１．２．データの表現形式が自動変換されることの意義と重要性」、「１．３．データ間の論理的な同等性の定義」、「１．４．DPPの要件と実装」、及び、「１．５．開発した理論および実装に対する結論」の節（それら節を、以下「本研究及び考案に係る開示」と称する）にて説明する。当該データ処理プラットフォームは、本発明者の研究に係るものであり、デジタル都市を構築するためのインタプリタとして機能する。
１．１．研究の目的と内容
１．１．１． デジタル都市の必要性
　地震や津波が都市にもたらす被害をスパコンで数値化する試みは、交通や経済に与える影響の評価など、学際的な研究に進展している。そして、その成果となるプログラム群は、高性能計算機とともに利用され、総合的な防災に役立てられることが期待されている。しかし、計算機とプログラムがあっても、災害を模擬する場となるデジタル都市がなければ実際の都市には適用できない。
１．１．２．デジタル都市の要件
　デジタル都市は、どのようなものであるべきか。少なくとも、被害の数値化に必要な情報を自在に抽出できなければならない。また、「データ爆発」や「計算機性能の指数関数的向上」が生じている中、すぐに陳腐化する固定的なものではなく、柔軟に新データ・新プログラムに対応して、持続的に発展可能なものであるべきである。
１．１．３．デジタル都市構築の困難: 異種性
　デジタル都市構築の課題は、多種多様なデータから自在に情報を抽出することと、デジタル都市の持続的な発展を可能とすることの両立であるが、これは実は容易ではない。従来、自在な情報抽出のためにはデータの表現形式を標準化して統一する方策がとられるが、その表現形式は固定的であるからである。また、実情として、データは作成時の目的に応じた最適な表現形式で記録され、既存のデータの表現形式は統一されていない。
１．１．４．デジタル都市構築、従来手法と予測される困難
　それでも、当面の目的のために必要な標準化を行い、デジタル都市を構築することはできる。しかし、この方法は、目的が変わるたびに、デジタル都市とその構築のためのプログラムを初期段階から開発する必要が生じる非効率なものであり、デジタル都市の複雑さが再開発に耐えられない段階になった時点で、デジタル都市構築技術の発展の頭打ちをもたらすことが予想される。
１．１．５．目的
　本来、標準化された機械部品の形状などと異なり、データの表現形式はそのデータの意味・内容が同等であれば柔軟に変更可能であり、特定の表現形式を入力として仮定したプログラムであっても、自動的に表現形式を変更する仕組みがあれば異なる形式で表現されたデータに適用が可能である。例えば、直交座標系で表現された二次元平面上の２点間の距離を計算するプログラムに対して、極座標系など他の座標系で表現された点が与えられた場合に、座標系の自動変換を行うことで一つのプログラムを複数の表現形式に対して共通利用可能とすることができる。もしこの仕組みが汎用的に実現できれば、表現形式に依存しない情報抽出プログラムが容易に作成可能となり、また、データやプログラムの入れ替えも容易となる。
　本研究及び考案に係る開示では、表現形式を自動変換する仕組みをもつインタプリタ（これをデータ処理プラットフォーム（DPP）と称する）を構築し、デジタル都市を構築するための要素プログラムをそのライブラリとして蓄積することを提案する。「プラットフォーム」とは、要素プログラムを集約して連携させる土台として機能するものを指す。本明細書に開示する「データ処理プラットフォーム（DPP）」についても、プラットフォームの語は、DPPが要素プログラムを集約して連携させる土台として機能することを意味している。
　DPPとそのライブラリからなるシステムにおいて、新しいデータや新しいプログラムを取り込むことは、プログラムの単純な追加や置き換えによって可能であり、システムの高度化がデジタル都市の高度化に対応する。また本研究及び考案に係る開示では、このシステムを実現するため、表現形式の異なるデータ間の論理的な同等性を定義し、その定義に従う表現形式の自動変換方法を提示することを目的とする。
１．１．６．内容
　本研究及び考案に係る開示の内容は次のように要約される。デジタル都市の構築においてデータの表現形式が自動変換されることの意義と重要性について「１．２．」で強調し、その変換のための理論、特にデータ間の論理的な同等性について「１．３．」で説明する。そして、その理論に対応する実装について「１．４．」で説明する。「１．５.」では、開発した理論および実装に対する結論を述べる。
１．２．データの表現形式が自動変換されることの意義と重要性
１．２．１．この節の目的
　この節「１．２．」では、デジタル都市の材料となるデータの表現形式の多様性とその多様性がもたらす利用の際の課題について説明する。また、データの表現形式をデータの意味に基づいて自動変換することによって、通常はデータの表現形式によって制限されるプログラムの適用範囲が拡大し、プログラムの再利用性が向上することを説明する。そして、この再利用性の向上によって、デジタル都市を自動構築するシステムが、要素プログラムを柔軟に追加・変更できる疎結合なシステムとして実現可能であることを説明する。
１．２．２．データの表現形式の多様性と利用の課題
１．２．２．１．各分野における表現形式に対する工夫
　デジタル都市の材料となるデータは、通常、何らかの特定の目的のために個別に作成されたデータであり、その表現形式は、それぞれ目的や使用方法に応じて工夫されている。
　例えば、一般に、データの共有は標準化機構が定めた形式で行われ、人間も読めるテキスト形式のデータであることが多いが、高性能計算ではバイナリ形式の採用が通常であり全体を高速に読み書きできるよう同種のデータが一列に並べられることが多い。また、長期間保存するデータの検索では一部へのアクセスが通常であり、検索対象の意味・内容のまとまりに基づいたデータ構造が選択され得る。同等な意味・内容をもつデータであっても、多様な処理目的に応じて多様な表現形式が計算の主体やデータの管理主体によって定められ利用されている。
１．２．２．２．デジタル都市構築における困難１：プログラム開発における組み合わせ爆発（図２３Ａ）
　デジタル都市の構築と利用は、複数のデータを入力として目標のデータを出力する処理の体系的な適用と捉えることが可能であり、各々の処理は入力データと出力データによって特徴づけられる。一般に、同等な意味・内容をもつ処理に対しても、データの表現形式が異なれば異なるプログラムを実装する必要があり、表現形式が多様であることは著しく開発効率を低下させる恐れがある。例えば、二つの物体の距離を出力する簡単な処理に対しても、図２３Ａのように入力データの表現形式の組み合わせごとに実装が必要であり、容易に組み合わせ爆発が生じる。
　図２３Ａ～図２３Ｃは、３通りのデータ処理の実装方法を示す図である。矢印はデータの表現形式の変換を表す。図２３Ａは、個別に開発する場合であり、図２３Ｂは、標準形式を利用する場合であり、図２３Ｃは、自動変換を利用する場合である。なお、図２３Ａ～図２３Ｃでは、Ｆ（Ｘｉ，Ｙｊ）は表現形式Ｘｉのデータｘｉと表現形式Ｙｊのデータｙｊを入力して、所定のデータ処理を行う関数を表している。また、ｉ≠ｉ'であればＸｉとＸｉ'の表現形式は異なり、同様に、ｊ≠ｊ'であればＹｊとＹｊ'の表現形式は異なるものとする。
１．２．２．３．デジタル都市構築における困難２：標準フォーマットの問題
　もし、図２３Ｂのように、利用するデータの表現形式を統一し、処理プログラムの実装を標準の表現形式に対してのみ行えば、類似の実装を繰り返すことを避けることができる。しかし、この方法論は、目的に適合した表現形式を設計して利用することを阻害するため、特に高性能計算の分野では実現可能ではない。高性能計算の分野で開発されるプログラムは、多くの場合に、計算性能の向上を目的として開発者が独自に設計した表現形式のデータを入力とするからである。標準化機構によって標準の表現形式が定められることの有用性は言うまでもないが、高性能計算分野で開発された高性能なプログラムを応用した数値シミュレーションをデジタル都市に適用するためには、多種多様な表現形式のデータが取り扱える、データとプログラムの連携に関する新しい方法論が必要である。
１．２．３．自動データ変換による処理プログラムの再利用
１．２．３．１．自動変換による処理プログラムの再利用（経路探索含む）
　図２３Ｃに示すように、データの表現形式をデータの意味に基づいて自動変換することで、プログラムの適用範囲を拡大させ、プログラムの再利用性を向上させることが可能である。通常、プログラムの適用範囲はデータの表現形式に依存するが、あらかじめ表現形式間にデータの意味・内容を保つ変換経路を定義し、この変換経路をたどる経路探索が自動で実施される機能を実装しておけば、プログラムの適用範囲は意味・内容に依存する形に拡大する。また、経路探索の方法を適切に定義することで複数の処理プログラムの実装から最適なものを選択して実行することも可能と考えられる。
１．２．３．２．媒介データ・標準の相対化
　図２４のように、表現形式をノード、変換経路をリンクとするネットワークを考えることができる。ここで、図２４は、表現形式と変換経路がつくるネットワークのトポロジーである。図２４Ａは、標準の表現形式を中心とする星形のネットワークであり、図２４Ｂは、表現形式の自動変換に基づく自由なネットワークである。
　標準の表現形式に基づく方法論は、図２４Ａのように、このネットワークのトポロジーを標準の表現形式を中心とする星形に制限するものであり、標準の表現形式は、データとプログラムを仲介する中間データ形式の役割を果たす。一方で、表現形式の自動変換に基づく方法論では、ネットワークのトポロジー構成が自由であり、データとプログラムが結合する位置も自由である（図２４Ｂ参照）。また直接プログラムと結合していないデータも自動変換によって間接的に自動結合されるため、データとプログラムの入れ替えが容易である。そして、このネットワークは新しい表現形式や処理プログラムの追加により成長が可能である。ネットワークの成長の結果として、星形のトポロジーが構成されることもあり得るが、中心に位置する表現形式は、トップダウンの形で定義される標準の表現形式と異なり、ボトムアップの形で自然に定まるデファクトスタンダードな表現形式である。
１．２．３．３．データの利用者負担の低減
　近年では、デジタル都市の材料として有用なオープンデータが、クリアリングハウスを通じて数多く公開・共有されている。しかし、オープンデータの表現形式は多種多様であり、応用プログラムの開発者が複数のデータを組み合わせる際には、多くの場合に、データ一つ一つの表現形式を理解して、データから情報を抽出するプログラムを開発することから始める必要がある。もし表現形式の自動変換に基づく方法論を実現するシステムがあり、情報抽出プログラムが共有できれば、オープンデータと既開発の処理プログラムが自動的に結合され、応用プログラムの開発が容易になる。また、そのシステムでは、データの本質的でない詳細、すなわち特定の表現形式に固有の実装を意識せずにデータを取り扱うことができるため、データの利用者の学習負担も低減される。
１．２．３．４．処理プログラムのラップによる再利用性の向上
　表現形式の自動変換がデータの実装の詳細を隠蔽する一方で、プログラムの再利用性を高める別の仕組みであるアプリケーションプログラミングインターフェース（API）は、プログラムの実装の詳細を隠蔽する。Web APIによる都市情報の提供は、前述の情報抽出プログラムの共有にあたり、応用プログラムの開発コスト低減が期待される。このため、すでに都市の様々な情報がWeb APIとして提供されており、その数は今後も増加することが想定されるが、この状況は独自形式の有用なデータが増加することと類似している。APIを備えた応用プログラムも、その機能が入力と出力のデータの表現形式で特徴づけられるため、表現形式の自動変換を適用することが可能である。この場合に、入力データはAPIに対する指示を表現したものとなる。
１．２．４．デジタル都市構築システム
１．２．４．１．デジタル都市の定義
　都市の構成要素である構造物の耐用年数は長く、一方で研究開発の進展は速い。このため、設計、施工、維持管理、の各段階で生じるデータを蓄積しておき、後に開発される技術を適用して多目的に利用することが想定される。実際に、既存の構造物に対して膨大なデータが保存されており、そのデータの有効活用が進められている。例えば、数値シミュレーションを用いた地震や津波の被害推定がその一例である。数値シミュレーションを実施するためには、相応の詳細度をもつ都市の模型をコンピュータ上に表現する必要があり、その模型は、複数のデータから、都市の情報を断片として抽出し、現実の都市の構成要素に対する知識を表現したデータへと統合することで構築される。本研究及び考案に係る開示では、この統合された知識としての都市の模型をデジタル都市と定義する。デジタル都市は、数値シミュレーションの入力データなど、目的のデータを作成するための情報源として利用する。
１．２．４．２．標準形式に基づくデジタル都市
　デジタル都市の構築と利用の素朴な形態は、図２５Ａのように、都市の構成要素をすべて表現可能な標準の形式を定めて、材料となるデータからその形式で表現されたデータを作成し、標準形式のデータに対して実装されたプログラムを適用して目的のデータを作成することである。しかし、この形態が基づいているデータとプログラムの連携に関する方法論は、前述の通り、実際の多様な表現形式に対応できない。また、すべてのプログラムが標準形式に依存するため、標準形式の変更に多大な労力を要する。新しい標準形式に合わせて既存の古い標準形式のデータを手作業で変換する作業も膨大である。その結果として、都市の数値的な表現は固定化され、技術の発展を阻害する。
１．２．４．３．デジタル都市構築システム
　本研究及び考案に係る開示では、デジタル都市の構築と利用の形態として、図２５Ｂのように、表現形式を自動変換する仕組みをもつ独自創作のインタプリタであるDPPを土台として、デジタル都市を構築するための要素プログラムを蓄積するデジタル都市構築システムを開発し、デジタル都市の材料データと目的データをそれぞれその入力と出力とすることを提案する。このシステムでは、プログラム間がデータを介して結合され、データとプログラムの間の結合がデータの表現形式ではなく、意味・内容に依存する。このことは、意味・内容が同じであれば表現形式の違いに依らず結合を柔軟に変更可能であることを意味する。要素プログラムを柔軟に追加・変更できる疎結合なシステムを利用することで、重複した開発を避けて技術の頭打ちを防ぐ設計を早期から採用することは、デジタル都市構築技術の発展にとってきわめて重要である。
１．３．データ間の論理的な同等性の定義
　異なる形式で表現された二つのデータが同等であることは、あるデータを異なる形式で表現された別のデータで代用する正しい置き換えが相互に可能であることである。二つのデータが正しく置き換え可能であるための条件について、もし明確な定義がなければ、置き換えたデータから本来と異なる意味・内容が抽出され得る。この節「１．３．」では、論理的に正しい置き換えが常に可能となるように、表現形式が異なるデータ間の論理的な同等性を、述語論理を用いて定義する。
１．３．１．データ表現間の上位概念・下位概念の関係
　データの表現形式を自動変換する基礎となる、データ表現間の論理的な同等性を定義するため、データ表現全体の集合を議論領域D1とした述語論理L1を考える。ここで、データの各表現形式はL1の1項述語に対応し、その1項述語の値が真となるD1の部分集合がその形式で表せるデータ表現の全体とする。二つのデータ表現が論理的に同等であることは、D1の元であるデータ表現間の上位概念・下位概念の関係を表すL1の2項述語⇒が双方向に成立することと定義する。なお、「下位概念」という用語の代わりに「外延」、「上位概念」という用語の代わりに「内包」、「上位概念・下位概念の関係」という用語の代わりに「外延・内包関係」という用語がそれぞれ用いられてもよい。
　2項述語⇒は、次の反射律および推移律を満たすものとして定義する。ただし、→は論理記号である。
　∀x（x ⇒ x）
　∀x∀y∀z（（x ⇒ y）&&（y ⇒ z）→（x ⇒ z））
　以降、x ⇒ yが成立していることを、xはyを上位概念にもつ、あるいは、yはxを下位概念にもつということにする。また、２項述語⇔を次のように定義し、
　∀x∀y（（x ⇔ y）←→（（x ⇒ y）&&（y ⇒ x）））
x⇔yが成立しているとき、xとyは同等であると定義する。
　そして、L1のn項関数φおよびn項述語ψは次の2条件を満たすとき正則であると呼ぶことにする。
　∀x∀y（（x ⇒ y）→（φ（…, x, …）⇒φ（…, y, …）））　（式１）
　∀x∀y（（x ⇒ y）→（ψ（…, y, …）→ψ（…, x, …）））　（式２）
　例えばx, yをそれぞれログハウスと家のデータ表現、Roof（a）をaに対してaの屋根のデータ表現を対応させる正則な1項関数とすると、一番目の式から、（x ⇒ y） → （Roof（x） ⇒ Roof（y）） が成り立つ。これは、「ログハウスが家であれば、ログハウスの屋根は家の屋根である。」ということを意味する。また、HasRoof（a）を「aには屋根がある」という属性を表す正則な1項述語とすると、二番目の式から（x ⇒ y） → （HasRoof（y） → HasRoof（x）） が成り立つ。これは、「ログハウスが家であるならば、家に屋根があればログハウスにも屋根がある。」ということを意味する。
　恒等関数は、正則関数であり、常に真を返す述語と常に偽を返す述語は正則述語である。一方で、一般には、データ表現間の上位概念・下位概念の関係について、反射律および推移律の成立を課しただけでは、どの関数・述語が正則関数・正則述語であるか定まらないし、二つのデータ表現間が上位概念・下位概念の関係にあるかどうかも定まらない。本研究及び考案に係る開示では、最初に基本的な正則関数・正則述語だけが定義されており、その後に正則関数・正則述語を逐次的に定義していく状況を考え、既定義の任意の正則関数および正則述語に関して式１と式２を満たせば、二つのデータ表現が上位概念・下位概念の関係にあると定義する。これは、正則関数・正則述語の定義によって、対象の意味付けが行われることを意味する。本研究に係る開示での目的は、表現形式間の本質的でない差異を捨象することであり、表現形式に依らずに値が決定できる関数や述語を正則関数および正則述語と定義することで、データ表現間の上位概念・下位概念の関係を決定する。
　一例として、2次元平面上の点を直交座標系で表現する表現形式Cartesian2Dと、2次元平面上の点を極座標系で表現する表現形式Polar2Dについて考える。Cartesian2Dのデータ表現は、x座標とy座標の組（x, y）であり、Polar2Dのデータ表現は、動径rと偏角θの組（r, θ）である。2次元平面上の点の位置は、データ表現によらず、与えられた直交座標系に対してx座標とy座標を測ることができる。例えば、直交座標系と極座標系がx = r cosθ, y = r sinθと関係づけられているとき、Polar2Dのデータ表現（r, θ）に対しては、この関係式からx座標とy座標を測ることができる。ここで、x座標とy座標の測量を、2次元平面上の点に対して実数の表現形式Realのデータ表現を対応させる正則関数と定義すると、Polar2Dのデータ表現がCartesian2Dのデータ表現の下位概念である場合には、式１より二つのデータ表現に対するx座標とy座標の測量結果が同等、すなわち二つのデータ表現が同一の点を表す。
　別の例のため、2次元平面上の色のついた点を、x座標とy座標、RGB値の組（x, y, r, g, b）で表現する表現形式 Cartesian2D_RGB を考える。x座標とy座標の測量はCartesian2D_RGBのデータ表現に対しても可能であり、Cartesian2D_RGBのデータ表現がCartesian2Dのデータ表現の下位概念である場合には、先の例と同様に、二つのデータ表現に対するx座標とy座標の測量結果が同等で、二つのデータ表現が同一の点を表す。
１．３．２．表現形式間の上位概念・下位概念の関係
　前小節「１．３．１．」では、データ表現間の上位概念・下位概念の関係を定義した。この小節では、L1の1項述語全体の集合を議論領域D2とする述語論理L2を導入し、L1の1項述語間の関係として上位概念・下位概念の関係を捉えなおす。これは、1項述語名をラベル、各データ表現を指示対象とした記号間の関係としてデータ間の上位概念・下位概念の関係を捉えることを意味し、データの性質とデータの表現方法を分離して扱うことを可能とする。具体的には、ある情報をデータとして記録する際に、先にそのデータの性質をL2において論じておき、その後にL2で表現された性質をもつようにそのデータの具体的な表現方法を決定することを可能とする。
　L1の1項述語A,BがL2において上位概念・下位概念の関係にあることを、A,BがL1において次の関係式を満たすことと定義する。
　∀x（A（x） → ∃y（B（y） && （x ⇒ y）））　（式３）
この式より、L2においてもL1においてと同様に、上位概念・下位概念の関係について反射律と推移律が成立することがただちにいえる。また、それぞれ条件∀x（T（x））, ∀x（￢F（x））を満たすL1の特殊な二つの1項述語T,Fを考えると、Tはすべての1項述語を下位概念にもち、Fはすべての1項述語を上位概念にもつ。
　L1の各データ表現に対して、そのデータ表現に対してだけ値を真とするL1の1項述語を考えることが可能であり、その1項述語はD2の元である。本研究及び考案に係る開示では、表記を簡単にするため、L1のデータ表現をa と記したときに、このデータ表現 aに対応するD2の元も同様にa と記すことにする。ただし、データ表現は小文字で表記し、大文字で表記するデータの表現形式と区別する。式３により、あるデータ表現a, bがL1で a ⇒ b の関係にあるとき、L2においても a ⇒ b の関係が成立する。また、ある表現形式 A とそのデータ表現 aとの間には、式３より、L2において a ⇒ A が成立する。
　式３の定義のもとで、L1の正則関数・正則述語は、次のようにL2の正則関数・正則述語に拡張することができる。まず、L2におけるn項正則関数φの値はL1の1項述語であり、その1項述語に対応するD1の部分集合を、L2における関数φの各引数、すなわちL1の1項述語、をそれぞれ真とする全てのL1の元の組に対して計算したL1における関数φの値全体の集合と定義する。また、L2におけるn項正則述語ψの値が真であることを、その述語の各引数、すなわちL1の1項述語、をそれぞれ真とする任意のL1の元の組に対して、L1の対応する述語ψの値が真となることと定義する。このとき、拡張されたL1の正則関数・正則述語に対して、L1における式１と式２に対応する式４と式５が、L2においても成立する。
　∀A∀B（（A ⇒ B）→（φ（…, A, …）⇒φ（…, B, …）））　（式４）
　∀A∀B（（A ⇒ B）→（ψ（…, B, …）→ψ（…, A, …）））　（式５）
　ある表現形式とそのデータ表現の関係は、オブジェクト指向プログラミングにおけるクラスとインスタンスの関係に対応し、上位概念・下位概念の関係は継承関係に対応する。この観点から、式５を1項述語に関する式に特殊化したものは、オブジェクト指向プログラミングにおけるリスコフの置換原則に対応する。ただし、本研究及び考案に係る開示では、「クラス」と「データ型」（単に「型」とも記す）を同義語とする。
　真理値をデータとして表現する表現形式を定義すると、述語が関数として定義できることは重要である。このことは、正則述語を使わずに正則関数のみでデータを表現することができることを示す。また、真理値の定義の仕方によって、多値論理を表現することもできる。このことから、以降では正則関数に焦点を絞って議論する。
　L2においてA ⇒ B であるとき、L1において
　∀x（A（x） → （B（B〈A〉（x）） && （x ⇒ B〈A〉（x））））
を満たすAからBへの写像B〈A〉が少なくとも一つ存在し、この写像B〈A〉を自動変換写像と呼ぶこととする。自動変換写像が実装されているとき、データの表現形式を自動変換することが可能となる。自動変換写像とD2の元は、圏論における射と対象に相当すると考えられ、一項正則関数は共変関手に相当すると考えられる。
１．４．DPPの要件と実装
　この節「１．４．」では、DPPの要件と実装について説明し、前節「１．３．データ間の論理的な同等性の定義」で定義したデータ間の上位概念・下位概念の関係に基づいて、DPPがデータの表現形式を必要に応じて自動変換（すなわち、型変換を自動実行）し、あらかじめ登録された処理プログラムに適用する方法について説明する。
１．４．１．データ処理プラットフォームと、一般的なオブジェクト指向プログラミングとの特性の差異
　以下に、データ処理プラットフォームと、一般的なオブジェクト指向プログラミングとの特性の差異を示す。
Figure JPOXMLDOC01-appb-T000001
　本開示に係るDPPは、表１に示すように、一般的なオブジェクト指向のプログラミングとは異なる考え方に基づくものである。一般的なオブジェクト指向のプログラミングでは、継承関係の定義において、データ構造の共有が条件とされている。それに対して、DPPでは、継承関係の定義において、データ構造の共有は要件とされていない。かわりに、上位概念・下位概念の関係があることが、クラス間の継承関係が成立する条件とされている。
　DPPにおいて、ユーザは、データ構造の共有という制約を受けずにクラス間の継承関係を定義することが可能である。自動的な（暗黙の）型変換の回数に制限はなく、型を変換する最適な経路が自動で探索され、探索された経路に沿って必要な回数の変換が自動実行される。DPPの型変換においては、論理的に同等な型の変換（同値キャストと称する）に加えて、下位概念側への型変換（ダウンキャストと称する）と上位概念側への型変換（アップキャストと称する）の両方が自動実行される。ただし、ダウンキャストはオブジェクトごとに変換先の型へ変換できる条件を定義しておき、その定義が満たされた場合にのみ実行される。
　本発明者は、インタプリタとして機能するDPPを、C++によって記述した。当然のことながら、当業者であれば、本明細書の記載に従い、同様のインタプリタを作成することができ、そのようなインタプリタによって実装される本開示のデータ処理プラットフォーム、並びに当該プラットフォームを備えた装置、方法、プログラムもまた、本発明の範囲に含まれる。
　DPPを記述する言語も、C++に限らずとも、本明細書に記載する要件と同等の要件を満たし、同等の実装が可能である限り、任意の他の言語で記載されたものであってよい。
１．４．２．要件及び実装
　本研究及び考案に係る開示におけるデジタル都市構築システムは、表現形式を自動変換する仕組みをもつ本発明開示のインタプリタ（DPP）を土台として、デジタル都市を構築するための要素プログラム群が蓄積されて構成されており、材料データからデジタル都市を構築し、目的のデータを作成する。このDPPの実装にあたり、次の３点を要件として考慮する。
（要件１）デジタル都市構築システムに処理を指示するためのインタフェースを備えること。
（要件２）既存の処理プログラムのラッパーとして機能すること。
（要件３）処理プログラムを個別開発可能なライブラリとして蓄積可能であること。
　前節「１．３．」で触れたとおり、ある表現形式とそのデータ表現の関係は、オブジェクト指向プログラミングにおけるクラスとインスタンスの関係に対応し、上位概念・下位概念の関係は継承関係に対応する。この対応に従って、デジタル都市構築システムの利用者は、DPPに一種のオブジェクト指向言語を用いて処理を指示することとする。実装の詳細は後述するが、DPPによって理解される言語は、通常と異なり、継承関係にあるクラス間でデータ構造を共有する必要がなく、個々のクラスのデータ構造を自由に設計可能であり、また、関数適用時に必要に応じて継承関係を辿る経路探索と型の自動変換が行われる。
　既開発のプログラムをDPPに組み込む際に、古いプログラムの機能を新しい言語で実装し直すのは非効率的である。DPPでは、C++言語のクラスと関数をDPPのクラスと関数としてラップして取り扱えるように実装する。これにより、DPPは、既開発のデータとプログラムを本研究及び考案に係る開示の方法論で疎結合に連携させることが可能である。
　DPPでは、クラスの定義とそのクラスに関連する処理プログラムを個別にコンパイルして動的ライブラリにまとめられるよう実装する。ライブラリは必要に応じてロードされ、ライブラリ内で定義されている継承関係に応じた変換経路の探索と自動変換が実行される。DPPの利用者は、独自の表現形式や処理プログラムをライブラリ化してロードすることで、システムを自由に拡張することが可能である。
１．４．３．自動変換の実装と処理プログラムの適用方法
　表現形式間に定義された自動変換写像を変換経路として辿ることで表現形式の変換が可能である。多様な経路の変換が可能であるが、一般に、あるデータが異なる経路で変換された場合に、同等なデータ表現になるとは限らないことに注意が必要である。データを変換した結果が経路によらずに同等となるためには、変換先の表現形式がL1において次の条件をみたせばよい。
　∀x∀y（（A（x）&& A（y））→（∃k（（k ⇒ x）&&（k ⇒ y））→（x ⇒ y）））
この条件を満たす表現形式を粒状であると定義する。粒状でない表現形式に変換を行う場合には、自動変換写像の定義によっては不要な情報の損失が生じる可能性がある。デジタル都市の材料データについて、既存の表現形式の多くは粒状であるが、そうでないものも存在すると考えられる。従って、DPPにおける表現形式の自動変換機能に対して粒状でない表現形式を考慮した実装を行う一方で、DPPのクラスの実装は原則として粒状とすることが適切である。
　DPPのクラスは、前節「１．３．」で定義された述語論理L2の対象、すなわちL1の1項述語を実装したものであり、データの表現形式である場合の他に、内部データを持たない単純な属性を表す場合がある。ここで、「属性」はL1の1項述語でデータの表現形式でないものを称している。表現形式から属性への自動変換写像は恒等写像とする。属性は、多様な表現形式間にまたがって定義されるため、一般的に粒状ではない。属性のみを取り扱い、属性の概念としての性質を表現する正則関数を適切に実装すれば、DPPは、オントロジー記述言語を定義することも可能と考えられる。
　二つの表現形式間に上位概念・下位概念の関係が成立していても、その二つの表現形式間を結ぶ変換経路が用意されなければ、表現形式の自動変換はできない。利用者に自動変換可能か否かの誤解が生じないように、DPPは、自動変換写像が実装された場合にのみ、上位概念・下位概念の関係が成立していると認識する。これは、一見、正則関数と正則述語の定義によって上位概念・下位概念の関係が定まるとする理論に反するが、不都合は生じない。実際に、プログラム開発者が理論上の定義と実装上の定義を明確に区別し、理論上で上位概念・下位概念の関係が成立している場合にのみ実装上で上位概念・下位概念の関係が認識されるようにすれば、上位概念・下位概念の関係が理論上ではないにもかかわらず実装上ではあるとする誤認識を防ぐことができる。
　表現形式をノード、自動変換写像をリンクとするネットワークにおいて、表現形式の自動変換は、コストが最小となる経路を探索して実行できるよう実装される。一例として、表現形式の自動変換は、例えば、ダイクストラ法に基づいてコストが最小となる経路を探索して実行し、自動変換写像が恒等写像である場合にはコストを0とし、その他の場合には1とすることができるが、これに限られるものではない。また、経路探索を効率化するため、上位概念・下位概念の関係に基づいて、目標へと至らないノードとリンクはあらかじめ排除される。
　図２６に式４に基づく表現形式の自動変換の例をL1の1項関数φの場合について示す。φは、入力の表現形式ごとに処理プログラムが実装され得るが、Bを定義域とする正則関数φ〈B〉が実装されているとき、DPPにおいて、A ⇒ Bであれば、自動変換写像B〈A〉が定義されており、Aの任意のデータ表現 a に対してφ〈B〉（B〈A〉（a））を計算することができる。これは表現形式の自動変換により、φ〈B〉の定義域がAを含むように拡大されているとみることができる。一方で、関数φ〈A〉を実装すれば、式４より、φ〈A〉（a） ⇒ φ〈B〉（B〈A〉（a））である。二通りのφ（a）の計算が可能であるが、自動変換により情報を落としてから関数を適用するよりは、関数を適用してから必要に応じて情報を落とす方が適切であるため、DPPは、φ〈A〉が定義されている場合には、後者の計算方法を採用する。これは一般のn項関数についても同様であり、この実装された関数の選択方法は、一般的なオブジェクト指向プログラミングにおけるポリモーフィズムと同様である。
１．５．開発した理論および実装に対する結論
　異なる形式で表現された二つのデータが同等であるための条件を明確に定義し、その定義に基づいた実装を行うことで、データの表現形式を論理的な間違い生じさせずに自動変換することに成功している。DPPを土台として、デジタル都市を構築するための要素プログラムを蓄積することで、デジタル都市構築技術を効率的かつ持続的に発展させることが可能と考えられる。
　古い表現形式を拡張した新しい表現形式のデータが特定の条件下で古い表現形式に変換でき、古いプログラムを活用できる場合がある。プログラムの再利用性を向上する観点からは、個々のデータ内容に依存して自動変換の可能性が定まる柔軟なデータ変換技術が必要である。このため、DPPは、ある形式で表現されたデータが特定の条件を満たすかを調べ、満たす場合には自動変換を実行することで関数の適用範囲をより拡大している。
２.実施の形態における目的
　以下、発明の実施の形態に係る本開示は、データを活用するための技術を持続的に高度化するために、標準と定められた形式で表現されたデータと、個々の目的に最適化された独自形式のデータの両方が同時に利用可能となる疎結合の方法を提供することを、目的とする。即ち、本開示は、一律的な形式でデータを表現する標準化に替わり、表現形式の自動データ変換に基づいたデータの抽象化によって疎結合を実現し、異種データ・異種プログラム群を柔軟に連携させる方法を提供することを目的とする。
また、そのような疎結合の方法を用いる、新規なデータから古い資料までの幅広いデータから情報を抽出するためのデータ解釈方法を提供することを、目的とする。
更に本開示は、そのような疎結合の方法を用いる、複数のデータに分散している断片的な情報を統合してデータの表現対象の模型を作成するデータ統合方法を提供することを、目的とする。
３．データ処理のためのプラットフォーム、及び、オブジェクト
　上述の目的を達成するために、本発明者は、「１．データ処理プラットフォームの研究」にて説明した、データ処理のためのプラットフォーム、及び、当該プラットフォームに基づいて定義され構築されるオブジェクトの考案に到っている。本開示では、発明者の考案に係る当該プラットフォーム（インタプリタとして機能する）を、データ処理プラットフォーム（DPP）と称している。又、DPPに基づいて定義され構築されるオブジェクトを、単にオブジェクトと称することとする。本発明者によるDPP及びオブジェクトの特性について、以下、整理して説明する。
　ある形式のデータを、目的の別の形式のデータに変換するには、通常、独自の変換プログラムが必要となる。例えば、図２Ａに示すように、「ソース１」、「ソース２」、「ソース３」・・・「ソースＭ」の表現形式のデータ（即ち、Ｍ種類の表現形式のデータ）を、「ターゲット１」、「ターゲット２」、「ターゲット３」・・・「ターゲットＮ」の表現形式のデータに変換することを想定する。この場合、Ｍ×Ｎ通り（図２Ａでは、具体的には３×３＝９通り）の変換プログラムが必要になる。
　ここで、図２Ｂに示すように、「媒介データ」の設定を導入する。つまり、「ソース１」、「ソース２」、「ソース３」・・・「ソースＭ」から、「ターゲット１」、「ターゲット２」、「ターゲット３」・・・「ターゲットＮ」への変換の媒介として、「媒介データ」を設定するとする。この場合、変換プログラムはＭ＋Ｎ通り（図２Ｂでは、３＋３＝６通り）で済むことになる。即ち、「Ｍ×Ｎ通り」から「Ｍ＋Ｎ通り」へ減少する。
　しかしながら、図２Ｂに示す「媒介データ」は、全てのコンポーネント（変換プログラム、データ）が、図２Ｂに示す「媒介データ」に依存することになり、標準化データである「媒介データ」に変更が生じれば、必ずＭ＋Ｎ通りの変換プログラムの再開発が必要となってしまう。
　そこで、本開示の発明者は、前述のような、自動データ変換を行うDPPを考案している。
　DPPでは、一般的なオブジェクト指向プログラミングにおけるオブジェクトと異なり、型変換が最適な変換経路で自動実行されるオブジェクトを導入・定義している。オブジェクトにおけるクラスの継承関係については、以下の（条件１）～（条件３）のように定義される。
　（条件１）継承関係は反射律と推移律を満たす。
　（条件２）上位概念・下位概念の関係が成立する時にクラス間の継承関係が認められる。
例えば、第１のオブジェクトが（x, y）座標を持つ第１のクラスに属し、第２のオブジェクトが（r, θ）座標（極座標）を持つ第２のクラスに属し、第１のクラスは第１のスーパークラスのサブクラスである、という状況を想定する。これらのクラスがC++により規定されるものである場合、座標表現が同じでないと継承関係は持ち得ないという原則から、第１のスーパークラスと第２のクラスとの間に継承関係は存在しない。これに対して、これらのクラスがオブジェクトを定義するDPPにより規定される場合、上位概念・下位概念の関係が成立すれば継承関係が生じることから、第１のスーパークラスと第２のクラスとの間に継承関係が存在することになる。
　（条件３）異なる内部構造を持つクラス間の継承関係に基づくポリモーフィズムが、クラス間に定義された変換処理を辿る自動経路探索と自動データ変換を実行することで実現される。
　なお、前述の「上位概念・下位概念の関係」は、オブジェクト指向プログラミングにおける「ｉｓ－ａ関係」に当たる。また、ここで、上位概念・下位概念の関係が成立すること、については、前述の「１．３．データ間の論理的な同等性の定義」にて、説明している。
　DPPでは、データは全て、オブジェクトとして扱われる。
　図３Ａは、自動データ変換による媒介データの別の状況を示す図である。図３Ａにおけるデータ、即ち、「ソース１」、「ソース２」、「ソース３」、「媒介データ１」、「媒介データ２」、「媒介データ３」、「ターゲット１」、「ターゲット２」、「ターゲット３」は、全てオブジェクト化されている。夫々の名称はクラス名（型名）である。
　図３Ａにおいて、まず、「ソース１」、「ソース２」から、「ターゲット１」、「ターゲット２」への変換の媒介として「媒介データ１」が設定されており、「ソース３」から、「ターゲット３」への変換の媒介として「媒介データ３」が設定されているとする。また、「媒介データ１」と「媒介データ３」との間に、クラス「媒介データ２」が設定されているとする。この場合、例えば、「ソース１」「ソース２」から、「ターゲット３」への変換が、「媒介データ１」「媒介データ２」「媒介データ３」を介して新たに実現され得ることになる。同様に、「ソース３」から「ターゲット１」「ターゲット２」への変換が、「媒介データ３」「媒介データ２」「媒介データ１」を介して新たに実現され得ることになる。
　ここで「媒介データ１」と「媒介データ２」との関係は等価関係であり、「媒介データ３」は「媒介データ２」を拡張したものである。媒介データの変更や拡張を古いコンポーネントを利用可能な状態で実施するためには、「媒介データ１」と「媒介データ２」との間で、２通りの変換が考慮されればよく、「媒介データ２」と「媒介データ３」との間でも、２通りの変換が考慮されればよい。これは、Ｍ＋Ｎ通りの再開発が２通りの変換の開発に効率化されることを意味する。
　なお、本開示のDPPにおいて、クラスであるデータ間の矢印（例えば、ソース１とターゲット１との間の、ソース１からターゲット１への矢印）が、継承関係を示すものであるように、各クラスが定義されている。ソース１とターゲット１との場合、矢印が示すように、「ソース１」がサブクラスであり、「ターゲット１」がスーパークラスである。
　更に、DPPでは、自動データ変換のためのインタプリタも構築され得る。図３Ｂは、インタプリタの動作例を示す図である。まず、「ソース１」から、「ターゲット１」への変換の媒介として「媒介データ１」が設定されており、「ソース２」、「ソース３」から、「ターゲット２」、「ターゲット３」への変換の媒介として「媒介データ２」が設定されており、更に、「ソース３」から「ターゲット３」への変換の媒介の設定は無い、とする。更に、「媒介データ１」と「媒介データ２」との間に相互の変換が設定されているとする。この場合に、インタプリタは、「処理Generate」で囲まれた部分Ｇの複雑な処理をユーザから隠蔽する役割を果たす。
　インタプリタは、その内部で必要に応じて媒介データを生成した上で自動データ変換を行う。例えば、図３Ｂに示す場合の「ソース３」から「ターゲット１」の変換を考える。このとき「ソース３」－＞「媒介データ２」－＞「媒介データ１」－＞「ターゲット１」という経路が想定され得る。インタプリタでは、各クラスの変換関係（即ち、継承関係）を把握しており、実際の「ソース３」から「ターゲット１」への変換時にはそれに基づいて、必要な媒介データの生成を行う。
　インタプリタは、実際の変換前に、複数の変換経路を想定し、それぞれに対して変換のコスト（例えば、矢印が示す変換（継承）が用いられた回数）を、計算するように構成されている。例えば、図３Ｂに示す場合の「ソース３」から「ターゲット３」の変換を考える。このとき「ソース３」－＞「媒介データ２」－＞「ターゲット３」という経路や、「ソース３」－＞「媒介データ２」－＞「媒介データ１」－＞「媒介データ２」－＞「媒介データ１」－＞「ターゲット３」という経路も想定されなくは無いが、「ソース３」－＞「ターゲット３」という経路が最も高速且つ効率的であることは明白である。このように、なるべく効率的であり高速である、変換経路を、インタプリタは自動決定しようとする。
３．１. DPPと、一般的なオブジェクト指向プログラミングとの特性の差異
　DPPと、一般的なオブジェクト指向プログラミングとの特性の差異は、上記の表に示した通りである。
　ここで「表現形式が異なること」について、説明する。「テキスト形式」と「バイナリ形式」は、表現形式が異なる一例である。
　更に、例えば、画像データであるならば、png, jpeg, bmp, tif、動画データであるならば、avi, mpeg, mov, wmv、などのように、無数の表現形式があり、それらが異なれば表現形式が異なる。
　また、テキスト形式と言っても、改行コードの違いによって、
・改行コードをLFとする表現形式
・改行コードをCR+LFとする表現形式
・改行コードをCRとする表現形式
などの違いがある。
　C++言語のクラスでいえば、次のクラスA,Bは、データの格納順序が異なるので異なる表現形式である。
class A { double x; double y; };
class B { double y; double x; };
　プログラミング言語もコンピュータへの指示を表現する表現形式の一つであり、C++、C、fortran、pythonなど、プログラミング言語が異なれば表現形式が異なる。
　性別をＭ、Ｆと書くか、男性、女性と書くか、を決めても、表現形式を定めたこと（即ち、異なること）になる。
３．２. オブジェクトがノードに関連付けられたグラフ
　本開示においては、データの解釈と、データの統合が、オブジェクトがノードに関連付けられたグラフを構築することで行われる。グラフは、一般に、グラフの構成要素であるノードと、二つのノードの間を結ぶリンクからなる。本開示におけるグラフは、各ノードと各リンクにオブジェクトが一つだけ関連付けられたものであり、各リンクは向きをもつ。本開示におけるグラフの各リンクは、データ処理プラットフォームの述語論理L2で定義された二項関係に対応し、各リンクの向きはリンクの両端のノードを区別する。本開示において、あるグラフの構成要素に関連付けられたオブジェクトにダウンキャストが生じると、ダウンキャスト後の新しいオブジェクトに応じた自動構造化が生じ得る。すなわち、グラフの各構成要素に関連付けられたオブジェクトのダウンキャストは、データを自動的に解釈・統合するための起点となる。
４．［実施の形態１］
　続いて、実施の形態１に係るデータ解釈方法及びデータ解釈装置を説明する。
４．１．データ解釈装置の構成
　図１は、本実施の形態に係るデータ解釈装置２の物理的な構成を示す図である。データ解釈装置２は、ハードウェアプロセッサに相当する制御部４と、メモリに相当するＲＡＭ（Random Access Memory）６と、メモリに相当するＲＯＭ（Read Only Memory）８と、通信部１２と、入力部１４と、出力部１６とを有する。これら各構成は、バス１０を介して相互にデータ送受信可能に接続される。
　制御部４は、ＲＡＭ６又はＲＯＭ８に記憶されたプログラムの実行に関する制御やデータの演算、加工を行う。制御部４は、様々なプログラム（例えば、データ解釈のためのプログラム）を実行する演算装置である。制御部４は、入力部１４や通信部１２から種々の入力データを受け取り、入力データの演算結果を出力部１６に表示したり、ＲＡＭ６やＲＯＭ８に格納したり、通信部１２を通じて外部サーバに転送したりする。制御部４は、ＣＰＵ（Central Processing Unit）などにより構成される。
　ＲＡＭ６は、データの書き換えが可能な記憶部であり、例えば半導体記憶素子で構成される。ＲＡＭ６は、制御部４が実行するアプリケーション等のプログラムやデータを記憶する。
　ＲＯＭ８は、データの読み出しのみが可能な記憶部であり、例えば半導体記憶素子で構成される。ＲＯＭ８は、例えばファームウェア等のプログラムやデータを記憶する。
　通信部１２は、データ解釈装置２を外部ネットワーク２０に接続する通信インタフェースである。
　入力部１４は、ユーザからデータの入力を受け付けるものであり、例えば、キーボードやマウス、タッチパネル、スキャナーで構成される。例えば、入力データとして2D-CAD図面のような非構造化データを読み込む場合、スキャナーを使用して画像データ（ラスタデータ）を取得することができる。
　出力部１６は、制御部４による演算結果を視覚的に表示するものであり、例えば、ＬＣＤ（Liquid Crystal Display）により構成される。
　データ解釈のためのプログラムは、ＲＡＭ６やＲＯＭ８等の、コンピュータによって読み取り可能な記憶媒体に記憶されて提供されてもよいし、通信部１２により接続される外部ネットワーク２０を介して外部サーバ２４から提供されてもよい。CADデータや、CADデータに基づくオブジェクトは、通信部１２により接続される外部ネットワーク２０を介して外部サーバ２４等から提供されるのが好ましい。データ解釈装置２では、制御部４がデータ解釈のためのプログラムを実行することにより、獲得部５ａや解釈部５ｂなどの様々な機能が実現される。なお、これらの物理的な構成は例示であって、必ずしも独立した構成でなくてもよい。例えば、データ解釈装置２は、ＣＰＵとＲＡＭ６やＲＯＭ８が一体化したＬＳＩ（Large-Scale Integration）や超ＬＳＩを備えていてもよい。
　制御部４にはプラットフォーム（ここでは、データ処理プラットフォーム）５が設けられる。当該プラットフォーム５は、獲得部５ａと、解釈部５ｂとを含む、機能ブロックを、備える。
　獲得部５ａは、入力データをオブジェクトとして獲得する。入力データは、構造化データであってもよく、非構造化データであってもよい。
　解釈部５ｂは、獲得部５ａが獲得したオブジェクトに対して初期グラフを作成する。更に、解釈部５ｂは、初期グラフからグラフを自動構造化させた結果を入力データの解釈とする。解釈部５ｂは、この解釈において、グラフの各ノードと各リンクに関連付けられたオブジェクトの下位概念側または上位概念側への型変換を適宜実行する。
４．２．データ解釈装置の動作
　図４は、橋脚構造を示す橋脚構造一般図の例であり、CADデータにより構成されている。CADデータである橋脚構造一般図のデータは、線分や曲線、文字列等を構成要素として含み、構成要素の集まりは、平面図や正面図などの「図」と、各種表などの「表」とに解釈され得る。
４．２．１．データを解釈する過程
　設計図面オブジェクトを入力として、図面の要素を表すオブジェクトがノードに関連付けられたグラフを生成する過程であり、生成されたグラフを図面の解釈結果とする。図１８に示すように、図面に含まれる線分や文字列、円などの要素をすべて同一の階層に配したグラフを初期グラフとし、グラフを順次自動構造化させる。ただし、図面データ中の要素が最初から構造化されている場合にはその構造を反映したグラフを初期グラフとしてもよい。一例として図１９に、引出線付きテキストバルーンを認識する過程を、グラフの自動構造化の例として示す。図１９では、図面内において円が文字列を包含している場合（上段）に、二つをまとめてテキストバルーンと解釈し（中段）、さらに、バルーンに折れ線が連結している場合にはその折れ線を引き出し線とみなしている（下段）。つまり、円要素と文字列要素の包含関係からテキストバルーンを認識し、テキストバルーンと線分要素の接続から引き出し線を認識する。引出線付きテキストバルーンの一部分となった線分要素に「引出線」という役割が割り当てられるように、グラフの構成要素間の関係は、図面の要素の使われ方を明示したコンテキストを表している。
４．２．２．表である「表題欄」を解釈する動作
　図４に示す橋脚構造一般図において、図５に示す「表題欄」を解釈する手順を説明する。「表題欄」は、CAD製図基準（国土交通省）において橋脚構造一般図の右下隅に記載することが規定されている。図４に示す橋脚構造一般図の例においても、右下隅に設けられている。更に、「表題欄」は、CADデータでは線と文字列から構成される。
　まず、CADデータ「橋脚構造一般図」において、線の集まりであるデータが、オブジェクト化される（クラス名は、例えば、「LineBuf2D」とされる）。図６は、「橋脚構造一般図」において線で構成されるオブジェクト（クラス名「LineBuf2D」）を示す図である。オブジェクトとして、「Ａ」から「Ｐ」まで、１６個のものが示されている。
　次に、図６に示すように、線の集まりのオブジェクト（クラス名「LineBuf2D」）から、セルの集合と解釈できないものが「表題欄」の候補から除外される。ここで、セルの集合については「CellSet」というクラスが定義されており、よって、線の集まりのオブジェクト（クラス名「LineBuf2D」）から、サブクラス「CellSet」へのダウンキャストが自動実行される。図７は、線の集まりのオブジェクト（クラス名「LineBuf2D」）がサブクラス「CellSet」にダウンキャストされ、「表題欄」の候補が残りの８個のオブジェクトであることを示す図である。「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」、「Ｅ」、「Ｆ」、「Ｋ」、及び「Ｌ」のオブジェクトが、「表題欄」の候補である。
　なお、線の集まりのオブジェクト（クラス名「LineBuf2D」）から、セルの集合と解釈できないものを除外するに当たっては、サブクラス「CellSet」に対してクラス「LineBuf2D」からダウンキャストするための関数をあらかじめ定義しておく。ここで、スーパークラスからサブクラスへダウンキャストするためにあらかじめ定義しておく関数を、input関数と称することとする。ダウンキャストが失敗したものが「表題欄」の候補から外れることになる。ここでのサブクラス「CellSet」とクラス「LineBuf2D」の継承関係は、セルの集合「CellSet」と解釈されたならば線の集まり「LineBuf2D」とも解釈されなければならないという上位概念・下位概念の関係に拠る（前述（条件２）参照）。
　更に、線の集まりのオブジェクト（クラス名「LineBuf2D」）から、セルの集合と解釈できないものを除外するに当たっては、スーパークラスからサブクラスへのダウンキャストがどの程度確からしいかを示す値（例えば、セルの集合と解釈されたオブジェクトが何％の確率で実際にセルの集合であるかを示す値）、確度をサブクラスへの変換時（input関数実行時）にオブジェクトに与えることができる。確度の計算の際に、スーパークラスに付与されている確度を参照することも可能である。
　次に、図８Ａに示すように、クラス「CellSet」のオブジェクトに対してサブクラス「Table」へのダウンキャストが試行される。この場合のinput関数に対しては、スーパークラス「CellSet」のオブジェクトとともに、CADデータの要素（線や文字列等）が入力され、セルの集合の各セルに含まれる要素が抽出される。クラス「CellSet」のオブジェクトに対して、一定数の文字列等が入力された場合に、ダウンキャスト成功とするようにinput関数を定義することが可能であり、「Table」のクラスにダウンキャストされたオブジェクトは、「Table」と解釈されることになる。
　次に、図８Ｂに示すように、クラス「Table」のオブジェクトにおいて、所定の項目、ここでは「図面名」の項目が存在するか調べる。存在すればクラス「表題欄」のオブジェクトにダウンキャストされ、「表題欄」であると解釈されることになる。このとき、ダウンキャストは、input関数によらず、クラスにあらかじめ定義されたダウンキャスト可能かをクラスの内部データから判別する関数（is関数と称する）と実際のダウンキャストを実行する関数（cast関数と称する）に基づいて実行される。ここで、is関数とcast関数によるダウンキャストを分析・分類によるダウンキャストと称する。以上のようにして「表題欄」が解釈される。
　ここでは、表である「表題欄」を解釈する動作について、グラフを自動構造化させる観点から簡単に説明する。図２１は、CAD製図基準（国土交通省）で定義されている「表題欄」を認識する過程を示している。「表題欄」の認識のため、まず、図２１（１）のように、接続された線分の集まりが抽出され、線分の配置状況から「表の枠組み」であるかどうかが判定される。図２１（２）のように、「表の枠組み」と判定された場合には、それを表現するオブジェクトに表の各セルの情報が記録されている。このセル情報を使って、さらに図面からセル内に文字列が配置されているかを調べ、文字列が配置されている場合には「表」であると判定し（図２１（３））、セルの情報として文字列を格納する。CAD製図基準に従う図面の表に対して、セルの項目として"工事名"がある等の条件を満たせば、図２１（４）のように、「表」は「表題欄」であると認識することができる。
４．２．３．図である「橋脚正面図」を解釈する動作
　続いて、図４に示す橋脚構造一般図において、図である「橋脚正面図」を解釈する手順を説明する。なお、図４では、中央上部に「橋脚正面図」が設けられている。
　まず、CADデータ「橋脚構造一般図」において、線の集まりであるデータが、オブジェクト化される（クラス名「LineBuf2D」）。図６は、「橋脚構造一般図」において線で構成されるオブジェクトを示す図である。オブジェクトとして、「Ａ」から「Ｐ」まで、１６個のものが示されている。
　次に、線の集まりのオブジェクト（クラス名「LineBuf2D」）から、寸法値が付いている図「View」と解釈できないものを除外するに当たっては、サブクラス「View」に対してクラス「LineBuf2D」からダウンキャストするための関数をあらかじめ定義しておく。ダウンキャストが失敗したものが「View」と解釈される候補から外れることになる。ここでのサブクラス「View」とクラス「LineBuf2D」の継承関係は、寸法値がついている図「View」と解釈されたならば線の集まり「LineBuf2D」とも解釈されなければならないという上位概念・下位概念の関係に拠る（前述（条件２）参照）。図９は、線の集まりのオブジェクト（クラス名「LineBuf2D」）からサブクラス「View」でないものが除外され、残りの８個のセルを示す図である。「Ｇ」、「Ｈ」、「Ｉ」、「Ｊ」、「Ｍ」、「Ｎ」、「Ｏ」及び「Ｐ」のセルが、残されている。
　なお、線の集まりのオブジェクト（クラス名「LineBuf2D」）から、寸法値が付いている図「View」へのダウンキャストに当たっては、スーパークラスからサブクラスへのダウンキャストがどの程度確からしいかを示す値（例えば、寸法値の付いた図と解釈されたオブジェクトが何％の確率で実際に寸法値の付いた図であるかを示す値）、確度をサブクラスへの変換時にオブジェクトに与えることができる。
　オブジェクトが「橋脚正面図」であるかを調べるため、オブジェクトの内部データの所定の項目、ここではレイヤを参照し、主構造物（D-STR）レイヤに属しているオブジェクトの子要素があるか分析及び分類する。オブジェクトのすべての要素が主構造物（D-STR）レイヤに属していないとすれば、そのオブジェクトは「橋脚正面図」の候補から除外される。図１０において、図９に示す８個のクラス名Viewのオブジェクトのうち、主構造物（D-STR）レイヤに属していないものが除外されて、「Ｈ」、「Ｉ」、「Ｊ」、「Ｍ」、「Ｎ」、「Ｏ」及び「Ｐ」を付して、７個が示されている。
　input関数を用いたダウンキャスト（情報の入力によるダウンキャストと称する）では、オブジェクトが個々にもつ固有の内部データに加えて追加の情報を用いてダウンキャスト可能か否かを判断することができる。図１１に示すように、クラス「View」のオブジェクトに対して、CADデータから表題となる文字列が入力され、「橋脚正面図」であると解釈される。以上のようにして、図面である「橋脚正面図」が解釈される。
４．２．４．図面を解釈する動作のまとめ
　本実施の形態に係るデータ解釈装置及びデータ解釈方法では、2D-CAD図面の意味及び内容を段階的に認識する。
　正面図や平面図などの各種の図に対しては、図１３（１）及び図１３（２）に示すように、線に着目する。即ち、線の集まりであるデータについてオブジェクト化（クラス名「LineBuf2D」）が行われる。次に、図１３（２）、図１３（３）及び図１３（４）に示すように、寸法値などを図面から入力した上で、クラス名「View」のオブジェクトであると解釈し、更にクラス名「橋脚正面図」のオブジェクトであると解釈する。さらに、寸法値と「View」がもつ内部データの投影面から、橋脚の柱の高さが１１ｍという情報が得られている。
　各種の表に対しては、図１４（１）及び図１４（２）に示すように、線に着目する。即ち、線の集まりであるデータについてオブジェクト化（クラス名「LineBuf2D」）が行われる。次に、図１４（２）及び図１４（３）に示すように、クラス名「CellSet」のオブジェクトであると解釈する。次に、図１４（３）及び図１４（４）に示すように、文字列などのセルの内容を図面から入力した上で、クラス名「Table」のオブジェクトであると解釈し、更に、クラス名「下部工座標」のオブジェクトであると解釈する。
　図１５に示すように、各種の表において、線の集まりのオブジェクト（クラス名「LineBuf2D」）は、セルの集合のオブジェクト（クラス名「CellSet」）として解釈され、更に、複数のセルに内容が充填されているオブジェクト（クラス名「Table」）や一つのセルのみを含むオブジェクト（クラス名「Cell」）として解釈される。同じように、図１５に示すように、各種の図において、線の集まりのオブジェクト（クラス名「LineBuf2D」）は、寸法値が付いている図であるオブジェクト（クラス名「View」）として解釈され、更に、「橋脚正面図」特有の項目を持つオブジェクト（クラス名「橋脚正面図」）や「橋脚側面図」特有の項目を持つオブジェクト（クラス名「橋脚側面図」）として解釈される。
　図１６に示すように、2D-CAD図面の認識手法として、本実施の形態では、二通り設定されている。（１）「情報の入力」と、（２）「分析・解釈」である。
　図１６（１）に例として示しているように、セルの集合のオブジェクト（クラス名「CellSet」）に対して、入力データからの追加の情報として、図面上の情報が入力されることで、クラス名「Table」のオブジェクトとして解釈され得ることとなる。
　また、図１６（２）に例として示しているように、クラス名「Table」のオブジェクトおいて、項目等を分析・分類してダウンキャストすることで、クラス名「表題欄」のオブジェクト、クラス名「構造高表」のオブジェクト、及び、クラス名「座標Table」のオブジェクト、が解釈され得ることとなる。
　なお、図２７は、2D-CAD図面「006_P2橋脚構造一般図.dxf」を解釈するためのスクリプトの例である。このスクリプトは、本開示に係るデータ処理プラットフォームに理解される言語の一例である。当然ながら、本開示のデータ処理プラットフォームは、これまでに述べた要件を満たす限り、本発明者の創作したインタプリタ以外の別のインタプリタであっても全く構わない。スクリプトも、当該別のインタプリタによって理解される言語であって構わない。
５．［実施の形態２］
　本実施の形態に係るデータ統合装置２'は、複数のデータに分散している断片的な情報を統合してデータの表現対象の模型を作成する。
　図２２を参照して、実施の形態２に係るデータ統合装置を説明する。
５．１．データ統合装置の構成
　図２２は、本実施の形態に係るデータ統合装置２'の物理的な構成を示す図である。データ統合装置２'は、ハードウェアプロセッサに相当する制御部４と、メモリに相当するＲＡＭ（Random Access Memory）６と、メモリに相当するＲＯＭ（Read Only Memory）８と、通信部１２と、入力部１４と、出力部１６とを有する。これら各構成は、バス１０を介して相互にデータ送受信可能に接続される。通信部１２は、データ統合装置２'を外部ネットワーク２０に接続する通信インタフェースであり、データ統合装置２'は、通信部１２により接続される外部ネットワーク２０を介して外部サーバ２４とも接続する。これらの、ＲＡＭ６、ＲＯＭ８、通信部１２、入力部１４、出力部１６、及び、バス１０は、図１に示す実施の形態１に係るものと、同様のものである。
　制御部４にはプラットフォーム（ここでは、データ処理プラットフォーム）５が設けられる。当該プラットフォーム５は、獲得部５ａと、解釈部５ｂと、及び統合部５ｃとを含む、機能ブロックを備える。
　獲得部５ａは、入力データをオブジェクトとして獲得する。入力データは、構造化データであってもよく、非構造化データであってもよい。
　解釈部５ｂは、獲得部５ａが獲得したオブジェクトごとに初期グラフを作成し、初期グラフからグラフを自動構造化させて入力データの解釈とする。解釈部５ｂは、この解釈において、グラフの各ノードと各リンクに関連付けられたオブジェクトの下位概念側または上位概念側への型変換を適宜実行し、また、型変換に応じてオブジェクト間の関係を表すグラフの構造を変化させる。さらに、解釈（型変換とグラフ構造の変化）の結果として言語表現を生成して統合部５ｃに送出する。
　統合部５ｃは、解釈部５ｂから送出された言語表現を受け取り、情報として保持する。また、統合部５ｃは、推論処理に基づいて情報の洗練を実行する。さらに、統合部５ｃは、言語表現に応じてグラフの変換を実行し、情報をグラフに反映させる（グラフの変換による情報の統合）。言語表現に応じた変換処理を施されたグラフは、情報を統合した統合データの側面をもつ。入力データの表現対象に対する統合データ（表現対象の模型）は、このグラフ（グラフを構成するオブジェクト群とグラフの構造の全体）として生成される。統合部５ｃは、推論処理に基づく情報の洗練を、言語表現の各単語に対応するオブジェクトの上位概念・下位概念の関係に基づいて実行する。また、グラフの変換による情報の統合を、グラフの各ノードと各リンクに関連付けられたオブジェクトの上位概念・下位概念の関係に基づいて実行する。
　以上の構成により、本実施の形態に係るデータ統合装置２'は、材料となる複数のデータから抽出した複数の断片的な情報を統合して所望のデータを構築する。
　また、本実施の形態に係るデータ統合装置２'は、表現形式が異なるオブジェクトのデータ構造を自動で変換するものであり、型変換の経路を自動探索し、更に統合データを自動構成する。
５．２．データ統合装置の動作
　本開示に係るデジタル橋梁自動構築手法の流れは図１７に示される。入力部で入力されたデータ（例えば、設計図面等）は、下位概念側への自動型変換を起点とする自動構造化によるデータの自動解釈によって個別に解釈され、その解釈結果に基づいて複数の情報（言語表現）が抽出される。抽出された情報や入力部で入力された情報（例えば、ユーザ入力等）は、適宜、推論処理によって洗練され、情報（言語表現）に応じたグラフの変換によって統合されることで、3次元橋梁モデルといったデジタル橋梁が構築され、出力部から出力される。デジタル橋梁自動構築の過程には、次の三つが含まれる。ここで、言語表現とは、自然言語類似の言語形式で表現された情報のことである。
（１）データを解釈する過程
（２）情報抽出過程
（３）同定・統合過程
　なお、（１）は図１７における自動構造化によるデータの解釈に該当し、（２）は解釈結果に基づく言語形式での情報（言語表現）の抽出、（３）はグラフの変換による情報の統合にそれぞれ該当する。また、実施の形態１は（１）（２）を含む実施例であり、実施の形態２では、（１）～（３）までを含む。
５．２．１．（１）データを解釈する過程
　データを解釈する過程は、「４．２．０．データを解釈する過程」で説明している。
５．２．２．（２）情報抽出過程
　図面を含む複数の入力データの解釈結果として得られるグラフから、自然言語類似の言語形式で情報を抽出する。例えば、グラフの構造とグラフを構成するオブジェクトの内部データから、図面が表現している現実の対象を洗い出し、その対象に関する記述として言語表現をまとめる。例えば、対象を特定するための主部と、対象の性質を表す述部をもつ言語表現として、以下のような言語表現を抽出する。
　Def:橋梁がある;
　Def:橋梁に橋脚がある;
　Def:橋梁は名前が:"P1":である;
　Def:名前が:"P1":の橋脚は高さが:"Q(13m)":である;
５．２．３．（３）同定・統合過程
　情報抽出過程で得られた複数の言語表現（情報）の統合は、一つのグラフに対して、言語表現に応じたグラフの変換を順次実行することで行う。この統合の結果として得られる統合データであるグラフは、データから洗い出された表現対象（例えば、「P1橋脚」、「A2橋台」）をグラフの一部として含み、各表現対象に関する情報もグラフの一部として反映され統合される。この統合の過程で図面の解釈時と同様にグラフの自動構造化が実行される。
　情報抽出過程では、上述したように、情報を「Def:名前が:"P1":である橋脚の高さが:Q("13m"):である;」のような言語表現の集まりとして得る。言語表現の内容を一つのグラフに統合するためには、例えば、言語表現の主部に対応するグラフのノードを同定し、述部に対応するグラフの変換を与える。ただし、言語表現の中には、特定のノードの存在を記すものや、グラフを一定のルールで修正する内容を記したものがあってもよく、言語表現それぞれに応じたグラフの変換を実行する。ここで、もし、或る言語表現に対応するグラフの変換が定義されていなければ、その情報は無視すればよく、グラフの変換をあとから実装することができる。
　一例として、情報抽出過程で抽出された各言語表現の内容を一つのグラフに統合した結果を図２８Ａ及び図２８Ｂに示す。
　図２８Ａは以下の言語表現を一つのグラフに統合した結果である。
　Def:橋梁がある;
　Def:橋梁に橋脚がある;
　Def:橋梁は名前が:"P1":である;
　Def:名前が:"P1":の橋脚は高さが:"Q(13m)":である;
　また、図２８Ｂは、以下の言語表現を一つのグラフに統合した結果である。
　Def:橋梁がある;
　Def:橋梁に橋脚がある;
　Def:橋梁は名前が:"P1":である;
　Def:名前が:"P1":の橋脚は高さが:"Q(13m)":である;
　Def:橋脚に梁がある;
　Def:梁は高さが:"Q(3m)":である;
　ここで、グラフのリンク部分には、ノード間の関係が表現されている（例えば、「部分」、「名前」、「高さ」など）。
　なお、グラフの変換により統合される言語表現のすべてが情報抽出過程で抽出されたものである必要はなく、ユーザや他のプログラム等から入力等された言語表現があってもよい。例えば、図２８Ｂに示すグラフを得るための言語表現のうち、「Def:梁は高さが:"Q(3m)":である;」との言語表現がユーザから入力されたものであってもよい。また、言語表現の内容としては、工学知や工学知に基づく何等かの推論又は推定を表したものであってもよい。
　各言語表現の内容を統合したグラフは、当該言語表現に応じたグラフの変換を順次実行することで得られる。
　例えば、以下の（１）～（４）に示す言語表現が順に得られたものとする。
　（１）Def:橋梁がある;
　（２）Def:橋梁に橋脚がある;
　（３）Def:橋脚は名前が:"P1":である;
　（４）Def:名前が:"P2":の橋脚が橋梁にある;
　このとき、図２９に示すように、（１）に示す言語表現が得られた後に（２）に示す言語表現が得られると、Ｓ１に示すようにグラフが変換される。次に、（３）に示す言語表現が得られると、Ｓ２に示すようにグラフが変換される。そして、（４）に示す言語表現が得られると、Ｓ３に示すようにグラフが変換される。グラフの自動構造化はグラフが変換される度に実行され、グラフのノードに関連付けられた図面の表現対象（橋梁、橋脚など）のオブジェクトが詳細な内部データを含む下位概念側のオブジェクトへ自動変換される。なお、グラフを自動構造化させる際には、必要に応じて、例えば、工学知や何等かの推定技術を用いる。例えば、或る対象と別の或る対象との関係が図面から抽出した情報からは得られなかったとしても、工学知や何等かの推論又は推定技術により得られた場合には、この関係を用いてグラフを自動構造化させる。
　このようにして得られたグラフを用いることで、このグラフが表す構造物の３次元モデルを出力することができる。なお、上述したように、言語表現には図面から抽出された情報だけでなく、ユーザや他のプログラム等から入力された言語表現も用いることができるため、例えば、CAD図面の一部の要素を変更等した３次元モデルを作成することも可能となる。このため、例えば、既存の構造物のCAD図面の一部の要素を変更する等にして、任意の構造物の３次元モデルを得ることが可能となる。
５．２．４．２次元CAD図面への適用
　本開示に係るデジタル橋梁自動構築手法の検討のため、線分や文字列等の図面の要素がベクター形式で記録されている２次元CAD（DXF形式）の図面を対象として自動解釈と表現対象の自動構築を試行した。図２０は、試行により橋脚の３次元モデルが自動構築された例を示している。図面の解釈結果として、「橋脚正面図」、「橋脚平面図」、及び「橋脚側面図」が解釈される。それら「橋脚正面図」、「橋脚平面図」、及び「橋脚側面図」から、構造物の情報が自動抽出されて、更に構造物の情報から３次元モデルが自動作成される。図１２Ａは、正面図、平面図、及び側面図から、構造物の情報が自動抽出される様子を示す図であり、図１２Ｂは、構造物の情報から３次元モデルが自動作成される様子を示す図である。
６．他の実施の形態
　以上のように、本出願において開示する技術の例示として、実施の形態１及び２を説明した。しかしながら、本開示における技術は、これに限定されず、適宜、変更、置き換え、付加、省略などを行った実施の形態にも適用可能である。
　また、実施の形態を説明するために、添付図面および詳細な説明を提供した。したがって、添付図面および詳細な説明に記載された構成要素の中には、課題解決のために必須な構成要素だけでなく、上記技術を例示するために、課題解決のためには必須でない構成要素も含まれ得る。そのため、それらの必須ではない構成要素が添付図面や詳細な説明に記載されていることをもって、直ちに、それらの必須ではない構成要素が必須であるとの認定をするべきではない。
　また、上述の実施の形態は、本開示における技術を例示するためのものであるから、特許請求の範囲またはその均等の範囲において種々の変更、置き換え、付加、省略などを行うことができる。
　本願は、日本国に２０２１年２月３日に出願された基礎出願２０２１－０１６１１８号に基づくものであり、その全内容はここに参照をもって援用される。
２・・・データ解釈装置、２'・・・データ統合装置、４・・・制御部、５・・・プラットフォーム、５ａ・・・獲得部、５ｂ・・・解釈部、５ｃ・・・統合部、６・・・ＲＡＭ、８・・・ＲＯＭ、１０・・・バス、１２・・・通信部、１４・・・入力部、１６・・・出力部、２０・・・外部ネットワーク、２４・・・外部サーバ。

Claims (10)

  1. 　オブジェクトの型変換を自動実行するプラットフォームを備えたデータ統合装置であって、
    　前記プラットフォームは、前記データ統合装置の制御部に設けられ、解釈部及び統合部を有しており、
    　前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成し；
    　前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行する；
    ように前記制御部を動作させる、データ統合装置。
  2. 　前記統合部は、
    　前記解釈部により生成される前記情報に加えて、ユーザにより入力された言語形式の情報を、前記グラフに反映させることで、前記解釈部により生成される情報と前記ユーザにより入力された言語形式の情報とを統合する、請求項１に記載のデータ統合装置。
  3. 　前記解釈部は、
    　前記プラットフォームのオブジェクト間の関係を表すグラフに対して、オブジェクト同士の上位概念・下位概念の関係に基づいて、グラフの構成要素がより下位概念側の型へ変換されるように前記グラフの構造を変換する、請求項１又は２に記載のデータ統合装置。
  4. 　前記統合部は、
    　前記統合部が保持している言語形式の情報に対して、オブジェクト同士の上位概念・下位概念の関係を考慮した推論処理を実行し、前記統合部が保持している情報の変換を行う、請求項１乃至３の何れか一項に記載のデータ統合装置。
  5. 　前記制御部は、
    　前記言語形式の情報が自然言語類似であり、ユーザにより入力された自然言語あるいは自然言語類似の単語あるいは文に応じて、ユーザへの出力を生成する、請求項１乃至４の何れか一項に記載のデータ統合装置。
  6. 　オブジェクトの型変換を自動実行するプラットフォームを用いたデータ統合方法であって、
    　前記プラットフォームは、コンピュータの制御部に設けられ、解釈部及び統合部を有しており、
    　前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成するステップと；
    　前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行するステップ；
    を実行する、データ統合方法。
  7. 　コンピュータが実行するプログラムであって、
    　当該コンピュータの制御部に備えられ、解釈部及び統合部を有し、オブジェクトの型変換を自動実行するプラットフォームにおいて、
    　前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成するステップと；
    　前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行するステップ；
    を行うように前記コンピュータの制御部を動作させる、プログラム。
  8. 　オブジェクトの型変換を自動実行するプラットフォームと要素プログラムを備えたシステムであって、
    　前記プラットフォームは、オブジェクト同士の上位概念・下位概念の関係に基づく型変換の経路探索と自動実行により、要素プログラムの入力形式を抽象化して適用範囲を拡大することで要素プログラム間の疎結合を実現している、デジタル都市構築システム。
  9. 　前記プラットフォームは、前記システムの制御部に備えられ、解釈部及び統合部を有しており、
    　前記解釈部が、前記プラットフォームのオブジェクト間の関係を表すグラフから、オブジェクトが単語に関連付けられた言語形式の情報を生成し；
    　前記統合部が、前記情報を保持して、前記情報を反映するように前記グラフの作成と変換を実行する；
    ように前記制御部を動作させる、請求項８に記載のデジタル都市構築システム。
  10. 　前記プラットフォームの前記解釈部及び統合部により統合されたデータの表現対象が都市又は構造物である、請求項８又は９に記載のデジタル都市構築システム。
PCT/JP2022/002713 2021-02-03 2022-01-25 データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システム WO2022168681A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022579469A JPWO2022168681A1 (ja) 2021-02-03 2022-01-25

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2021-016118 2021-02-03
JP2021016118 2021-02-03

Publications (1)

Publication Number Publication Date
WO2022168681A1 true WO2022168681A1 (ja) 2022-08-11

Family

ID=82741315

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/002713 WO2022168681A1 (ja) 2021-02-03 2022-01-25 データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システム

Country Status (2)

Country Link
JP (1) JPWO2022168681A1 (ja)
WO (1) WO2022168681A1 (ja)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02224066A (ja) * 1988-11-15 1990-09-06 Fuji Xerox Co Ltd 文書解析装置
JPH04153878A (ja) * 1990-10-18 1992-05-27 Fujitsu Ltd 機械翻訳装置における前編集支援処理装置
JP2001051997A (ja) * 1999-08-11 2001-02-23 Sony Corp 文書データ作成装置、文書データ作成方法、及び記録媒体
JP2019056976A (ja) * 2017-09-19 2019-04-11 国立大学法人 東京大学 データ管理装置、データ管理方法及びデータ管理プログラム
JP7042545B2 (ja) * 2019-07-29 2022-03-28 国立研究開発法人理化学研究所 データ解釈装置、方法及びプログラム、データ統合装置、方法及びプログラム、並びにデジタル都市構築システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02224066A (ja) * 1988-11-15 1990-09-06 Fuji Xerox Co Ltd 文書解析装置
JPH04153878A (ja) * 1990-10-18 1992-05-27 Fujitsu Ltd 機械翻訳装置における前編集支援処理装置
JP2001051997A (ja) * 1999-08-11 2001-02-23 Sony Corp 文書データ作成装置、文書データ作成方法、及び記録媒体
JP2019056976A (ja) * 2017-09-19 2019-04-11 国立大学法人 東京大学 データ管理装置、データ管理方法及びデータ管理プログラム
JP7042545B2 (ja) * 2019-07-29 2022-03-28 国立研究開発法人理化学研究所 データ解釈装置、方法及びプログラム、データ統合装置、方法及びプログラム、並びにデジタル都市構築システム

Also Published As

Publication number Publication date
JPWO2022168681A1 (ja) 2022-08-11

Similar Documents

Publication Publication Date Title
CN115544264B (zh) 知识驱动的桥梁建造数字孪生场景智能构建方法及系统
WO2021020356A1 (ja) データ解釈装置、方法及びプログラム、データ統合装置、方法及びプログラム、並びにデジタル都市構築システム
US20220036232A1 (en) Technology for optimizing artificial intelligence pipelines
Wu et al. Use of patterns for know-how reuse in a model-based systems engineering framework
Song et al. Elastic structural analysis based on graph neural network without labeled data
Dunlap et al. Earth system curator: metadata infrastructure for climate modeling
Capellman Hands-On Machine Learning with ML. NET: Getting started with Microsoft ML. NET to implement popular machine learning algorithms in C
Yin et al. Two-stage Text-to-BIMQL semantic parsing for building information model extraction using graph neural networks
Jia et al. Graph neural networks for construction applications
Kordjamshidi et al. Spatial language understanding with multimodal graphs using declarative learning based programming
CN115997204A (zh) 使用图形和结构化神经编码器生成文本的丰富描述符框架
WO2022168681A1 (ja) データ統合装置、データ統合方法及びプログラム、並びにデジタル都市構築システム
Yousef et al. DVP: Data visualization platform
CN115687651A (zh) 知识图谱构建方法、装置、电子设备及存储介质
Lamons et al. Python Deep Learning Projects: 9 projects demystifying neural network and deep learning models for building intelligent systems
Vadavalasa End to end CI/CD pipeline for Machine Learning
Khodnenko et al. A lightweight visual programming tool for machine learning and data manipulation
Firdous Handwritten Character Recognition
Taieb Data analysis with Python: a modern approach
CN117151247B (zh) 机器学习任务建模的方法、装置、计算机设备和存储介质
CN118012781B (zh) 模型训练方法与相关方法、装置、设备及存储介质
Lin Visual architectural topology: An ontology-based topological tool for use in an architectural case library
Singh Automating Generation of Web GUI from a Design Image
Sai Srichandra et al. Vectorization of Python Programs Using Recursive LSTM Autoencoders
Forkel et al. Converting Legacy Data to CLDF: A FAIR Exit Strategy for Linguistic Web Apps

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22749555

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022579469

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22749555

Country of ref document: EP

Kind code of ref document: A1