Query method and system for large-scale temporal RDF graph data

Abstract

The present invention provides a query method and system for large-scale time-series RDF graph data, comprising: step S1: using a key-value storage method to uniformly load and store time-series RDF graph data in a five-tuple format into the memory of multiple machines; step S2: creating a plurality of client threads and a plurality of worker threads on each machine; step S3: the client thread receives a user's query request, parses the user's query request, and sends the parsed query request to the worker thread of the corresponding machine; step S4: the worker thread executes the query task to obtain a final query result; step S5: the worker thread returns the query result to the client thread.

Description

Technical Field

[0001] The present invention relates to the technical field of knowledge graph query, and in particular, to a query method and system for large-scale temporal RDF graph data. Background Art

[0002] A graph is a complex data structure that abstracts data objects as vertices and the relationships between data objects as edges. With the development and improvement of Web technology and the advent of the big data era, the excellent ability of graphs to express massive data and the relationships between them has made using graphs as data structures to store data a popular choice.

[0003] RDF is a graph model developed by W3C to represent data on the Web. It is one of the most widely used knowledge graph frameworks. SPARQL, which is compatible with RDF, is a query language specifically used to query data stored using the RDF model. Ordinary SPARQL statements consist of several <subject, predicate, object> triple patterns, and only data that conforms to these patterns can be added to the query result set.

[0004] Traditional RDF graphs only have entities and their relationships, but in real-world scenarios, the relationships between entities are not necessarily static, but may change over time, and a relationship that exists at one moment may not exist at another moment. Therefore, applying the concept of time series to RDF to allow time-based graph data queries has become a solution. Many real-world applications may have the need to query time series data, such as retrieving historical information on a website, and querying data on time-related resources (such as stocks and news).

[0005] At present, there are many studies on time series knowledge graphs at home and abroad, and many storage methods for time series graphs have also been proposed. The two more representative solutions are labeling and versioning. Labeling refers to adding time labels to the edges of the graph (which can be understood as the attributes of the edges), indicating at which point in time or time period the edge is valid; versioning refers to maintaining a snapshot for each state of the graph, and a new graph version is created whenever one or a group of edges change. At the same time, some storage and query systems for time series knowledge graphs have also emerged, but these systems cannot meet the following two indicators at the same time:

[0006] (1) Supports storage of billions of vertices and edges.

[0007] (2) Complete basic SPARQL queries within a few milliseconds.

[0008] How to design a storage structure and query algorithm so that these two indicators can be met at the same time is a major problem that researchers in this field need to solve urgently.

[0009] Patent document CN110909111A (application number: 201910982253.6) discloses a distributed storage and indexing method based on the data features of knowledge graph RDF, and the steps are as follows: process the stored data, count the statistical information, and mine the associated information in the data set; build an effective entity clustering index between triple classes through the data information in step 1); perform ontology division processing on each entity class based on statistical information, increase the aggregation degree of predicates contained in the entity class, and establish a predicate pointing index; connect the data set and save the connection specific class to improve the efficiency of star queries with extremely high frequency of occurrence; divide the data set into levels based on the above steps to ensure that the data is stored in descending order according to the definition level; introduce query optimization for input queries. Summary of the invention

[0010] In view of the defects in the prior art, the purpose of the present invention is to provide a query method and system for large-scale temporal RDF graph data.

[0011] A query method for large-scale temporal RDF graph data provided by the present invention includes:

[0012] Step S1: Use a key-value storage method to evenly load and store the time-series RDF graph data in the five-tuple format into the memory of multiple machines;

[0013] Step S2: Create several client threads and several worker threads on each machine;

[0014] Step S3: The client thread receives the user's query request, parses the user's query request, and sends the parsed query request to the working thread of the corresponding machine;

[0015] Step S4: the working thread executes the query task based on the parsed query request to obtain the final query result;

[0016] Step S5: The working thread returns the query result to the client thread.

[0017] Preferably, the temporal RDF graph data is persistently stored in several text files, each of which consists of data rows in the form of five-tuples, the first three elements of the five-tuple are respectively IDs obtained after converting the subject, predicate and object, the first three elements of the five-tuple represent an edge of a directed graph, the edge points from the vertex corresponding to the subject to the vertex corresponding to the object, and the predicate represents the type of the edge; the last two elements respectively represent the timestamps of the start time and end time of the validity period of the edge.

