learn from SQL standards (temporary tables, views, materialized views, etc.)

Why?

Much time has been spent in prior SPARQL WGs trying to reinvent wheels from zero, and thereby omitting key spokes (e.g., basic aggregates) and other significant elements (e.g., views) of those wheels -- rather than learning from and building on prior DBMS art, particularly including the 30+ year development of SQL standards and related client APIs (SQL-CLI, ODBC, JDBC, etc.).

I'm concerned that this pattern may be continuing.

TEMPORARY TABLEs, SELECT FROM SELECT with and without ALIAS, and VIEWs are closely related examples of such SQL features, now being discussed in issues #44 (named solution sets), #33 (CONSTRUCT in FROM, possibly with AS graph), #41 (named queries), #57 (parameterized queries). There are undoubtedly others.

Previous work

SQL-x is everywhere.

Virtuoso has long blended SQL features with SPARQL, both by allowing SPARQL-within-SQL ("SPASQL") and by allowing SQL Stored Procedures (which may have inline SPARQL) to be called from SPARQL through the internally predefined prefix, sql: (neighbor to bif: for Built-In Function).

Proposed solution

ALIASing a subquery is primarily achieved via keyword AS, as in CONSTRUCT ... AS temp_graph, which would be expected to auto-destruct at completion of query execution. This ALIAS is local to the query being executed, is not experienced by any other user or process.
CONSTRUCT ... INTO TEMPGRAPH temp_graph would be analogous to a SQL TEMPORARY TABLE, with content expected to persist until dropped (because REST requirements don't allow for "auto-DROP at client session end" as is typical for the SQL implementation), and temp_graph would be otherwise treated as if it were a full-fledged GRAPH. TEMPGRAPHs would be available to all users/processes, until DROPped.
CONSTRUCT ... INTO VGRAPH vgraph would be analogous to a SQL VIEW, and expected to store the CONSTRUCT and dynamically maintain the content of vgraph, such that changes to the source graph(s) would affect subsequent queries against vgraph. (This is in contrast to TEMPGRAPH which content would be persistent from initial population.)
Named SELECT result sets are a special case, as they are not RDF triple/quad data, but tabular data of arbitrary column-counts. Among other things, Virtuoso allows for use of such result sets in hybrid SPARQL-in-SQL queries, where they are treated as normal tables, and there is the further possibility of making the SQL result set available for further SPARQL work via a Linked Data View.

I would strongly suggest working to enlist SQL experts who have played a part in development of those specifications to assist in these efforts.

w3c / sparql-dev