[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:all-tabpanel ]
David Honey updated OSLCCORE-102:
---------------------------------
Description:
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 contains, 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.
was:
The description of the query result could do with at least one example.
The current design seems to be that to interpret the container, you have to get the resource shape of the container, and then look for an oslc:property with oslc:isMemberProperty with value true to see what predicate defines the membership. It doesn't describe whether this should be declared using oslc:instanceResourceShape or oslc:resourceShape. The spec is also unclear whether the resource shape triples MUST be in a separate resource (since the use of those predicates is oslc:Resource), or whether they can be included in the query response. The former is a poor design. It requires every consumer of a query response to perform a separate GET on a referenced resource shape. The latter is better, but it is unclear whether that is valid according to OSLC Core 3.0.
The query spec does not provide a shape for the query result container, so it's not safe to assume that the container MUST reference a resource shape, or if one is provided that a maximum of only one is defined. What if two or more are defined, or two or more properies in those shapes are marked with oslc:isMemberProperty=true.
If a resource shape doesn't exist, or has no oslc:property specified with oslc:isMemberProperty=true,then it's not clear what the default is. There is a suggestion in the core vocabulary it might be rdfs:member, but no mention of this in the query spec itself. The spec ought to define the default membership predicate.
What would be better would be to use an LDPC. For backwards compatibility, if the container defined the membership predicate the same as any defined in the query result's referenced resource shape, then both means of discovering the memership predicate would work. This allows an implementation to do any one of:
1) Use an ldp:BasicContainer and define ldp:contains as the membership property in the query capability resource shape.
2) Use an ldp:DirectContainer with a ldp:hasMemberRelation that uses the same predicate as the membership property in the query capability resource shape, or if none is supplied, whatever the default predicate should be (currently not defined in the spec).
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.
Proposal:
1) Have the query specification state that an oslc:QueryCapability SHOULD declare an oslc:resourceShape. Without it, clients have no means of discovering what member resource properties are available.
2) Have the query specification state that resource shape referenced by the query capability SHOULD denote one, and only one, OSLC property with oslc:isMemberProperty "true"^^xsd:boolean and that it SHOULD reference exactly one oslc:valueShape that describes member properties. It should define the semantics and deal with https://issues.oasis-open.org/browse/OSLCCORE-145.
3) The spec should explicitly describe the query result container and provide examples. The spec should state that the query result container should be an LDPC, and that the query response contains the LDPC headers that declares that as described in the LDPC W3C spec.
4) If a query capability does not declare an oslc:resourceShape, or that referenced shape defines rdfs:member with isMemberProperty=true, then the query result container SHOULD use both rdfs:member and ldp:contains, and SHOULD use an ldp:DirectContainer with ldp:membershipPredicate rdfs:member. This maintains backwards compatibility with Query 2.0, but moves the spec forwards to be consistent with 3.0 LDPC usage.
5) If a query capability does reference a resource shape, the spec should state that an implementation MAY choose to declare ldp:contains as the isMemberProperty=true. The advantage of this is that the query result container only need use ldp:contains (saving rdfs:member triples), and the container can be an ldp:BasicContainer.
> 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 contains, 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]