[0018] Preferably, step S1 adopts: the key is a triple consisting of the vertex ID, predicate ID and direction of the directed graph; the value is a triple list consisting of the vertex ID, two timestamps of the start time and the end time of the validity period; a key-value pair is the IDs of all vertices connected by the edge with direction dir and type pid and the vertex vid and the validity period of the adjacent relationship.

[0019] Preferably, the step S2 adopts: the number of client threads and worker threads is configured before running; and because the load of the worker threads is large, the number of worker threads is greater than a preset multiple of the number of client threads.

[0020] Preferably, the user's query request adopts: a time-series extended SPARQL query command;

[0021] The time series extended SPARQL query command includes: a time constant or two time constants are included before the WHERE keyword, and / or each query pattern after the WHERE keyword includes two time quantities, wherein the two time quantities include constants and / or variables.

[0022] Preferably, the step S3 adopts: sending the parsed query request to the working thread of the preset machine through the TCP or RDMA network.

[0023] Preferably, the query task includes a number of triple or quintuple query steps;

[0024] The step S4 adopts: each time a query step is executed, the intermediate result is updated once, and the final result is obtained when all query steps are executed;

[0025] When a query step is a triple, the matched edges only need to comply with the validity period restrictions of the time constant preceding the WHERE keyword; when a query step is a quintuple, the matched edges need to comply with the validity period restrictions of the two time quantities of the quintuple.

[0026] A query system for large-scale temporal RDF graph data provided by the present invention includes:

[0027] Module M1: Uses key-value storage to load and store the time-series RDF graph data in quintuple format evenly into the memory of multiple machines;

[0028] Module M2: Create several client threads and several worker threads on each machine;

[0029] Module M3: The client thread receives the user's query request, parses the user's query request, and sends the parsed query request to the working thread of the corresponding machine;

[0030] Module M4: The working thread executes the query task based on the parsed query request to obtain the final query result;

[0031] Module M5: The working thread returns the query results to the client thread.

[0032] Preferably, the time-series RDF graph data is persistently stored in a number of text files, each of which consists of data rows in the form of five-tuples, the first three elements of the five-tuple are respectively IDs obtained after converting the subject, the predicate and the object, the first three elements of the five-tuple represent an edge of a directed graph, the edge points from the vertex corresponding to the subject to the vertex corresponding to the object, and the predicate represents the type of the edge; the last two elements represent the timestamps of the start time and end time of the validity period of the edge respectively;

[0033] The module M1 adopts: the key is a triple consisting of the vertex ID, predicate ID and direction of the directed graph; the value is a triple list consisting of the vertex ID, two timestamps of the start time and end time of the validity period; a key-value pair is the IDs of all vertices connected by the edge with direction dir and type pid and the vertex vid and the validity period of the adjacent relationship.

[0034] Preferably, the module M2 adopts: the number of client threads and worker threads is configured before running; and because the load of the worker threads is large, the number of worker threads is more than a preset multiple of the number of client threads;

[0035] The user's query request adopts: a time-series extended SPARQL query command;

[0036] The time series extended SPARQL query command includes: a time constant or two time constants are included before the WHERE keyword, and / or each query pattern after the WHERE keyword includes two time quantities, wherein the two time quantities include constants and / or variables;

[0037] The module M3 adopts: sending the parsed query request to the working thread of the preset machine through the TCP or RDMA network;

[0038] The query task includes a number of triple or quintuple query steps;

[0039] The module M4 adopts: each time a query step is executed, the intermediate result is updated once, and the final result is obtained when all query steps are executed;

[0040] When a query step is a triple, the matched edges only need to comply with the validity period restrictions of the time constant preceding the WHERE keyword; when a query step is a quintuple, the matched edges need to comply with the validity period restrictions of the two time quantities of the quintuple.

[0041] Compared with the prior art, the present invention has the following beneficial effects:

[0042] 1. The present invention uses a key-value storage method to store graph data in a distributed manner in the memory of multiple machines. When a graph query request comes in, the machine and memory address where the required data is located can be quickly located and read, greatly improving the efficiency of the query engine. At the same time, the number of machines can be easily configured according to the amount of data, and in theory it can be expanded to any number of machines;

[0043] 2. According to demand research, the present invention designs two types of time series extension syntax based on the SPARQL language standard formulated by W3C, which supports filtering query results according to time points or time periods, and supports querying edge time data, which can meet most practical needs;

[0044] 3. While realizing the storage of time-series RDF graphs and the parsing and execution of time-series extended SPARQL statements, the present invention also supports the storage of common RDF graphs and the parsing and execution of common SPARQL statements, that is, the present invention has strong compatibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0046] Figure 1 A flowchart of the query method and system designed for large-scale temporal RDF graph data used in the present invention.

[0047] Figure 2 It is a time-series extended SPARQL query statement used in the embodiment. DETAILED DESCRIPTION

[0048] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0049] In view of the defects in the prior art, the purpose of the present invention is to provide a query method and system for large-scale temporal RDF graph data. Based on the existing native knowledge graph query system, the present invention redesigns the underlying data structure to support the storage of temporal RDF data, and designs two types of temporal extension syntax based on the SPARQL standard syntax, and modifies the parsing and execution logic of the original SPARQL syntax to support the extended SPARQL syntax, thereby realizing efficient query of large-scale temporal RDF graph data.

[0050] Example 1

[0051] According to a query method for large-scale temporal RDF graph data provided by the present invention, Figure 1-2 As shown, including:

[0052] Step S1: Use a key-value storage method to evenly load and store the time-series RDF graph data in the five-tuple format into the memory of multiple machines;

[0053] Step S2: After completing the storage of the graph data, create several client threads and several worker threads on each machine;

[0054] Step S3: The client thread receives the user's query request, parses the user's query request, converts it into a form that the working thread can understand using its built-in query language parser, and sends the parsed query request to the working thread of the corresponding machine;

[0055] Step S4: the working thread executes the query task based on the parsed query request to obtain the final query result;

[0056] Step S5: The working thread returns the query result to the client thread.

[0057] Specifically, the temporal RDF graph data is persistently stored in several text files, each of which consists of data rows in the form of five-tuples. The first three elements of the five-tuple are IDs obtained after converting the subject, predicate and object. The first three elements of the five-tuple represent an edge of a directed graph, which points from the vertex corresponding to the subject to the vertex corresponding to the object, and the predicate represents the type of the edge; the last two elements represent the timestamps of the start time and end time of the validity period of the edge.

[0058] Specifically, the step S1 adopts: the key is a triple consisting of the vertex ID (represented by vid) of the directed graph, the predicate ID (represented by pid) and the direction (the value is IN or OUT, represented by dir); the value is a list, each element of the list is a triple consisting of the vertex ID, two timestamps of the start time and the end time of the validity period; a key-value pair is the IDs of all vertices connected by the edge with the direction dir and the type pid and the vertex vid and the validity period of the adjacent relationship.

[0059] Specifically, the step S2 adopts: the number of client threads and worker threads can be configured by the operator before the system runs; and because the load of the worker threads is large, the number of worker threads is generally more than ten times the number of client threads.

[0060] Specifically, the user's query request adopts: a time-series extended SPARQL query command; one of the parameters of the time-series extended SPARQL query command is a path name of a text file, and the content of the file is a time-series extended SPARQL statement.

[0061] The time series extended SPARQL query command includes: a time constant or two time constants are included before the WHERE keyword, and / or each query pattern after the WHERE keyword includes two time quantities, wherein the two time quantities include constants and / or variables.

[0062] More specifically, the WHERE keyword can be preceded by a time constant (indicating a time point) or two time constants (indicating a time period). It requires that all edges involved in the query must be valid at that time point (when there is a time constant) or there is a valid time point in the time period (when there are two time constants).

