[OASIS Issue Tracker] (OSLCCORE-145) Resource shape for use with oslc.query and oslc.select

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/OSLCCORE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Honey updated OSLCCORE-145:
---------------------------------

    Description: 
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. This does not seem very useful.

How does a client discover what member properties may be used with oslc.select or with oslc.where?

A service might not define any creation factory for that type of resource. Even if it does, not all the properties that can be specified at creation might be queryable. Some properties might not be supported at creation but be available as readonly.

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

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.

  was:
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. This does not seem very useful.

How does a client discover what member properties may be used with oslc.select or with oslc.where?

A service might not define any creation factory for that type of resource. Even if it does, not all the properties that can be specified at creation might be queryable. Some properties might not be supported at creation but be available as readonly.

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



> Resource shape for use with oslc.query and oslc.select
> ------------------------------------------------------
>
>                 Key: OSLCCORE-145
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-145
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: Query
>            Reporter: David Honey
>            Assignee: James Amsden
>
> 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. This does not seem very useful.
> How does a client discover what member properties may be used with oslc.select or with oslc.where?
> A service might not define any creation factory for that type of resource. Even if it does, not all the properties that can be specified at creation might be queryable. Some properties might not be supported at creation but be available as readonly.
> 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
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)