Structured semantic expression system for engineering product data and implementation method thereof

Abstract

A Semantic Substances Targeting System (SST) for Engineering Product Data and its Implementation Method are disclosed, addressing the problems of poor semantic expression, low processing efficiency, and poor semantic accuracy in existing technologies. The SST system includes a naming graph, comprising: a header region for semantically describing global information of the naming graph; a dictionary region for logically enumerating all non-character type nodes appearing in the naming graph and assigning a unique index identifier to each node (non-character type nodes include IRI type nodes and blank type nodes; IRI type nodes are semantic nodes identified by Internationalized Resource Identifiers, and blank type nodes are semantic nodes without explicit IRI identifiers); a content region for recording engineering product data according to triples using node index identifiers and storing triples by node (triples include subject, predicate, and object); and statistical information for recording global metadata.

Description

Technical Field

[0001] This application relates to the field of engineering data management technology, specifically to a Structured Semantic Technology (SST) system for engineering product data and its implementation method. Background Technology

[0002] Engineering product data spans the entire lifecycle, including demand, design, manufacturing, and operation and maintenance, and involves various stakeholders (e.g., design institutes, manufacturing units, and operation and maintenance service providers) and heterogeneous information systems such as Product Lifecycle Management (PLM), Enterprise Resource Planning (ERP), and Manufacturing Execution System (MES). Engineering product data needs to be managed in a way that allows for exchange, sharing, and traceability across all stages, stakeholders, and systems; this is the foundation for achieving digital collaboration throughout the entire product lifecycle.

[0003] In existing data modeling methods, a typical approach is centered on a hierarchical structure: "classes / entities" are treated as first-class citizens, using instance objects to carry the main information; "attributes / features" are treated as second-class citizens, primarily used as constants or auxiliary fields of entities. In the semantic representation of complex engineering products, this type of model can easily lead to real relationships being rewritten as additional entity nodes. For example, relations that should be attribute predicates (such as "belong to" or "connected to") are modeled as independent "relational entities." This can introduce additional data generation and storage overhead, further impacting processing performance.

[0004] To enhance semantic expressiveness, some systems employ Semantic Web technology based on the Resource Description Framework (RDF) / Web Ontology Language (OWL), utilizing logical axioms (such as transitivity, symmetry, and functionality) for runtime reasoning. In engineering-scale data scenarios, this mechanism may lead to increased reasoning costs and an explosion in the number of derived triples. Particularly in more expressive logical systems, the reasoning process may exhibit significantly increased complexity, generating redundant triples unrelated to business logic, resulting in a substantial increase in processing latency and resource consumption.

[0005] In terms of data exchange and engineering implementation, existing semantic data representation still faces the following engineering pain points: First, different serialization methods or multiple text arrangements of the same semantic content will lead to non-unique representation, making it difficult to achieve capabilities such as consistency verification, hash comparison, difference extraction, and cross-process streaming transmission; Second, data content is often coupled with revision history and version information or lacks a unified management mechanism, making it difficult to meet the archiving and traceability needs of engineering product data "evolving over time".

[0006] Furthermore, in engineering product data, the need for structured representations such as "sets / sequences / multi-valued attributes" is widespread and crucial. Relying solely on general blank nodes or loose list structures can easily lead to engineering implementation challenges in areas such as cross-file referencing, stable numbering, difference calculation, and the order and semantic constraints of set members. To address these needs, existing data formats have attempted improvements at the dictionary level. For example, they incorporate blank nodes and set nodes into a unified node identifier system for management. At the underlying encoding design level, a structured list format specifically defined for storing pure data has been developed to efficiently process and store sets containing only basic numerical values ​​or strings (i.e., "character counts").

[0007] Therefore, in response to the needs of engineering product data in terms of semantic expression, performance controllability, expression uniqueness, difference extraction, version traceability, and set node expression, there is an urgent need for a general semantic expression system and its implementation method for engineering product data, so as to achieve deterministic representation and engineering-level high-performance processing while ensuring semantic expression capabilities, and support data management and evolution tracking throughout the entire lifecycle. Summary of the Invention

[0008] In view of this, embodiments of this application provide a structured semantic representation system and its implementation method for engineering product data, which solves the problems of poor expressive power, low processing efficiency and poor semantic accuracy faced in the field of engineering data semantic representation in the prior art.

[0009] The first aspect of this application provides a structured semantic representation system for engineering product data, comprising: one or more named graphs, each including a header region, a dictionary region, and a content region; a header region used to describe global information of the named graph at the semantic level; a dictionary region used to enumerate all non-character type nodes appearing in the named graph at the logical level and assign a unique index identifier to each node, the non-character type nodes including IRI type nodes and blank type nodes, where IRI type nodes are semantic nodes identified by Internationalized Resource Identifiers and blank type nodes are semantic nodes without explicit IRI identifiers; a content region used to record engineering product data according to triples using the node index identifiers and to store the triples by node, the triples including subject, predicate, and object; and statistical information used to record global metadata.

[0010] In conjunction with the first aspect, in some possible implementations, the header region includes at least one of the following: a version field for identifying the file type and logical version number; a logical structure for distinguishing different versions of the naming graph; an identifier of the current naming graph for uniquely identifying the naming graph; an ordered list of identifiers of other naming graphs referenced and imported by the current naming graph, wherein the triples of nodes in the imported naming graphs are visible to the current naming graph; and an ordered list of identifiers of other naming graphs referenced but not imported by the current naming graph, wherein the triples of nodes in the unimported naming graphs are not visible to the current naming graph. The dictionary area includes at least one of the following: the number of IRI type nodes and blank nodes belonging to the current named graph; an ordered list of IRI identifiers of IRI type nodes belonging to the current named graph and the total number of associations of each IRI type node in the current named graph; an ordered list of blank type nodes belonging to the current named graph and the total number of associations of each blank type node in the current named graph; the number of IRI type nodes belonging to referenced and imported named graphs; an ordered list of IRI identifiers of IRI type nodes belonging to referenced and imported named graphs and the number of times each IRI type node is referenced by the current named graph; the number of IRI type nodes belonging to referenced but not imported named graphs; and the IRI identifiers of IRI type nodes belonging to referenced but not imported named graphs and the number of times each IRI type node is referenced by the current named graph. The content area includes at least one of the following: the number and sequence of triples for non-character quantifier objects belonging to IRI type nodes and blank type nodes of the current named graph, with the sequence of triples for non-character quantifier objects sorted according to "predicate index – object index"; and the number and sequence of triples for character quantifier objects belonging to IRI type nodes and blank type nodes of the current named graph, with the sequence of triples for character quantifier objects sorted according to "predicate index – literal value". Preferably, the identifier of the named graph includes an IRI string. In different versions of the same named graph, the IRI string is the same, but the nodes and triples are different, and the logical version number is different.

[0011] In conjunction with the first aspect, in some possible implementations, there are differences in the data boundary ranges between the named graph referenced and imported by the current named graph and the named graph referenced by the current named graph but not imported. Specifically, the nodes and triples in the named graph referenced and imported by the current named graph are known to the current named graph, and all triples of the corresponding nodes in the imported named graph can be obtained through the reference of the current named graph to the triples of the imported named graph. The nodes and triples in the named graph referenced by the current named graph but not imported are not visible to the current named graph, and all triples of the corresponding nodes in the unimported named graph cannot be obtained through the reference of the current named graph to the triples of the unimported named graph.

[0012] In conjunction with the first aspect, in some possible implementations, IRI type nodes belong to at least one named graph, and only the belonging named graph allows the corresponding IRI type node to be written as the subject in the triple; blank type nodes belong to a named graph, and only the belonging named graph allows the blank type node to be written as the subject in the triple, and only the belonging named graph allows the blank type node to be referenced within the belonging named graph.

[0013] In conjunction with the first aspect, in some possible implementations, IRI type nodes can simultaneously function as class and individual, or simultaneously as attribute and individual, within a triple.

[0014] In conjunction with the first aspect, in some possible implementations, blank type nodes include ordinary blank nodes and non-character set nodes; in the content area, IRI type nodes and ordinary blank nodes are represented by sorted index values, non-character set nodes themselves participate in the statistical sorting of the dictionary area, and the set element triples inside non-character set nodes do not participate in the node triple sorting of the content area.

[0015] In conjunction with the first aspect, in some possible implementations, the character type nodes in the content area include ordinary character nodes and character set nodes; ordinary character nodes include a type code and a number, and the type code includes one or more of the following: text string type code, boolean type code, integer type code, floating-point number type code, date type code, time type code, and date and time type code; character set nodes include a type code, the number of numbers, and multiple numbers, with the multiple numbers having the same type code.

