@Ciaran ,

If you mean the new SQL/PGQ language added to SQL and part of the Oracle database 23c, you can already use it right now because it is "just" SQL. You can create a dataset and use it (because SQL/PGQ results are like a table with columns and rows as they come from SQL).

If you expect to run "interactive" graph queries from a workbook, this would be a full overlap with Graph Studio and the Oracle Graph Web Application which both already works with SQL/PGQ and PGQL against Graph Server or the database (PGQL and SQL/PGQ).

I do see your point.

The Graph Web Application is purely java and doesn't really use anything of Weblogic (that's also why it is more often deployed on Tomcat or it is self-hosted on an embedded Tomcat when you run it directly from the Graph Server installation): no need to pay a Weblogic license.

I believe the graph team did work on the APEX support for their products, so APEX is meant to more easily be able to use graphs for queries and some form of analysis.

The issue I can imagine with DV having to support graphs is that it will "break" the separation between physical sources and analytical platform: DV does use the BI Server in the background, which is source agnostic. Adding something in DV that would be "only" available with an Oracle database 23c (SQL/PGQ) would be a big change of paradigm with some analytics capabilities only available if you do use that exact source.

Even the current graph limited support is done bypassing the limit of the source: any source can be used, because the data is loaded on an Oracle database in the backend and the methods of the OPG_APIS PL/SQL package are executed there before to send back the result as a "table" (with columns and rows).

And that's why you can already use the 23c SQL/PGQ, because it is just SQL and therefore can be used to create dataset directly. And any visualization in DV is designed to work with tabular results: columns and rows.

There is also another aspect to keep in mind: SQL/PGQ is not fully a property graph solution. It is called "operational property graph" because the purpose is to execute known, pre-defined, graph pattern matching queries on live relational data. This is very different compared to Graph Server and PGQL where you can execute algorithms, modify the graph on the fly and do exploration to try to find something useful, but everything is done on a snapshot (static) of data that doesn't reflect the source data in real time.

With this in mind, a DV dataset based on a SQL/PGQ statement would already fully fit in the idea of the operational property graph that is SQL/PGQ.

Because SQL/PGQ is part of the standard SQL, there should be other databases that are going to support it. Maybe at that time some special kind of visualization that will work only with a connection to a database with SQL/PGQ support will be added to enable some kind of exploration of the graph. Currently I didn't try but the network visualization would also already work with a SQL/PGQ dataset.

In the meantime I believe (this is my understanding based on what product managers of graph and oracle analytics said here and there) the idea is more that Graph Studio or Graph Web application (and also notebooks) are used for exploration, discover (ideally connected to Graph Server to get the full power of graph analysis), while DV datasets can be used to display and integrate with other sources the result of a SQL/PGQ query.