[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-145) Resource shape for use with oslc.query and oslc.select
[ 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?
The technique used by some implementations, such as RTC Work Item query capabilities, is to have the container reference a resource shape.
That resource shape defines the 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
If only one oslc:valueShape can be used, one technique would be to add a new resource shape boolean property, for example, oslc: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).
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
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.
> 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?
> The technique used by some implementations, such as RTC Work Item query capabilities, is to have the container reference a resource shape.
> That resource shape defines the 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
> If only one oslc:valueShape can be used, one technique would be to add a new resource shape boolean property, for example, oslc: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).
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]