[0016] The second aspect of this application provides a method for implementing a structured semantic representation system for engineering product data, comprising: constructing an engineering semantic model for a specific domain based on the engineering product data, the engineering semantic model including multiple engineering entities and their type constraints, multiple semantic attributes and their attribute constraints; parsing the engineering product data into one or more intermediate named graphs based on the engineering semantic model, each intermediate named graph having a unique identifier and consisting of multiple triples, the subject, predicate, and object of the triples corresponding to an engineering entity, a semantic attribute, and an engineering entity or literal value, respectively; and performing the following steps for each intermediate named graph: statistical analysis. The reference relationships between intermediate named graphs and other intermediate named graphs are determined by obtaining an ordered list of identifiers of other intermediate named graphs that reference and import other intermediate named graphs and reference but not import other intermediate named graphs. This list, combined with the identifier of the current intermediate named graph, generates the header region of the named graph. The number of IRI type nodes and blank type nodes belonging to the current intermediate named graph, along with the total number of associations in the current named graph, are counted, and the nodes are sorted according to their identifiers. The IRI type nodes belonging to the current intermediate named graph and the total number of associations of IRI type nodes in the current intermediate named graph are enumerated sequentially. The blank type nodes belonging to the current intermediate named graph are also enumerated sequentially. The system calculates the total number of associations for nodes and blank nodes in the current intermediate naming graph; it counts the number of IRI type nodes and their reference counts in other intermediate naming graphs referenced by the current intermediate naming graph, and sorts the nodes by their identifiers; based on an ordered list of identifiers of other intermediate naming graphs that reference and import, and reference but not import, it sequentially enumerates the IRI type nodes belonging to the referenced intermediate naming graphs and their reference counts to generate the dictionary area of ​​the naming graph; and it counts the number of non-literal type object triples and literal type object triples belonging to the IRI type nodes and blank nodes in the current intermediate naming graph. Based on the sorting results and index information of IRI type nodes and blank type nodes, the system sequentially records the triples with that node as the subject for each node, where the predicate is represented by the predicate index and the object is represented by the object index or a "literal reference", generating the content area of ​​the named graph, thus completing the generation of the current intermediate named graph; based on all named graphs, the system generates statistical information, including the total number of named graphs, the named graph IRI identifier, the named graph version number, the named graph hash value, and at least one of the following: the generation time of the structured semantic expression system, the generator, and the system hash value, thus completing the construction of the structured semantic expression system.

[0017] In conjunction with the second aspect, in some possible implementations, the engineering semantic model can be modeled and represented using the Resource Description Framework (RDF), the RDF architecture (RDFS), and the Web Ontology Language (OWL). This includes: using "rdfs:Resource" or "owl:Class" to represent multiple engineering object classes, defining the abstract concept of engineering objects, which include at least one of product, component, connection point, working condition, event, and measurement quantity; using the subclass "owl:ObjectProperty" of "rdf:Property" to represent multiple engineering relationship attributes, describing at least one of structural, participation, and temporal relationships between engineering objects; and using the subclass "owl:ObjectProperty" of "rdf:Property"... ":DatatypeProperty" represents multiple project data attributes used to describe the identifier, name, code, and numerical parameters of a project object. Each project relation attribute and project data attribute declares its scope through "rdfs:domain" and "rdfs:range" respectively, and constrains the project semantic attributes through "rdfs:subClassOf", "rdfs:subPropertyOf" and at least one OWL axiom, including but not limited to "owl:FunctionalProperty", "owl:InverseFunctionalProperty" or "owl:TransitiveProperty".

[0018] In conjunction with the first aspect, in some possible implementations, the triple is represented as <subject, verb, object>; or, the number of triples of the current subject is N and there are N <verb index, object index or literal reference> pairs.

[0019] The structured semantic representation system and its implementation method for engineering product data provided in the embodiments of this application achieve the following technical effects.

[0020] First, it enhances the semantic expressiveness of engineering data, making the semantics explicit. By introducing engineering semantic models and semantic graphs, information such as components, connection relationships, operating conditions, and physical quantities are uniformly represented as ternary relationships, explicitly expressing engineering semantics and facilitating cross-system understanding and automatic processing.

[0021] Secondly, it improves the efficiency of engineering data processing. This solution creatively provides a logical file format for the SST system, the core of which is a "global node index" (dictionary area) plus a "file folder archived by node" (content area) structure. In this way, when querying data, the system is as efficient as pulling out all the file folders of a person by number in an archive, transforming the complex search based on the named graph into a direct location based on the index, resulting in an order-of-magnitude improvement in performance.

[0022] Third, it improves the semantic accuracy of engineering data. By using fixed encoding rules, it ensures that the physical files generated from the same knowledge are completely identical at the byte level, achieving a unique and authoritative expression of the data. Furthermore, relying on the versioning mechanism of the naming graph, it makes all changes traceable and comparable, completely eliminating ambiguity. Attached Figure Description

[0023] Figure 1 This is a structural block diagram of a structured semantic representation system for engineering product data provided in an embodiment of this application.

[0024] Figure 2 A schematic diagram of the structure of the 3D part model is shown.

[0025] Figure 3 This is a flowchart illustrating the implementation method of a structured semantic representation system for engineering product data provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In the accompanying drawings, the dimensions of layers and regions may be exaggerated for clarity. It is understood that when a structure is referred to as being "on" or "below" another structure, the structure may be directly on or below the other structure, or there may be intermediate structures. The same reference numerals always indicate the same structure. Structures referred to herein include any of the following: membrane, element, device, component, assembly.

[0028] When a structure is referred to as being “connected” to another structure, it can be directly connected to the other structure or indirectly connected to the other structure by means of one or more intermediate structures placed between them.

[0029] Figure 1 This is a structural block diagram of a structured semantic representation system for engineering product data provided in one embodiment of this application. Figure 1 As shown, the Structured Semantic Technology (SST) system 100 for engineering product data includes: one or more named graphs 110 and statistical information 120.

[0030] Named diagram 110 records all semantic data of the engineering product, covering the entire product lifecycle from design to retirement. It does not simply store raw files, but transforms various aspects of the product information into structured semantic assertions that are understandable to machines. One engineering product can correspond to one or more named diagrams 110.

[0031] For example, one engineering product corresponds to one named diagram 110. The application scenario could be a relatively simple 3D part, such as a bolt or gear. In this case, all the data of the product, including geometry, attributes, and relationships, are recorded in the same named diagram.

[0032] One engineering product corresponds to multiple named diagrams 110, and these multiple named diagrams 110 are respectively denoted as named Figure 1 ,name Figure 2 ...Named diagram X...Named diagram N, where N is any positive integer. The application scenario can be a complex system product, such as a complete car engine. In this case, multiple named diagrams 110 can correspond to multiple logical modules of the engineering product. For example, the engine assembly, cylinder block module, crankshaft system, turbocharger, and control system each correspond to a named diagram 110. Multiple named diagrams 110 can also correspond to different data types of the engineering product. For example, geometric design diagrams, material property diagrams, process manufacturing diagrams, testing and verification diagrams, and operation and maintenance data diagrams each correspond to a named diagram 110. Furthermore, the same named diagram can be referenced by multiple engineering products. For example, named diagrams for standard parts (such as bolts and washers) and general modules (such as battery packs and displays) can be referenced by multiple different products simultaneously.

[0033] Statistics 120 is used to record global metadata, which is a macro-level summary and governance information of the entire SST system. For example, statistics 120 includes basic statistics, such as the total number of named graphs, the generation time of the named graphs, the user identifier of the user who produced the named graphs, and the version number of the named graphs; a list of named graphs and metadata, such as the identifier of the named graph, version number, hash value, number of triples contained, and last modification time; and extended management information, such as confidentiality level, validity period, associated projects, and storage location.

[0034] In one embodiment, the identifier of a named graph includes an Internationalized Resource Identifier (IRI) string. Different versions of the same named graph share the same IRI string, but differ in nodes, triples, and logical version numbers. Thus, in the SST system, the identity of a named graph (i.e., its IRI identifier) ​​is decoupled from its content (including nodes and triples). Modifying a named graph will cause changes to nodes and / or triples, generating a new logical version number, but the identifier of the modified named graph remains unchanged. In this way, the IRI identifier of a named graph can act as a "digital genetic ID card" that anchors itself throughout its digital lifecycle, enabling traceability.

[0035] Engineering product data includes two types: character-based and non-character-based. Character-based types refer to the raw data values ​​themselves, which can only be used as objects, not subjects. Non-character-based types refer to identified "resources" or objects, including IRI-type nodes and blank type nodes. IRI-type nodes are semantic nodes identified by Internationalized Resource Identifiers (IRIs), while blank type nodes are semantic nodes without explicit IRI identification. Blank type nodes include ordinary blank nodes and non-character-based set nodes. Ordinary blank nodes are typically used to represent an anonymous resource that does not require a global identifier, or as temporary join points in complex data structures. Their internal structure is simple, possibly associating only a few triples. Non-character-based set nodes are blank nodes with a specific internal structure used for a specific purpose. Their sole purpose is to represent an ordered list.

[0036] See Figure 1 The naming graph 110 includes a header region S1, a dictionary region S2, and a content region S3. The header region S1 contains the identification information of the current naming graph and the reference relationships between it and related naming graphs. The dictionary region S2 enumerates all IRI type nodes and blank type nodes, assigning a unique index to each node. The content region S3 records triple relationships according to node indices, processing the number of triples and their ordered sequences for non-character literal objects and character literal objects, respectively.

