Currently, the only resource shape available for a query user is the maximum of one specified by oslc:resourceShape in the oslc:queryCapability. That resource shape relates to the properties of the query base URI and provides the properties that may be referenced in any oslc.properties query parameter value. It does not describe the properties of members.
How does a client discover what member properties may be used with oslc.select or with oslc.where?
The technique used by some implementations, such as RTC Work Item query capabilities, is to have the query capability reference a resource shape for the container. That resource shape defines the OSLC property that denotes membership of the property, and that property specifies an oslc:valueShape for the members. However, it's not clear whether that referenced shape:
1) Only specifies queryable properties.
2) Specifies member properties that can be specified in oslc.select, but only some of which might be queryable.
This seems like a major omission from the OSLC Core 2.0 and 3.0.
We need a means for a client to discover which member properties:
1) Can be queried and specified in oslc.where
2) Can be returned in the result and specified in oslc.select
Although a resource shape can specify more than one oslc:valueShape, there does not appear to be any means of distinguishing different purposes or semantics for multiple value shapes. It would be better to have a single value shape to avoid unncvessary duplication, but add a new resource shape boolean property for OSLC Core 3.0 resource shapes that indicated if that OSLC property was queryable. A single value shape could then satisfy both #1 and #2.
Ideally, #1 would include nested query properties. This could be done using oslc:valueShape for an OSLC property representing a queryable related resource. For example, if dcterms:creator is a queryable property, the OSLC property for it in a query resource shape could specify oslc:valueShape referencing a query resource shape for users. In this way, a client could discover nested properties that can be specified in oslc.where.
Similarly, for #2, a resource shape for oslc.select could use oslc:valueShape for an OSLC property representing an associated resource, and that shape would provide the nested selectable properties for that associated resource.
I think the Query spec needs to describe how clients discover properties for #1 and #2, referencing the Query capability section in Core, and provide example(s).