[0063] Each query pattern after the WHERE keyword can contain two time quantities, which can be either constants or variables, representing the start time and end time of the validity period of the edge matched by the pattern. If the first time quantity is a constant, only the edges whose validity period start time is equal to the constant match the query pattern; if it is a variable, it can be regarded as a normal variable in the SPARQL statement, except that it refers to the start time of the edge validity period. The second time quantity is similar.

[0064] Specifically, the step S3 adopts: sending the parsed query request to the working thread of the preset machine through the TCP or RDMA network.

[0065] Specifically, the query task includes a number of triple or quintuple query steps;

[0066] The step S4 adopts: each time a query step is executed, the intermediate result is updated once, and the final result is obtained when all query steps are executed;

[0067] In order to achieve compatibility with ordinary SPARQL queries, when a query step is a triple, the matched edges only need to comply with the validity period restrictions of the time constant before the WHERE keyword; when there is no time constant before the WHERE keyword, it falls back to ordinary SPARQL queries; when a query step is a quintuple, it needs to comply with the validity period restrictions of the two time quantities in the quintuple.

[0068] In order to support the storage and query of large-scale time series data, its implementation is distributed, that is, multiple machines are used to store graph data, each machine is responsible for storing a part of the graph, and each machine will try to execute a SPARQL query together to speed up the query. The machines communicate with each other using TCP or RDMA network. If there is hardware that supports RDMA, RDMA should be used as much as possible for communication, which will greatly reduce the query latency. Of course, using TCP for communication can also achieve correct queries.

[0069] The present invention redesigns the underlying data structure of the knowledge graph query system to support the storage of time-series RDF data, then designs two types of time-series related extended syntax based on the SPARQL query language standard formulated by W3C, and finally modifies the parsing and execution logic of the SPARQL syntax to support the extended SPARQL syntax. The present invention can support efficient query of large-scale knowledge graph data in time-series RDF format.

[0070] A query system for large-scale temporal RDF graph data provided by the present invention includes:

[0071] Module M1: Uses key-value storage to load and store the time-series RDF graph data in quintuple format evenly into the memory of multiple machines;

[0072] Module M2: After completing the storage of graph data, create several client threads and several worker threads on each machine;

[0073] Module M3: The client thread receives the user's query request, parses the user's query request, converts it into a form that the worker thread can understand using its built-in query language parser, and sends the parsed query request to the worker thread of the corresponding machine;

[0074] Module M4: The working thread executes the query task based on the parsed query request to obtain the final query result;

[0075] Module M5: The working thread returns the query results to the client thread.

[0076] Specifically, the temporal RDF graph data is persistently stored in several text files, each of which consists of data rows in the form of five-tuples. The first three elements of the five-tuple are IDs obtained after converting the subject, predicate and object. The first three elements of the five-tuple represent an edge of a directed graph, which points from the vertex corresponding to the subject to the vertex corresponding to the object, and the predicate represents the type of the edge; the last two elements represent the timestamps of the start time and end time of the validity period of the edge.

[0077] Specifically, the module M1 adopts: the key is a triple consisting of the vertex ID (represented by vid) of the directed graph, the predicate ID (represented by pid) and the direction (the value is IN or OUT, represented by dir); the value is a list, each element of the list is a triple consisting of the vertex ID, two timestamps of the start time and the end time of the validity period; a key-value pair is the IDs of all vertices connected by the edge with direction dir and type pid and the vertex vid and the validity period of the adjacent relationship.

[0078] Specifically, the module M2 adopts: the number of client threads and working threads can be configured by the operator before the system runs; and because the load of working threads is relatively large, the number of working threads is generally more than ten times the number of client threads.

[0079] Specifically, the user's query request adopts: a time-series extended SPARQL query command; one of the parameters of the time-series extended SPARQL query command is a path name of a text file, and the content of the file is a time-series extended SPARQL statement.

[0080] The time series extended SPARQL query command includes: a time constant or two time constants are included before the WHERE keyword, and / or each query pattern after the WHERE keyword includes two time quantities, wherein the two time quantities include constants and / or variables.

[0081] More specifically, the WHERE keyword can be preceded by a time constant (indicating a time point) or two time constants (indicating a time period). It requires that all edges involved in the query must be valid at that time point (when there is a time constant) or there is a valid time point in the time period (when there are two time constants).