[0037] The header region S1 is used to describe the global information of the named graph at the semantic level. Here, "semantic level" refers to the meaning, significance, and interpretation of the data, rather than the physical storage form or syntactic structure of the data. In other words, the header region S1 describes what the named graph 110 is, not how the named graph 110 is stored.

[0038] Dictionary area S2 is used to enumerate all non-character type nodes appearing in the naming graph at the logical level and assign a unique index identifier to each node. The index identifier is, for example, an integer sequence, i.e., 1, 2, 3... Non-character type nodes include IRI type nodes and blank type nodes. IRI type nodes are semantic nodes identified by an Internationalized Resource Identifier (IRI), while blank type nodes are semantic nodes without an explicit IRI identifier. In other words, IRI type nodes have an explicit IRI identifier, meaning the node possesses an identifier that is well-known outside the document or system and can be directly written and accessed. Any triple can point to this node by fully writing out this IRI identifier. Correspondingly, blank type nodes have a non-explicit IRI identifier, meaning the node does not have a globally referenceable, persistent IRI identifier. It only has a temporary, local, internal identifier. This identifier is only valid within the current document or a specific data context and cannot be directly addressed or globally referenced from outside.

[0039] The content area S3 is used to record engineering product data according to triples based on the node index identifier, and to store the triples by node. The triples include subject, predicate and object.

[0040] In one embodiment, the header region S1 includes at least one of the following: a version field for identifying the file type and logical version number; a logical structure for distinguishing different versions of the SST file; an identifier of the current naming graph for uniquely identifying the naming graph; an ordered list of identifiers of other naming graphs referenced and imported by the current naming graph, wherein the triples of nodes in the imported naming graphs are visible to the current naming graph; and an ordered list of identifiers of other naming graphs referenced but not imported by the current naming graph, wherein the triples of nodes in the unimported naming graphs are not visible to the current naming graph.

[0041] There are differences in data boundary ranges between named graphs referenced and imported by the current named graph and named graphs referenced but not imported by the current named graph. Nodes and triples in a named graph referenced and imported by the current named graph are known to the current named graph; by referencing triples in the imported named graph through the current named graph, all triples of the corresponding nodes in the imported named graph can be obtained. Nodes and triples in a named graph referenced but not imported by the current named graph are not visible to the current named graph; by referencing triples in a non-imported named graph through the current named graph, all triples of the corresponding nodes in the non-imported named graph cannot be obtained. This example illustrates two different external dependency management methods in the SST system: "reference and import" and "reference only, no import." These are key technical rules for achieving data boundary isolation and dependency minimization. By switching between "import" and "no import," it provides flexible engineering control between "requiring deep integration" and "maintaining lightweight references," forming the cornerstone for achieving large-scale, maintainable engineering semantic data systems.

[0042] The dictionary region S2 includes at least one of the following: the number of IRI type nodes and blank nodes belonging to the current named graph; an ordered list of IRI identifiers of IRI type nodes belonging to the current named graph and the total number of associations of each IRI type node in the current named graph; an ordered list of blank type nodes belonging to the current named graph and the total number of associations of each blank type node in the current named graph; the number of IRI type nodes belonging to referenced and imported named graphs; an ordered list of IRI identifiers of IRI type nodes belonging to referenced and imported named graphs and the number of times each IRI type node is referenced by the current named graph; the number of IRI type nodes belonging to referenced but not imported named graphs; and the IRI identifiers of IRI type nodes belonging to referenced but not imported named graphs and the number of times each IRI type node is referenced by the current named graph.

[0043] In the SST system, IRI type nodes belong to at least one named graph, and only the belonging named graph allows the corresponding IRI type node to be written as the subject in triples. Blank type nodes belong to a named graph, and only the belonging named graph allows blank type nodes to be written as the subject in triples, and blank type nodes can only be referenced within the belonging named graph. Specifically, an IRI type node is like a "citizen" of a country, while a blank type node is like a "temporary resident." In the SST system, when an IRI type node is first created and used, it belongs to its creator (i.e., the named graph), becoming a "citizen" of that named graph. This IRI type node can only be written as the subject in triples by at least one of its belonging named graphs, while other named graphs can only mention (e.g., reference) the IRI type node as the object in triples, not as the subject. Blank type nodes belong only to their belonging named graph and can only be referenced within their belonging named graph, not by other named graphs. In this way, the SST system establishes an orderly and scalable distributed data governance model, which completely solves the common problems of permission confusion and conflict in traditional data sharing, and is the cornerstone for the engineering implementation of the whole method.

[0044] Content area S3 includes at least one of the following: the number and sequence of non-character quantifier triples belonging to IRI type nodes and blank type nodes of the current named graph, with the sequence of non-character quantifier triples sorted by "predicate index – object index"; and the number and sequence of character quantifier triples belonging to IRI type nodes and blank type nodes of the current named graph, with the sequence of character quantifier triples sorted by "predicate index – literal value".

[0045] In the SST system, IRI-type nodes can simultaneously function as both a class and an individual, or both an attribute and an individual. Within a triple, the "class" can be the object, the "individual" can be the subject or object, and the "attribute" can be the predicate. A "class" is an abstract category or concept, such as a car, an employee, or a geometric point. An "attribute" is an abstract relationship or characteristic, such as being manufactured in, belonging to a department, or having coordinates. An "individual" is a concrete instance, such as an employee named Zhang San or a point with coordinates (1,2,3). Therefore, in the SST system, a "data content" identified by an IRI can simultaneously play multiple logical roles, demonstrating the flexibility of resource roles.

[0046] In one embodiment, blank type nodes include ordinary blank nodes and non-character set nodes. In content region S3, IRI type nodes and ordinary blank nodes are represented using sorted index values. Non-character set nodes themselves participate in the statistical sorting of dictionary region S2, and the set element triples inside non-character set nodes do not participate in the node triple sorting of content region S3.

[0047] In this embodiment, the non-character type nodes in the content area S3 are divided into three categories: IRI type nodes, ordinary blank nodes, and non-character set nodes.

[0048] In the content area S3, IRI type nodes and ordinary blank nodes can directly use sorted index values. That is, when storing a triple in the content area S3, the nodes corresponding to the subject, predicate, and object are not stored. Instead, the integer index numbers of the nodes, which are allocated in the dictionary area S2 and have a pre-defined sorting, are stored. In this way, storage can be greatly compressed, facilitating the rapid location of triples.

[0049] In content region S3, non-character set nodes are treated as blank nodes and participate in the statistical sorting of dictionary region S2. That is, a non-character set node is treated as a regular blank node in dictionary region S2 and assigned an index number. This allows the entire non-character set node to be referenced by a stable index at the top level. However, the triples of elements within a non-character set node do not participate in the node triple sorting in content region S3. The advantage of this is that it guarantees the absolute stability of the order of elements within the non-character set node. If these internal triples were broken up and reordered according to their subjects, the entire linked list order might be lost or disordered. When the system needs to read this set, it directly locates this data block and parses the entire list completely in the order it was written.

[0050] In one embodiment, the character type nodes in the content area S3 include ordinary character type nodes and character set nodes. Ordinary character type nodes include a type code and a number. The type code includes one or more of the following: text string type code, boolean type code, integer type code, floating-point number type code, date type code, time type code, and date / time type code. Character set nodes include a type code, the number of numbers, and multiple numbers, where the type code for the multiple numbers is the same.

[0051] This embodiment defines how the content area S3 in the SST system handles character quantity data. A regular character quantity node is represented as a combination of a type code and a numerical value. The type code indicates the type of the numerical value and can be represented by an integer. For example, 1 represents a string, 2 represents an integer, 3 represents a floating-point number, 4 represents a date, etc. A character quantity set node is represented as a combination of a type code, the number of numerical values, and multiple numerical values, stored in the format: [type code] + [number of numerical values ​​N] + [value 1] + [value 2] + ... + [value N]. For example, a three-dimensional coordinate (55.5, 10.5, 0.0) can be stored as a compact data block, i.e., [3] + [3] + [55.5] + [10.5] + [0.0].

[0052] The following example uses a 3D part model to illustrate the naming convention for that 3D part model. Figure 2 A structural schematic diagram of the 3D part model is shown. In this embodiment, Figure 110 is named as follows: 1. Head region S1 (1) The identifier of the current named graph is used to uniquely identify the named graph. For example, in this embodiment, the IRI identifier is used to identify the named graph.

[0053] urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb (2) Imported and referenced diagrams In this embodiment, the number of imported named graphs is 0, and the number of named graphs referenced but not imported is 5. That is, the current named graph does not import other named graphs, but it will import the following 5 external named graphs: http: / / ontology.semanticstep.net / rep (Geometric Representation Naming Diagram) http: / / ontology.semanticstep.net / ssmeta (Metadata represents a named graph) http: / / ontology.semanticstep.net / sso (Semantic Object Naming Diagram for Engineering Products) http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns (W3C standard vocabulary, used to express any data as triples) http: / / www.w3.org / 2000 / 01 / rdf-schema (W3C standard vocabulary, providing the most basic descriptions of classes and properties) By using "reference but not import", classes and properties from the above ontology can be used for modeling in the current named graph, but the current named graph is not required to hold all the contents of its triples, thereby achieving data boundary isolation and dependency minimization.

