[OASIS Issue Tracker] (OSLCCORE-102) Query result container issues in Query spec

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

    [ https://issues.oasis-open.org/browse/OSLCCORE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67884#comment-67884 ] 

Jad El-khoury commented on OSLCCORE-102:
----------------------------------------

An example is certainly needed here. I can't comment on the suggestions above, since it is not clear (to me at least) how query relates to its shape(s). I hope I can highlight some confusions that an example can clarify.

But first a clarification to a statement above:
>It doesn't describe whether this should be declared using oslc:instanceResourceShape 
>or oslc:resourceShape.

The Query Capability shape defined under https://open-services.net/bin/view/Main/OslcCoreSpecification#Conceptual_Model_SP explicitly states oslc:resourceShape, with description "The Query Capability SHOULD provide a Resource Shape that describes the query base URI". So, I assume oslc:isMemberProperty is to be defined for one of the properties in that shape.

But I get the impression the query shape is meant to be used to describe both itself, as well as its resulting member resources. Here's why.

1.
as stated under https://open-services.net/bin/view/Main/OslcCoreSpecification#Query_Capabilities, "A Query Capability ... MAY provide Resource Shapes that describe the property values that may be expected in the resources that are queryable via the query capability."  

This imples that the shape is to describe the member resources - and not the query base.

2. How can I client identify the valid set of member resource properties that can be included in the oslc.where clause? Should they not be defined the oslc:resourceShape?

I realised that I might have diverged from the originally proposed issue, but I hope the need for a few examples here is further highlighted here.


> 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 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. 



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