Based on the discussions in the ‘teaser’ posts, I have thought a bit more about the way we can formally define the notion of ‘projection’ in AQL. The confusing thing is that in ‘normal’ DB theory, the FROM part of a query specifies the logical database (tables or virtual join) on which the row-filtering (WHERE clause) should operate, before the SELECT columns are selected to generate the result. You can’t mention columns in the SELECT that don’t exist in the FROM part. Here, the WHERE clause does the instance matching.
In AQL we are using the FROM part to some of the instance matching, in order to generate a kind of reduced database - this is doing some of what would be in a WHERE clause in SQL. However, if we consider that the ‘table structure’ of the reduced result is still what is defined by either a) the RM or b) the potential slot structure of the mentioned archetypes, then we can see this ‘database’ as something over which the projection specified in the SELECT still makes sense. It would also be the basis on which it returned Void values for some items.
If we go that way (which I think is @Seref’s idea) then the remaining part is to understand:
- how to determine the number of rows that should come back, and
- whether SELECT items that are contained in other SELECT items should be refs or copies.
thoughts?