[0054] 2. Dictionary area S2 (1) The ordered index of all nodes in the current named graph.

[0055] IRI Node Count: 555 Blank Node Count: 42 Index 1 IBNode:urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#010dbc9 d-ae4a-416d-96e9-a791732767ed Triple Count:1 Index 2 IBNode:urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#0132b06 d-e176-41c6-bca9-d5590fadf763 Triple Count:3 ··· Index 148 IBNode:urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#4f246 9a9-f1bf-410d-a87e-b7cb963d9966 Triple Count:3 ··· Index 421 IBNode:urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079 edc-5326-4ef2-944e-5caa91841d33 Triple Count:2 ··· Index 554 IBNode:urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#ff3b2 167-d703-4c2f-b5b8-70b452accec1 Triple Count:7 Index 555 IBNode:_:8a968903-017b-4a5a-8f12-5448150f7fd4 Triple Count:7 Index 556 IBNode:_:64947f22-b06c-4d65-b2de-441279d9b24c Triple Count:3 ··· Index 596 IBNode:_:e3c56497-6896-454d-9e2c-846c7f8ae67d Triple Count:2 Here, “IRI Node Count:555” means that the number of IRI type nodes is 555.

[0056] "Blank Node Count:42" means that the number of blank nodes is 42.

[0057] "Index 1 to "Index 554" are index fields in dictionary area S2 used to manage IRI type nodes. Taking "Index 1" as an example, it represents the current node's sequence number (i.e., index identifier) ​​as 1. "IBNode:urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#010dbc9d-ae4a- "416d-96e9-a791732767ed" represents the current node's IRI identifier as "urn:uuid:a87af91f- d0ef-45e8-a117-d058e329cdfb#010dbc9d-ae4a-416d-96e9-a791732767ed”, meaning the number of triples associated with the current node is 1.

[0058] The index fields from "Index 555" to "Index 596" are index fields in dictionary region S2 used to manage blank nodes. Taking "Index 555" as an example, it represents the current node's sequence number (i.e., index identifier) ​​as 555. "IBNode:_:8a968903-017b-4a5a-8f12-5448150f7fd4" indicates that the current node's identifier is a blank node identifier (starting with _:), and its internal identifier is "8a968903-017b-4a5a-8f12-5448150f7fd4". Unlike IRI type nodes, blank type node identifiers are only valid within the current named graph and do not have globally unique referenceability. "Triple Count:7" indicates that the number of all triples associated with the current node is 7.

[0059] It should be noted that a large number of nodes in the current named graph use the format urn:uuid:...#... to provide identification for the parsed engineering entities (e.g., points, directions, edges, faces, shells, solids, product objects, etc.).

[0060] (2) Nodes belonging to the referenced named graph In this example, dictionary region S2 contains key term nodes from the referenced ontology and their reference counts. For example, in this embodiment, terms related to geometric topology belong to http: / / ontology.semanticstep. The nodes of the net / rep naming graph (partial list) include: Referenced Graph IRI: http: / / ontology.semanticstep.net / rep Referenced IRI Node Count: 58 Index 597 IBNode: http: / / ontology.semanticstep.net / rep#AdvancedBrepSh apeRepresentation Referenced Count:1 Index 598 IBNode:http: / / ontology.semanticstep.net / rep#AdvancedFace Re Referenced Count: 16 Index 599 IBNode: http: / / ontology.semanticstep.net / rep#Axis2Placement3D Referenced Count: 21 Index 600 IBNode:http: / / ontology.semanticstep.net / rep#CartesianPointReferenced Count:79 Index 601 IBNode:http: / / ontology.semanticstep.net / rep#CircleReferenced Count:4 ··· Here, "Referenced Graph IRI:http: / / ontology.semanticstep.net / rep" means that the IRI identifier of the currently referenced named graph is http: / / ontology.semanticstep.net / rep, and "ReferencedIRI Node Count: 58" means that the total number of nodes referenced by the current named graph in this referenced named graph is 58.

[0061] Take Index 597 IBNode: http: / / ontology.semanticstep.net / rep#AdvancedBrep For example, with ShapeRepresentation Referenced Count: 1, "Index 597" means the current node's index is 597. (http: / / ontology.semanticstep.net / rep#AdvancedBrepShape) "Representation" represents the IRI identifier of the current node, which is "http: / / ontology.semanticstep.net / ". rep#AdvancedBrepShapeRepresentation”, “Referenced Count:1”, means that the referenced node is referenced once in the current named graph.

[0062] The basic W3C vocabulary referenced in this example belongs to the naming diagram: http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns, specifically includes: Referenced Graph IRI: http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns Referenced IRI Node Count: 3 Index 663 IBNode:http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#List Referenced Count: 57 Index 664 IBNode: http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#first Referenced Count: 119 Index 665 IBNode: http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type Referenced Count: 476 This section contains detailed records of the "referenced nodes" in dictionary area S2, precisely describing how the current named graph uses the most basic semantic web "syntax" vocabulary from the W3C. The named graph references three terms from http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns: "rdf-syntax-ns#List", "rdf-syntax-ns#first", and "rdf-syntax-ns#type". These terms are numbered 663, 664, and 665, and have been referenced 57, 119, and 476 times, respectively.

[0063] The semantic object naming diagram for engineering products referenced in this example is http: / / ontology.semanticstep. net / sso, specifically includes: Referenced Graph IRI: http: / / ontology.semanticstep.net / sso Referenced IRI Node Count: 6 Index 657 IBNode:http: / / ontology.semanticstep.net / sso#Part ReferencedCount:1 Index 658 IBNode: http: / / ontology.semanticstep.net / sso#PartDesignReferen ced Count:1 Index 659 IBNode: http: / / ontology.semanticstep.net / sso#PartVersionReferen ced Count:1 Index 660 IBNode: http: / / ontology.semanticstep.net / sso#definingGeometry Referenced Count: 1 Index 661 IBNode: http: / / ontology.semanticstep.net / sso#hasPartVersionRefe renced Count:1 Index 662 IBNode: http: / / ontology.semanticstep.net / sso#hasProductDefiniti on Referenced Count:1 This section records another set of key terms related to references in dictionary area S2. It describes how the current 3D part model file uses the vocabulary from the "Engineering Product Semantic Object (SSO)" ontology to construct its top-level business logic and product structure. This naming diagram is from http: / / ontology The .semanticstep.net / sso file references six key terms, including three core entities: “sso#Part”, “sso#PartDesign”, and “sso#PartVersion”; two core key attributes: “sso#hasProductDefinition” and “sso#hasPartVersion”; and one key connection attribute: “sso#definingGeometry”.

[0064] Through the above mechanism, this embodiment ensures that the current named graph has write rights to the nodes that "belong" to it, and for other named graphs that are referenced, only the IRI identifier of the other party is referenced, and not all of its data is copied, thereby achieving consistent node permission management.

[0065] 3. Content Area S3 The system writes triples in content area S3 according to the subject node index. In this embodiment, the product object layer uses an SSO naming diagram to express the semantics of parts, versions, and design definitions, as detailed below.

[0066] (1) Create a Part object and associate it with a Part version.

[0067] In content region S3, there exists a node with a subject index of 421, whose triples contain: subject index: 421 non-literal triple count: 2 predicate index: 665 object index: 657 predicate index: 661 object index: 148 literal triple count: 0 Here, “subject index:421” means that the current subject is the node with index 421, namely the node “urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33”.

[0068] "non-literal triple count:2" means that the number of non-literal triples in the current subject is 2.