[0082] Each query pattern after the WHERE keyword can contain two time quantities, which can be either constants or variables, representing the start time and end time of the validity period of the edge matched by the pattern. If the first time quantity is a constant, only the edges whose validity period start time is equal to the constant match the query pattern; if it is a variable, it can be regarded as a normal variable in the SPARQL statement, except that it refers to the start time of the edge validity period. The second time quantity is similar.

[0083] Specifically, the module M3 adopts: sending the parsed query request to the working thread of the preset machine through the TCP or RDMA network.

[0084] Specifically, the query task includes a number of triple or quintuple query steps;

[0085] The module M4 adopts: each time a query step is executed, the intermediate result is updated once, and the final result is obtained when all query steps are executed;

[0086] In order to achieve compatibility with ordinary SPARQL queries, when a query step is a triple, the matched edges only need to comply with the validity period restrictions of the time constant before the WHERE keyword; when there is no time constant before the WHERE keyword, it falls back to ordinary SPARQL queries; when a query step is a quintuple, it needs to comply with the validity period restrictions of the two time quantities in the quintuple.

[0087] In order to support the storage and query of large-scale time series data, its implementation is distributed, that is, multiple machines are used to store graph data, each machine is responsible for storing a part of the graph, and each machine will try to execute a SPARQL query together to speed up the query. The machines communicate with each other using TCP or RDMA network. If there is hardware that supports RDMA, RDMA should be used as much as possible for communication, which will greatly reduce the query latency. Of course, using TCP for communication can also achieve correct queries.

[0088] The present invention redesigns the underlying data structure of the knowledge graph query system to support the storage of time-series RDF data, then designs two types of time-series related extended syntax based on the SPARQL query language standard formulated by W3C, and finally modifies the parsing and execution logic of the SPARQL syntax to support the extended SPARQL syntax. The present invention can support efficient query of large-scale knowledge graph data in time-series RDF format.

[0089] Example 2

[0090] Embodiment 2 is a preferred embodiment of Embodiment 1

[0091] The present invention provides a query method for large-scale time-series RDF graph data to complete the query of large-scale time-series RDF graph. Figure 1 The following steps are described in detail:

[0092] In step 1, the system starts and starts to load the time-series RDF graph data files in the five-tuple format from a specific directory of the file system (configured by the user in the configuration file). These files are composed of more than 100,000 five-tuple data rows. The first three elements of the five-tuple are the IDs obtained after the subject, predicate and object are converted, representing an edge of the graph; the last two elements are two timestamps representing the start time and end time of the validity period of the edge; in addition, there are two text files that store the mapping relationship between strings and IDs. Finally, the system evenly distributes and stores the data in the memory of 8 machines;

[0093] In step 2, the system creates 1 client thread and 16 worker threads on each machine;

[0094] In step 3, client thread 0 of machine 0 starts waiting for the user to enter the time-series extended SPARQL query command in the command line and press Enter. After the client thread receives the user's input (the input query statement is as follows Figure 2 ), uses its built-in parser to parse it into a form that the worker thread can understand, and then sends it to the worker thread 3 of machine 5 through the RDMA network;

[0095] Step 4: After receiving the parsed query request, the worker thread 3 of machine 5 starts to execute the query task. In this embodiment, the query task consists of two query steps. Each time a query step is executed, the intermediate result is updated until all query steps are executed and the final result is obtained;

[0096] Step 5: Worker thread 3 of machine 5 sends the query result to the client thread that specifies it to execute the query (ie, client thread 0 of machine 0) through the RDMA network, and then returns to step 3.

[0097] Those skilled in the art know that, in addition to implementing the system, device and its various modules provided by the present invention in a purely computer-readable program code, it is entirely possible to implement the same program in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded microcontrollers by logically programming the method steps. Therefore, the system, device and its various modules provided by the present invention can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing the method and structures within the hardware component.

