[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-102) Query result container issues in Query spec
[ https://issues.oasis-open.org/browse/OSLCCORE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68840#comment-68840 ]
David Honey edited comment on OSLCCORE-102 at 1/8/18 10:41 AM:
---------------------------------------------------------------
Re: "The Query Capability should provide a Resource Shape that describes the query base URI."
What this means is that the shape describes the resource whose subject URI is the query base URI, which is the query result container.
Re: "Regarding the value shape that describes the members, isn't that the purpose of QueryCapability::resourceType? How would this relate to the valueShape of the query capability resourceShape?"
The query capabilities oslc:resourceType property is described as: "The expected resource type URI that will be returned with this query capability. These would be the URIs found in the result resource's rdf:type property. ".
For example, a query capability for configurations for configurations might have oslc:ResourceType oslc_config:Configuration. However, that says nothing about the resource shape of those configurations and does not provide a means for a client discover such a resource shape. So oslc:resourceType is orthogonal to oslc:resourceShape. The way that a client consuming a query capability discovers the shape of the members is to get the oslc:QueryCapability oslc:resourceShape, then determine the OSLC property describing membership (oslc:isMemberProperty "true"^^xsd:boolean), and then perform a GET on that property's oslc:valueShape. It's a pity that this requires two separate GETs. If OSLC defined another predicate, say oslc:memberResourceShape, the oslc:QueryCapability could have used that so that a client could GET that shape without having to get the query base resource shape. I don't think it's worth changing that now. Existing servers that care about the shape of the members returned by the query would already be using the existing representation.
Given that we view backwards compatibility as one of the most important requirements for OSLC 3.0, at a minimum we must preserve the existing semantics:
1) If a oslc:QueryCapability does not reference a resource shape, the default membership predicate is rdfs:member.
2) If a oslc:QueryCapability references a resource shape, that shape must include at least one OSLC property with oslc:isMemberProperty="true"^^xsd:boolean.
If we want consistency with both 3.0 LDPC usage and LDPCs that are typically like query capabilities but without support for oslc.where, then we also need the query response to:
3) Be an LDPC
4) Have the required LDPC headers in the response.
That means for 3.0 usage compatible with 2.0 usage, we need to satsify all 4 requirements. My proposal does that. If a 2.0 or 3.0 server only chooses to satsify #1 and #2, then consumers should still work. The examples show that this is easy to implement, and if a server uses ldp:Contains, the query result keeps a compact and easyily understandable container representation.
was (Author: davidhoney):
Re: "The Query Capability should provide a Resource Shape that describes the query base URI."
What this means is that the shape describes the resource whose subject URI is the query base URI, which is the query result container.
Re: "Regarding the value shape that describes the members, isn't that the purpose of QueryCapability::resourceType? How would this relate to the valueShape of the query capability resourceShape?"
The query capabilities oslc:resourceType property is describes as: "The expected resource type URI that will be returned with this query capability. These would be the URIs found in the result resource's rdf:type property. ".
For example, a query capability for configurations for configurations might have oslc:ResourceType oslc_config:Configuration. However, that says nothing about the resource shape of those configurations and does not provide a means for a client discover such a resource shape. So oslc:resourceType is orthogonal to oslc:resourceShape. The way that a client consuming a query capability discovers the shape of the members is to get the oslc:QueryCapability oslc:resourceShape, then determine the OSLC property describing membership (oslc:isMemberProperty "true"^^xsd:boolean), and then perform a GET on that property's oslc:valueShape. It's a pity that this requires two separate GETs. If OSLC defined another predicate, say oslc:memberResourceShape, the oslc:QueryCapability could have used that so that a client could GET that shape without having to get the query base resource shape. I don't think it's worth changing that now. Existing servers that care about the shape of the members returned by the query would already be using the existing representation.
Given that we view backwards compatibility as one of the most important requirements for OSLC 3.0, at a minimum we must preserve the existing semantics:
1) If a oslc:QueryCapability does not reference a resource shape, the default membership predicate is rdfs:member.
2) If a oslc:QueryCapability references a resource shape, that shape must include at least one OSLC property with oslc:isMemberProperty="true"^^xsd:boolean.
If we want consistency with both 3.0 LDPC usage and LDPCs that are typically like query capabilities but without support for oslc.where, then we also need the query response to:
3) Be an LDPC
4) Have the required LDPC headers in the response.
That means for 3.0 usage compatible with 2.0 usage, we need to satsify all 4 requirements. My proposal does that. If a 2.0 or 3.0 server only chooses to satsify #1 and #2, then consumers should still work. The examples show that this is easy to implement, and if a server uses ldp:Contains, the query result keeps a compact and easyily understandable container representation.
> Query result container issues in Query spec
> -------------------------------------------
>
> Key: OSLCCORE-102
> URL: https://issues.oasis-open.org/browse/OSLCCORE-102
> Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
> Issue Type: Task
> Components: Query
> Reporter: David Honey
> Assignee: James Amsden
>
> The description of the query result could do with at least one example.
> The current specification does not describe any container, but related guidance documents do. The current position is that an oslc:QueryCapability may reference Zero-or-one oslc:resourceShape. If specified, that resource shape is the resource shape of the query result container, and it MUST denote at least one OSLC property as being a member property using the oslc:isMemberProperty. That predicate is defined in OSLC Core 3.0 Resource shapes, but was not described in the query spec. If a query capability does not reference a resource shape, then the current [undocumented] behaviour is to use rdfs:member.
> Some implementations also provide a resource shape for the query result members by providing an oslc:valueShape for the OSLC property that has oslc:isMemberProperty set to true. However, the semantics of that referenced shape is ambiguous - see https://issues.oasis-open.org/browse/OSLCCORE-145.
> In many cases, both OSLC Core and OSLC Configuration Management provide other containers, and these are specified as LDPCs. These LDPCs have some similarity with a query base except that they do not support oslc.where or oslc.searcdhTerms. We should align the query result container with LDPCs. This has the advantage that it's backwards compatible with OSLC 2.0 query, but has the usual semantics of LDPCs widely used in OSLC Core 3.0.
--
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]