[0069] "predicate index:665 object index:657" means the predicate index of the first triple is 655, i.e., the predicate node (http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type), and the object index is 657, i.e., the object node (http: / / ontology.semanticstep.net / sso#Part). The current triple is (urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type, http: / / ontology.semanticstep.net / sso#Part). gy.semanticstep.net / sso#Part).

[0070] The expression "predicate index:661 object index:148" indicates that the predicate index of the second triple is 661, which is the predicate node (http: / / ontology.semanticstep.net / sso#hasPartVersion), and the object index is 148, which is the object node (urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#4f24). 69a9-f1bf-410d-a87e-b7cb963d9966. The current triple is (urn:uuid:a87af91f-d0ef- 45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, http: / / ont ology.semanticstep.net / sso#hasPartVersion, urn:uuid:a87af91f-d0ef-45e8-a117 -d058e329cdfb#4f2469a9-f1bf-410d-a87e-b7cb963d9966).

[0071] "literal triple count:0" means that the number of character type triples in the current subject is 0.

[0072] The above content includes two parts: creating part objects and associating part versions. Creating part objects involves: subject index 421 corresponding to a unique node created by this naming graph (i.e., urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33); predicate index 665 corresponding to rdf:type (from the W3C basic vocabulary); and object index 657 corresponding to sso#Part (from the engineering product semantic object ontology). Therefore, the first triple is: 421, 665, 657. The semantic triple corresponding to this triple is (urn:uuid:a87af91f- d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type, http: / / ontology.semanticstep.net / sso#Part), whose semantics is to declare the node at index 421 as a part.

[0073] The associated part version includes: predicate index 661 corresponds to sso#hasPartVersion (from the engineering product semantic object ontology, meaning "has a part version"); object index 148 corresponds to another unique node created by this naming graph (e.g., urn:uuid:a87af91f...#4f2469a9...); this object node (i.e., index 148) is declared as type sso#PartVersion in point (2) of the following content. Therefore, the second triple is: 421,661,148. The semantic triple corresponding to this triple is (urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e- 5caa91841d33, http: / / ontology.semanticstep.net / sso#hasPartVersion, urn:uuid: a87af91f-d0ef-45e8-a117-d058e329cdfb#4f2469a9-f1bf-410d-a87e-b7cb963d99 66), whose semantics is that this part (i.e., index 421) has a part version (i.e., index 148).

[0074] (2) Create a version (PartVersion) and associate it with the product definition (PartDesign).

[0075] Subject index: 148 non-literal triple count: 2 predicate index: 665 object index: 659 predicate index: 662 object index: 132 literal triple count: 0 The creation of the version object includes: predicate index 665 corresponding to rdf:type (a W3C basic vocabulary, meaning "is a...type"); object index 659 corresponding to sso#PartVersion (the "part version" class in the SSO ontology); and subject index 148, which is the node associated with the part as the object in the previous step. Therefore, the first triple is: 148, 665, 659. Its corresponding semantic triple is (urn:uuid:a87af9). 1f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, ttp: / / ww w.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type, http: / / ontology.semanticstep.net / sso#Part Version), whose semantics is to declare the node at index 148 as a part version.

[0076] The associated product definition includes: predicate index 662 corresponds to sso#hasProductDefinition (an attribute in the SSO ontology, meaning "has a product definition"); object index 132 corresponds to another unique node created by this naming graph; this object node (i.e., index 132) will be declared as sso#PartDesign type in subsequent point (3). Therefore, the second triple is: 148, 662, 132. Its corresponding semantic triple is (urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2- 944e-5caa91841d33, http: / / ontology.semanticstep.net / sso#hasProductDefinition, urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#48f41025-e882-4e16-963f-e391336a332c), its semantics is that this part version (i.e., index 148) has a product definition (i.e., index 132).

[0077] (3) Create a design definition (PartDesign) and associate it with a geometry definition (definingGeometry).

[0078] subject index: 132 non-literal triple count: 2 predicate index:665 object index:658 predicate index:660 object index:25 literal triple count: 0 The creation of the design definition includes: predicate index 665 corresponds to rdf:type; object index 658 corresponds to sso#PartDesign (the "Part Design Definition" class in the SSO ontology); subject index 132 is the node that was associated with the version as the object in the previous step. Therefore, the first triplet is: 132, 665, 658. Its corresponding semantic triplet is (urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326- 4ef2-944e-5caa91841d33, ttp: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type, http: / / (ontology.semanticstep.net / sso#PartDesign), its semantics are to declare the node at index 132 as a part design definition. This is equivalent to creating a container to hold all the specific design information for this version of the part.

[0079] The associated geometry definition includes: predicate index 660 corresponds to sso#definingGeometry (a key attribute in the SSO ontology, meaning "defined by... geometry"); object index 25 corresponds to a node representing a specific geometric model; this object node (i.e., index 25) is declared as type rep#AdvancedBrepShapeRepresentation in the subsequent "Geometric Representation Layer" section, which is a high-level geometry shape for boundary representation. Therefore, the second triple is: 132,660,25. The semantic triple corresponding to this triple is (urn: uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, http: / / ontology.semanticstep.net / sso#definingGeometry, urn:uuid:a87af91f- The semantics of d0ef-45e8-a117-d058e329cdfb#12014f23-09ac-489e-8552-5fd6e434c279 are that the geometry of this part design definition (i.e., index 132) is defined by a certain geometric representation (i.e., index 25). This is the core bridge connecting the business world and the geometric world.

[0080] Through the aforementioned triplet relationships, the named graph realizes the semantic connection between the semantic objects and geometric representations of engineering products, namely the semantic connection between Part, PartVersion, PartDesign, and DefiningGeometry.

[0081] 4. Geometric Representation Layer (1) Geometric representation of nodes subject index:25 non-literal triple count: 3 predicate index:665 object index:597 predicate index:663 object index:186 predicate index:663 object index:556 literal triple count: 0 This node (i.e., subject index 25) is the core entry point of the geometric representation layer in the entire data chain. It connects to the upper-level product design definition and initiates the specific geometric data structure.

[0082] The first triple is used to declare the type of the node, with the semantics that the node at index 25 is a high-level boundary representation shape. This formally defines the geometric identity of this node. It indicates that this node follows the "high-level boundary representation" method defined in the ISO 10303 (STEP) standard to describe 3D shapes, which is a precise, face- and edge-based solid modeling approach.

[0083] The second and third triples are used to associate the large core components that make up the geometric representation. These two triples share the same predicate rdf:List (index 663), but point to different objects, indicating that the geometric representation consists of two list structures. The semantics of these two triples are that the shape corresponding to index 25 contains two lists, namely list 186 and list 556.

[0084] In this embodiment, the node with a subject index of 25 is declared as: urn:uuid:a87af91f-d0ef- 45e8-a117-d058e329cdfb#12014f23-09ac-489e-8552-5fd6e434c279 has three triples: (urn:uuid:a87af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2- 944e-5caa91841d33, http: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#type, http: / / onto logy.semanticstep.net / rep#AdvancedBrepShapeRepresentation), (urn:uuid:a87af) 91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, htt p: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#List,urn:uuid:a87af91f-d0ef-45e8- a117-d058e329cdfb#62164fbe-79c2-4bab-8044-d50a056bf8e9), (urn:uuid:a87 af91f-d0ef-45e8-a117-d058e329cdfb#cb079edc-5326-4ef2-944e-5caa91841d33, htt p: / / www.w3.org / 1999 / 02 / 22-rdf-syntax-ns#List,_:64947f22-b06c-4d65-b2de-441 279d9b24c).

[0085] (2) Establish the geometric representation context and uncertainty.

[0086] In this embodiment, the node with subject index 186 includes: rdf:type ->rep#GeometricRepresentationContext(object index = 613) rdf:type ->rep#GlobalUncertaintyAssignedContext(object index = 614) rep#globalUncertainty -><Uncertainty Structure Node> (predicate index = 643, object index = 567) This structure is used to express global conditions such as coordinate context, accuracy / uncertainty, etc. of geometric representation, which facilitates subsequent geometric calculations and consistency verification.

[0087] The first triple is declared as "Geometric Representation Context," with the predicate "rdf:type" and an object index of 613, pointing to the object "rep#GeometricRepresentationContext." The first triple means that "the node with index 186 is a geometric representation context." "Geometric representation context" is a fundamental concept in the STEP standard. It defines the coordinate space dimension (e.g., 3D space) and the number of coordinate systems (e.g., only one global coordinate system) in which the geometric model resides. It answers the fundamental question, "In what mathematical space is this model described?"

[0088] The second triple is declared as "global uncertainty-specified context," with the predicate "rdf:type" and the object index 614, pointing to the object "rep#GlobalUncertaintyAssignedContext." The second triple means "the node at index 186, which is also a global uncertainty-specified context." This is a more specific context type, indicating that a global precision or tolerance is specified for this context.

[0089] The third triplet is associated with a specific uncertainty value. Its predicate index is 643, pointing to the predicate "rep#globalUncertainty," and its object index is 567. This object is a structure node describing the specific content of the uncertainty. The meaning of the third triplet is "the global uncertainty associated with this context is the value defined by node 567." The role of the third triplet is to concretize the abstract "accuracy requirement." For example, node 567 might be a composite structure that explicitly indicates the type of uncertainty (such as linear tolerance, angular tolerance) and its specific value (such as 0.01 mm).

[0090] 5. Boundary Representation (B-Rep) Entity Construction: Manifold Solid B-Rep - Closed Shell - Set of Faces (1) The set of representation items contains the entity B-Rep.

[0091] The "set of representation items" in this embodiment is carried by a set node. For example, the set node with a subject index of 556 contains multiple representation items pointed to by rdf:first, including: the representation item pointed to by index 502.

[0092] Among them, the "set of representation items" contains various geometric entities that make up this shape. Exemplarily, in the named graph, this "set of representation items" is specifically implemented by a dedicated RDF list node with an index number of 556. This node (index 556) is exactly the second list (i.e., the core geometric entity list) associated with the previous geometric representation node (index 25). List 556 is an ordered set implemented by an rdf:first / rdf:rest linked list structure. rdf:first points to the first member in the set, and rdf:rest points to the remainder, recursively. List 556 includes a representation item pointed to by index 502, and the node with index 502 is exactly a Manifold Solid B-Rep node.

[0093] (2) Manifold Solid B-Rep and Closed Shell.

[0094] The node with a subject index of 502 contains: rdf:type ->rep#ManifoldSolidBrep (object index = 616) rep#outer -> <ClosedShell node> (predicate index = 648, object index = 533) This step explicitly creates the entity object itself and defines its boundary. The node with a subject index of 502 contains two triples. The meaning of the first triple is that the node with index 502 is a boundary representation of a manifold solid. The first triple completes the "creation" of the top-level entity. It declares the existence of a solid, manufacturable physical object in this geometric representation. Semantically, this is equivalent to "placing" an entity in three-dimensional space. The second triple defines the boundary of the entity, that is, associates its closed shell. The meaning of the second triple is that the outer boundary of this manifold solid (index 502) is the closed shell defined by node 533. In this way, the abstract concept of "entity" is connected to the specific set of faces that make up its shape through the B-Rep representation method.

[0095] (3) Enclosed shell and surface assembly.

[0096] The node with subject index 533 contains: rdf:type ->rep#ClosedShell(object index = 602) And associate it with a "face set" node (object index = 593) The set node with subject index 593 is associated with multiple face nodes (e.g., 298, 119, 238, 193, etc.) through multiple rdf:first links. This set structure is used to represent the topology of all faces contained within the closed shell.

[0097] (4) Advanced face example.

[0098] Taking face node 298 as an example, it includes: rdf:type ->rep#AdvancedFace(object index = 598) And associate it with its geometric and orientation / same orientation properties.

[0099] Thus, this embodiment completes the B-Rep topological framework expression from manifold entity to closed shell and then to surface set.

[0100] 6. Examples of geometric elements: coordinate system, point and direction To support the geometric definitions of faces, edges, and curved surfaces, this embodiment also records basic geometric elements such as coordinate placement, point coordinates, and direction vectors in the content area. Taking Axis2Placement3D as an example: (1) Axis2Placement3D node.

[0101] The node with a subject index of 420 is declared as rep#Axis2Placement3D(object index = 599), and is associated with the axis, position, and reference direction through attributes. For example: rep#axis ->Direction(441) rep#location ->CartesianPoint(215) rep#refDirection ->Direction(265) This node fully defines a three-dimensional coordinate system through four triples (including a type declaration and three property associations).

[0102] The first triple declares the type, explicitly specifying that this is a 3D coordinate placement. Its predicate is `rdf:type`, and its object index is 599, pointing to the object `rep#Axis2Placement3D`. The first triple means that the node at index 420 is a "3D Axis2Placement3D". A "3D Axis2Placement3D" is an entity in the STEP standard used to define a complete local Cartesian coordinate system, containing an origin, a principal axis (Z-axis), and a reference direction (X-axis). The Y-axis is determined by the right-hand rule.

[0103] The second triple defines the principal axis direction (Z-axis), with predicate `rep#axis` and object index 441, pointing to a direction node. The second triple means that the principal axis direction of this coordinate system (index 420) is defined by direction node 441. The function of the second triple is to set the Z-axis direction of the coordinate system. This is the most important vector defining the orientation of the coordinate system. The third triple defines the origin location, with its predicate `rep#location` and object index 215, pointing to a CartesianPoint node. The meaning of the third triple is that the origin location of this coordinate system (index 420) is defined by point node 215. The function of the third triple is to set the origin of the coordinate system. All geometry defined in this coordinate system is referenced to this point.

[0104] The fourth triple defines the reference direction (X-axis), with the predicate `rep#refDirection` and the object index 265, pointing to another direction node. The meaning of the fourth triple is that the reference direction of this coordinate system (index 420) is defined by the direction node 265. The function of the fourth triple is to set the X-axis direction of the coordinate system. The two directions, `axis` (Z-axis) and `refDirection` (X-axis), must not be parallel so that the Y-axis is determined through the cross product, thus uniquely determining the pose of the entire coordinate system.

[0105] (2) Cartesian Point coordinates.

[0106] The node with subject index 215 is of type rep#CartesianPoint (object index = 600) and records the three-dimensional coordinates in the form of a "character set", for example: (55.50, 10.50, 0.00).

[0107] (3) Direction vector.

[0108] The node with subject index 441 is of type rep#Direction (object index = 606) and records the direction ratio. For example: (0.71, 0.71, 0.00).

[0109] An example of a Direction with a subject index of 265 is: (0.00, 0.00, -1.00).

[0110] Through the above nodes, the system can provide a unified local coordinate placement and parameterization reference for surfaces, curved surfaces, and edge curves.

[0111] Figure 3 This is a flowchart illustrating the implementation method of a structured semantic representation system for engineering product data provided in an embodiment of this application. Figure 3 As shown, the implementation method includes: Step 210: Construct an engineering semantic model for a specific domain based on engineering product data.

[0112] An engineering semantic model is a set of "data blueprints" or "syntax rules" defined in advance for a specific engineering domain before the naming graph is created. It can be understood as a "domain-specific data architecture" customized for a specific industry (such as aviation and automotive) or a specific task (such as 3D design and pipeline layout) on top of the SST system.

[0113] The semantic model comprises two parts: 1. Engineering entity types and their type constraints. Engineering entity types define the categories of objects within a specific domain. For example, in mechanical design, this includes: Part, Assembly, Feature, Hole, Chamfer, etc. In circuit design, it includes: Resistor, Capacitor, IC, Net, etc. Type constraints specify the characteristics and rules of these objects. For example, parent-class relationships, such as a bolt being a standard part, and a standard part being a component; disjointness, such as components and materials being different categories, and an instance not belonging to both simultaneously; and necessary conditions, such as an assembly must contain at least two components. 2. Semantic attributes and their attribute constraints. Semantic attributes include: object attributes, such as installed on, manufactured by, versioned, contained, etc.; and data attributes, such as diameter, material, weight, version number, etc. Attribute constraints specify the rules for using semantic attributes. For example, the domain, such as the relation “installed in”, must have a part as its subject; the value domain, such as the relation “installed in”, must have an assembly or another part as its object.

[0114] In one embodiment, the "engineering semantic model" can be modeled and represented using the Resource Description Framework (RDF), the RDF architecture (RDFS), and the Web Ontology Language (OWL). That is, the "engineering semantic model" is not written in natural language or a proprietary format, but rather in the international standard "modeling language" of RDF and OWL. This language provides the following standard "building blocks," which we use to construct the model, including: Use "rdfs:Resource" or "owl:Class" to represent multiple project object classes, which are used to define the abstract concept of project objects. Project objects include at least one of the following: product, component, connection point, operating condition, event, and measurement quantity.

[0115] The subclass "owl:ObjectProperty" of "rdf:Property" represents multiple project relationship properties used to describe at least one of the following: structural relationships, participation relationships, and temporal relationships between project objects. Structural relationships include "contains," such as an engine containing blades. Participation relationships include "acts on," such as a load acting on a structural component. Temporal relationships include "precedes," such as a detection event preceding a maintenance event.

[0116] The subclass "owl:DatatypeProperty" of "rdf:Property" represents multiple project data properties used to describe the identifier, name, code, and numeric parameters of a project object.

[0117] Each project relation attribute and project data attribute declares its scope using "rdfs:domain" and "rdfs:range" respectively, and constrains the project semantic attributes using "rdfs:subClassOf", "rdfs:subPropertyOf" and at least one OWL axiom, including but not limited to "owl:FunctionalProperty", "owl:InverseFunctionalProperty" or "owl:TransitiveProperty".

[0118] "Scope" is a term directly introduced from the RDFS standard and has a specific technical meaning. It specifically refers to "the valid syntactic and semantic range of an attribute (whether relational or data attribute)," and can be precisely declared using the two core attributes `rdfs:domain` and `rdfs:range`. Scope consists of a domain and a range. The domain defines the valid range of the subject, and the range defines the valid range of the object. For example, the domain of the relation "contains" is "assembly," meaning only assemblies can "contain" other things. The range of the relation "contains" is "part," meaning that what is contained must be a part. In this case, if the content region S3 has a triple, (bolt, contain, washer), the computer will infer from this rule that "the bolt must be an assembly."

[0119] `rdfs:subClassOf` and `rdfs:subPropertyOf` are used to establish an "inheritance hierarchy," enabling a hierarchical organization of concepts. `rdfs:subClassOf` defines the parent-child relationship between classes (e.g., `bolt` is a subclass of `fastener`). `rdfs:subPropertyOf` defines the parent-child relationship between properties (e.g., `tighten` is a sub-property of `connect`). At this point, the "engineering semantic model" has a well-organized, type-safe vocabulary system, but it still lacks deep constraints on the "behavior" of properties.

[0120] Advanced behavioral constraints leverage the powerful axioms of OWL to inject "deep business logic and intelligence" into the "engineering semantic model." This is key to transforming the "engineering semantic model" from a "static dictionary" into a "dynamic rule engine." Specifically, owl:FunctionalProperty means that the property can have at most one value. owl:InverseFunctionalProperty means that the value of the property can uniquely deduce the subject. That is, if two different subjects have the same property value, then they are actually the same thing. owl:TransitiveProperty means that the relation is transitive. If a has this relation with b, and b also has this relation with c, then a and c automatically have this relation.

[0121] In this embodiment, RDFS is first used to lay a solid foundation of type safety and hierarchical structure, and then OWL axioms are used to add more complex business logic rules, thereby creating an intelligent knowledge model that can not only describe data but also understand and process it. This is precisely the semantic foundation upon which the SST system relies, enabling it to support the full lifecycle management of complex engineering products.

[0122] Step 220: Parse the engineering product data into one or more intermediate named graphs according to the engineering semantic model. Each intermediate named graph has a unique identifier and consists of multiple triples. The subject, predicate, and object of the triples correspond to the engineering entity, semantic attribute, and engineering entity or literal value, respectively.

[0123] The intermediate naming graph has the logical structure of a naming graph, namely a set of triples and an IRI identifier, but it lacks the engineering encapsulation and optimization necessary for the physical format of a naming graph.

[0124] Step 231: For each intermediate named graph, count the reference relationships between the intermediate named graph and other intermediate named graphs, obtain an ordered list of identifiers of other intermediate named graphs that reference and import, and reference but not import, and generate the header region of the named graph based on the identifiers.

[0125] Specifically, first, we calculate the reference relationships between intermediate named graphs and other intermediate named graphs.

[0126] After performing step 220, multiple intermediate named diagrams may be obtained. For example: Intermediate Naming Diagram A: Describes a specific gear part.

[0127] Intermediate diagram B: Describes the material standards used for this gear.

[0128] Intermediate named graph C: describes the ontology of geometric representation (external standard, not generated in this instance).

[0129] In this case, analyze the triples of intermediate named graph A to find the IRI identifiers of all predicates and objects. If these IRI identifiers point to the IRI identifiers of intermediate named graph B or intermediate named graph C, then it means that intermediate named graph A references intermediate named graph B or intermediate named graph C.

[0130] Example: The intermediate named diagram A contains a triple (gear A, rdf:type, sso:Part). If sso: If the IRI identifier of Part belongs to intermediate naming graph C (i.e., SSO ontology), then one entry is counted, namely, intermediate naming graph A references intermediate naming graph C.

[0131] Next, determine which other intermediate named graphs referenced by the current intermediate named graph are referenced and imported, and which are referenced but not imported. This step can be determined based on a pre-defined list of IRIs that specifies which IRI identifiers are "referenced and imported" and which are "referenced but not imported".

[0132] For example, "Referencing and Importing" means merging all the data from another intermediate named figure (such as intermediate named figure B, material standard) into the current file (intermediate named figure A). This is usually because intermediate named figure B is specific to this project task and needs to be packaged and exchanged together.

[0133] "Referencing but not importing" means deciding to only reference terms from another intermediate named graph (such as intermediate named graph C, an SSO ontology) without copying its entire contents. This is usually because intermediate named graph C is a public, authoritative ontology that may be shared by a large number of documents, and maintaining a reference ensures a single source and lightweight data.

[0134] Then, the IRI identifiers of the external named graphs that determine which to import and reference are sorted according to a fixed rule (such as lexicographical order of the IRI strings), generating an ordered list. This sorting rule is key to deterministic generation, ensuring that the same set of dependencies will always generate the exact same list.

[0135] Finally, the resulting ordered list, combined with the identifier of the current intermediate named image, is encoded according to the fixed format of the header area S1 of the SST file.

[0136] For example, the header region S1 will explicitly state: The unique IRI identifier of the current named graph itself.

[0137] "Imported Graphs" is an ordered list of IRI identifiers for external named graphs that are "referenced and imported".

[0138] "Referenced Graphs" is an ordered list of external named graphs identified by IRIs that are "referenced but not imported".

[0139] Step 232: Count the number of IRI type nodes and blank type nodes belonging to the current intermediate named graph, and the total number of associations in the current named graph, and sort the nodes according to their node identifiers; sequentially enumerate the IRI type nodes belonging to the current intermediate named graph and the total number of associations of IRI type nodes in the current intermediate named graph; sequentially enumerate the blank type nodes belonging to the current intermediate named graph and the total number of associations of blank type nodes in the current intermediate named graph; count the number of IRI type nodes in other intermediate named graphs referenced by the current intermediate named graph and their reference counts, and sort the nodes according to their node identifiers; based on the ordered list of identifiers of other intermediate named graphs that reference and import, and reference but not import, sequentially enumerate the IRI type nodes belonging to the referenced intermediate named graphs and their reference counts to generate the dictionary area of ​​the named graph. The "sequential enumeration" mentioned here means assigning a unique integer index to each node according to the natural order of the nodes after sorting (0th, 1st, 2nd...) and listing its information.

[0140] Step 232 includes two phases, which process "nodes owned by the current intermediate named graph" and "nodes referenced from other intermediate named graphs".

[0141] Phase 1: Processing "Owned Assets" (Owned Nodes). This part processes the nodes that the current intermediate naming graph creates and owns.

[0142] First, count the number of IRI type nodes and blank type nodes in the current intermediate naming graph, as well as the total number of associated nodes. Specifically, count the number of IRI type nodes, the number of blank type nodes, the total number of associated nodes for each IRI type node, and the total number of associated nodes for each blank type node. The "total number of associated nodes" refers to how many triples in the current intermediate naming graph use the current node (including IRI type nodes and blank type nodes) as the subject or object. This is crucial performance optimization information, telling the encoder how much space needs to be reserved for that node.

[0143] Next, all owned nodes (first IRI type nodes, then blank type nodes) are deterministically sorted according to their identifiers (e.g., lexicographical order of IRI string or blank type node ID). Following this order, each sorted node is assigned a consecutive integer index starting from 0 or 1. Simultaneously, the node identifiers and the total number of associated records are recorded. This forms the "owned node directory".

[0144] For example: Index 0: IRI node (identifier: ...001, number of associations: 5) Index 1: IRI node (Identifier: ...002, Number of associations: 3) Index 554: Blank node (Identifier: _:xxx1, Association Count: 7) Index 555: Blank node (Identifier: _:xxx2, Association Count: 2) Phase Two: Processing “External Vocabulary” (Reference Nodes). This part handles nodes borrowed from external intermediate naming graphs.

[0145] First, count the number of IRI type nodes in all other intermediate named graphs referenced by the current intermediate named graph, as well as the number of times each IRI type node is referenced. Note that only IRI type nodes in the referenced intermediate named graphs are counted; blank type nodes are not counted (because blank type nodes cannot be referenced across intermediate named graphs).

[0146] Secondly, based on the "reference graph list" generated in step S330, each referenced intermediate named graph is processed sequentially. Within each intermediate named graph, the IRI type nodes referenced by the current intermediate named graph are sorted by identifier, and a unique index is assigned to each referenced IRI type node. Simultaneously, the number of times each IRI type node is referenced is recorded. This forms an "external reference node directory." For example: Index 596: Reference node (from: rep, identifier: rep#CartesianPoint, cited 79 times) Index 597: Reference node (from: sso, identifier: sso#Part, number of citations: 1) Index 598: Reference node (from: rdf, identifier: rdf#type, reference count: 476) The final dictionary region S2 of the named graph is obtained, which includes the two directories mentioned above. Essentially, dictionary region S2 is a "global node registry" containing: a complete list of all non-character type nodes (own + referenced); a unique, stable index for each non-character type node; and key metadata for each non-character type node (including type, identifier, association count, or reference count).

[0147] Step 233: Count the number of non-literal value type object triples and literal value type object triples belonging to the current intermediate named graph IRI type nodes and blank nodes. Based on the sorting results and index information of IRI type nodes and blank type nodes, record the triples with that node as the subject for each node in sequence. The predicate is represented by the predicate index, and the object is represented by the object index or "literal value reference", generating the content area of ​​the named graph.

[0148] The triples mentioned in step 233 can be represented as: <subject, predicate, object>; or, the number of triples of the current subject N and N <predicate index, object index or literal reference> tuples.

[0149] In step 233, two sets of data are first counted for each subject node: First, the number of non-literal object triples, i.e., how many triples exist where the object of the current subject node is another resource node (including IRI type nodes or blank type nodes). Second, the number of literal object triples, i.e., how many triples exist where the object of the current subject node is a primitive value (string, number, etc.). This is equivalent to knowing how many "dialogues" (objects are other resource nodes) and how many "side narrations" (objects are descriptive text) each subject node has. This allows for precise space allocation during encoding, avoiding dynamic expansion and improving efficiency.

[0150] Next, each node is processed sequentially according to the node index order arranged in dictionary area S2. For the node with index number N: First, write the subject header information: In content area S3, write the subject index = N, and the number of the two types of triples for it. Second, traverse and encode all triples of the subject. For example, for each triple (subject N, verb X, object Y), when encoding the verb, do not record the complete verb IRI identifier (such as http: / / ... / hasPart), but instead look up the integer index corresponding to the verb IRI identifier in dictionary area S2 and write the verb index into the triple. Object encoding needs to be handled differently: If the object Y is a resource node (such as an IRI type node or a blank type node), also look up its integer index in dictionary area S2 and write the integer index into the triple. If the object Y is a literal value (such as "10kg"), then the dictionary is not looked up (because the character is not in the dictionary area S2). Instead, the type code and the value itself are encoded to form a "literal reference" data block, which is then written into the triple.

[0151] Step 234: The generation of the current intermediate naming graph is now complete. The next subject (index N+1) will be processed according to steps 231-234.

[0152] Step 240: Generate statistics based on all named graphs. The statistics include the total number of named graphs, the named graph IRI identifier, the named graph version number, the named graph hash value, and at least one of the following: the generation time of the SST system, the generator, and the system hash value.

[0153] Step 250: The construction of the SST system is now complete.

[0154] According to the implementation method of the structured semantic representation system for engineering product data provided in this embodiment, the following steps are taken: constructing a semantic model; parsing engineering product data into a semantic graph; statistically analyzing global information of the semantic graph; statistically analyzing node information of the semantic graph; and statistically analyzing semantic data. Figure 3 The tuple information completed the construction of the SST system.

[0155] The basic principles of this application have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this application are merely examples and not limitations, and should not be considered as essential features of each embodiment of this application. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the application to the necessity of employing the aforementioned specific details for implementation.

[0156] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this application to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A structured semantic representation system for engineering product data, characterized in that, include: One or more naming diagrams, wherein the naming diagrams include a header region, a dictionary region, and a content region; The header region is used to describe the global information of the naming graph at the semantic level; the dictionary region is used to enumerate all non-character type nodes appearing in the naming graph at the logical level, and assign a unique index identifier to each node. The non-character type nodes include IRI type nodes and blank type nodes. The IRI type nodes are semantic nodes identified by Internationalized Resource Identifiers, and the blank type nodes are semantic nodes without explicit IRI identifiers; the content region is used to record the engineering product data according to triples using the index identifiers of the nodes, and to store the triples by nodes. The triples include a subject, a predicate, and an object. And statistical information, used to record global metadata.

2. The structured semantic expression system according to claim 1, characterized in that, The header region includes at least one of the following: a version field for identifying file type and logical version number; a logical structure for distinguishing different versions of the naming graph; an identifier for the current naming graph, used to uniquely identify the naming graph; an ordered list of identifiers of other naming graphs referenced and imported by the current naming graph, wherein the triples of the nodes in the imported naming graphs are visible to the current naming graph; and an ordered list of identifiers of other naming graphs referenced but not imported by the current naming graph, wherein the triples of the nodes in the unimported naming graphs are not visible to the current naming graph. The dictionary region includes at least one of the following: the number of IRI type nodes and blank nodes belonging to the current named graph; an ordered list of IRI identifiers of the IRI type nodes belonging to the current named graph and the total number of associations of each IRI type node in the current named graph; an ordered list of blank type nodes belonging to the current named graph and the total number of associations of each blank type node in the current named graph; the number of IRI type nodes belonging to the named graphs that are referenced and imported; an ordered list of IRI identifiers of the IRI type nodes belonging to the named graphs that are referenced and imported and the number of times each IRI type node is referenced by the current named graph; the number of IRI type nodes belonging to the named graphs that are referenced but not imported; and the IRI identifiers of the IRI type nodes belonging to the named graphs that are referenced but not imported and the number of times each IRI type node is referenced by the current named graph. The content area includes at least one of the following: the number of triples of non-character objects belonging to the IRI type node and the blank type node of the current naming graph, and the sequence of the triples, wherein the sequence of the triples of the non-character objects is sorted according to "predicate index – object index"; The number of triples and the sequence of the character quantifier objects belonging to the IRI type node and the blank type node of the current naming graph, wherein the sequence of the character quantifier objects is sorted according to "predicate index - literal". Preferably, the identifier of the named graph includes an IRI string. In different versions of the same named graph, the IRI string is the same, but the nodes and triples are different, and the logical version numbers are different.

3. The structured semantic expression system according to claim 2, characterized in that, The named graphs referenced and imported by the currently described named graph and the named graphs referenced by the currently described named graph but not imported have different data boundary ranges; wherein, The nodes and triples in the naming graph that are referenced and imported by the current naming graph are known to the current naming graph. All triples of the corresponding nodes in the imported naming graph can be obtained through the reference of the triples of the current naming graph to the imported naming graph. The nodes and triples of the named graph that are referenced by the current named graph but not imported are not visible to the current named graph. By referencing the triples of the unimported named graph through the current named graph, it is impossible to obtain all triples of the corresponding nodes that are not imported into the named graph.

4. The structured semantic expression system according to claim 2, characterized in that, The IRI type node belongs to at least one of the naming graphs, and only the naming graph to which it belongs allows the corresponding IRI type node to be written as the subject of the triple. The blank type node belongs to a naming graph, and the belonging naming graph is only allowed to write the triple with the blank type node as the subject, and the blank type node is only allowed to be referenced within the belonging naming graph.

5. The structured semantic expression system according to claim 2, characterized in that, The IRI type node can simultaneously serve as a class and an individual, or simultaneously serve as an attribute and an individual, in the triple.

6. The structured semantic expression system according to claim 2, characterized in that, The blank type nodes include ordinary blank nodes and non-character set nodes; in the content area, the IRI type nodes and the ordinary blank nodes are represented by sorted index values, the non-character set nodes themselves participate in the statistical sorting of the dictionary area, and the set element triples inside the non-character set nodes do not participate in the node triple sorting of the content area.

7. The structured semantic expression system according to claim 2, characterized in that, The character type nodes in the content area include ordinary character nodes and character set nodes; the ordinary character node includes a type code and a value, and the type code includes one or more of the following: text string type code, boolean type code, integer type code, floating-point number type code, date type code, time type code, and date and time type code; the character set node includes the type code, the number of the values, and multiple values, and the type code of the multiple values ​​is the same.

8. A method for implementing a structured semantic representation system for engineering product data, characterized in that, include: Based on engineering product data, an engineering semantic model for a specific domain is constructed. The engineering semantic model includes multiple engineering entities and their type constraints, and multiple semantic attributes and their attribute constraints. The engineering product data is parsed into one or more intermediate named graphs according to the engineering semantic model. Each intermediate named graph has a unique identifier and is composed of multiple triples. The subject, predicate, and object of the triples correspond to the engineering entity, the semantic attribute, and the engineering entity or literal value, respectively. For each of the intermediate named graphs, perform the following steps: The reference relationships between the intermediate named graph and other intermediate named graphs are counted to obtain an ordered list of identifiers of other intermediate named graphs that reference and import and reference but not import. Combined with the identifier of the current intermediate named graph, the header region of the named graph is generated. The system counts the number of IRI type nodes and blank type nodes belonging to the current intermediate named graph, as well as the total number of associated nodes in the current named graph, and sorts the nodes according to their node identifiers. It then sequentially enumerates the IRI type nodes belonging to the current intermediate named graph and the total number of associated nodes in the current intermediate named graph. Similarly, it sequentially enumerates the blank type nodes belonging to the current intermediate named graph and the total number of associated nodes in the current intermediate named graph. The system also counts the number of IRI type nodes and the number of references in other intermediate named graphs referenced by the current intermediate named graph, and sorts the nodes according to their node identifiers. Finally, based on the ordered list of identifiers of other intermediate named graphs that reference and import, and reference but not import, it sequentially enumerates the IRI type nodes belonging to the referenced intermediate named graphs and the number of references to generate the dictionary region of the named graph. The number of non-literal value type object triples and the number of literal value type object triples belonging to the IRI type nodes and the blank nodes in the current intermediate naming graph are counted. Based on the sorting results and index information of the IRI type nodes and the blank type nodes, the triples with the node as the subject are recorded for each node in sequence, where the predicate is represented by the predicate index and the object is represented by the object index or "literal value reference". The content area of ​​the naming graph is generated, thus completing the generation of the current intermediate naming graph. Statistical information is generated based on all the named graphs. The statistical information includes the total number of named graphs, the named graph IRI identifier, the named graph version number, the named graph hash value, and at least one of the following: the generation time of the structured semantic expression system, the generator, and the system hash value. This completes the construction of the structured semantic expression system.

9. The method according to claim 8, characterized in that, The engineering semantic model can be modeled and represented using the Resource Description Framework (RDF), the RDF architecture (RDFS), and the Web Ontology Language (OWL), including: Use "rdfs:Resource" or "owl:Class" to represent multiple project object classes, which are used to define the abstract concept of project objects. The project objects include at least one of the following: product, component, connection point, operating condition, event, and measurement quantity. The subclass "owl:ObjectProperty" of "rdf:Property" represents multiple project relationship properties, which are used to describe at least one of the structural relationships, participation relationships and temporal relationships between project objects; The subclass "owl:DatatypeProperty" of "rdf:Property" represents multiple project data properties, used to describe the identifier, name, code, and numeric parameters of a project object; Each project relation attribute and project data attribute declares its scope using "rdfs:domain" and "rdfs:range" respectively, and constrains the project semantic attributes using "rdfs:subClassOf", "rdfs:subPropertyOf" and at least one OWL axiom, including but not limited to "owl:FunctionalProperty", "owl:InverseFunctionalProperty" or "owl:TransitiveProperty".

10. The method according to claim 8, characterized in that, The triple is represented as <subject, predicate, object>; or, the number of triples of the current subject N and N <predicate index, object index or literal reference> pairs.

Images