[0098] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A query method for large-scale temporal RDF graph data, characterized in that: include: Step S1: Use a key-value storage method to evenly load and store the time-series RDF graph data in the five-tuple format into the memory of multiple machines; Step S2: Create several client threads and several worker threads on each machine; Step S3: The client thread receives the user's query request, parses the user's query request, and sends the parsed query request to the working thread of the corresponding machine; Step S4: the working thread executes the query task based on the parsed query request to obtain the final query result; Step S5: The working thread returns the query result to the client thread; The time-series RDF graph data is persistently stored in a number of text files, each of which consists of data rows in the form of five-tuples, the first three elements of which are IDs obtained by converting the subject, predicate and object, respectively. The first three elements of the five-tuple represent an edge of a directed graph, which points from the vertex corresponding to the subject to the vertex corresponding to the object, and the predicate represents the type of the edge; the last two elements represent the timestamps of the start time and end time of the validity period of the edge, respectively; The step S1 adopts: the key is a triple consisting of a vertex ID, a predicate ID and a direction of the directed graph; The value is a list of triplets consisting of the vertex ID, the start time of the validity period, and two timestamps of the end time; A key-value pair is the IDs of all vertices connected by the edge with direction dir and type pid and the vertex vid and the validity period of the adjacent relationship; The step S2 adopts: the number of client threads and worker threads is configured before running; and because the load of the worker threads is large, the number of worker threads is more than a preset multiple of the number of client threads; The user's query request adopts: a time-series extended SPARQL query command; The time series extended SPARQL query command includes: a time constant or two time constants are included before the WHERE keyword, and / or each query pattern after the WHERE keyword includes two time quantities, wherein the two time quantities include constants and / or variables; The step S3 adopts: sending the parsed query request to the working thread of the preset machine through the TCP or RDMA network; The query task includes a number of triple or quintuple query steps; The step S4 adopts: each time a query step is executed, the intermediate result is updated once, and the final result is obtained when all query steps are executed; When a query step is a triple, the matched edges only need to comply with the validity period restrictions of the time constant preceding the WHERE keyword; when a query step is a quintuple, the matched edges need to comply with the validity period restrictions of the two time quantities of the quintuple.

2. A query system for large-scale temporal RDF graph data, characterized in that: include: Module M1: Uses key-value storage to load and store the time-series RDF graph data in quintuple format evenly into the memory of multiple machines; Module M2: Create several client threads and several worker threads on each machine; Module M3: The client thread receives the user's query request, parses the user's query request, and sends the parsed query request to the working thread of the corresponding machine; Module M4: The working thread executes the query task based on the parsed query request to obtain the final query result; Module M5: The working thread returns the query results to the client thread; The time-series RDF graph data is persistently stored in a number of text files, each of which consists of data rows in the form of five-tuples, the first three elements of which are IDs obtained by converting the subject, predicate and object, respectively. The first three elements of the five-tuple represent an edge of a directed graph, which points from the vertex corresponding to the subject to the vertex corresponding to the object, and the predicate represents the type of the edge; the last two elements represent the timestamps of the start time and end time of the validity period of the edge, respectively; The module M1 adopts: the key is a triple consisting of a vertex ID, a predicate ID and a direction of a directed graph; The value is a list of triplets consisting of the vertex ID, the start time of the validity period, and two timestamps of the end time; A key-value pair is the IDs of all vertices connected by the edge with direction dir and type pid and the vertex vid and the validity period of the adjacent relationship; The module M2 adopts: the number of client threads and worker threads is configured before running; and because the load of the worker threads is large, the number of worker threads is more than a preset multiple of the number of client threads; The user's query request adopts: a time-series extended SPARQL query command; The time series extended SPARQL query command includes: a time constant or two time constants are included before the WHERE keyword, and / or each query pattern after the WHERE keyword includes two time quantities, wherein the two time quantities include constants and / or variables; The module M3 adopts: sending the parsed query request to the working thread of the preset machine through the TCP or RDMA network; The query task includes a number of triple or quintuple query steps; The module M4 adopts: each time a query step is executed, the intermediate result is updated once, and the final result is obtained when all query steps are executed; When a query step is a triple, the matched edges only need to comply with the validity period restrictions of the time constant preceding the WHERE keyword; when a query step is a quintuple, the matched edges need to comply with the validity period restrictions of the two time quantities of the quintuple.

Images