[OSLCCORE-140] OSLC Core 3.0 Discovery does not describe the results of GET on a QueryCapability queryBase URL. - OASIS Technical Committees Issue Tracker

Details

Type: Bug
Status: Open
Priority: Major
Resolution: Unresolved
Component/s: Core, Query
Labels:
None

Proposal:

Hide

We can satsify both backwards compatibility and LDPC compatibility by having the standard say that implementations SHOULD return an LDPC that includes both ldp:contains (as required by https://www.w3.org/TR/ldp/#ldpc) and rdfs:member. One way of having both is to use an ldp:DirectContainer. For example, consider a queryBase URI of http://example.com/query. A GET with some oslc.where query expression might have returned the following in an OSLC Query 2.0 implementation (omitting namespace prefixes for brevity):

<http://example.com/query>
rdfs:member <http://example.com/resource/1>,
<http://example.com/resource/2>,
<http://example.com/resource/3>;

A response might be:

<http://example.com/query>
a ldp:DirectContainer;
ldp:membershipResource <http://example.com/query>;
ldp:hasMemberRelation rdfs:member;
ldp:contains <http://example.com/resource/1>,
<http://example.com/resource/2>,
<http://example.com/resource/3>;
rdfs:member <http://example.com/resource/1>,
<http://example.com/resource/2>,
<http://example.com/resource/3>;

Additionally, the response should contain the following header:
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
<http://www.w3.org/ns/ldp#Resource>; rel="type"

Using LDPCs also means that there is no need for a resource shape for the container itself. That means we can avoid the issues with having to mark one (and only one?) OSLC property of the container as its membership property, and not being able to provide two separate resource shapes.

Show
We can satsify both backwards compatibility and LDPC compatibility by having the standard say that implementations SHOULD return an LDPC that includes both ldp:contains (as required by https://www.w3.org/TR/ldp/#ldpc ) and rdfs:member. One way of having both is to use an ldp:DirectContainer. For example, consider a queryBase URI of http://example.com/query . A GET with some oslc.where query expression might have returned the following in an OSLC Query 2.0 implementation (omitting namespace prefixes for brevity): < http://example.com/query > rdfs:member < http://example.com/resource/1 >, < http://example.com/resource/2 >, < http://example.com/resource/3 >; A response might be: < http://example.com/query > a ldp:DirectContainer; ldp:membershipResource < http://example.com/query >; ldp:hasMemberRelation rdfs:member; ldp:contains < http://example.com/resource/1 >, < http://example.com/resource/2 >, < http://example.com/resource/3 >; rdfs:member < http://example.com/resource/1 >, < http://example.com/resource/2 >, < http://example.com/resource/3 >; Additionally, the response should contain the following header: Link: < http://www.w3.org/ns/ldp#DirectContainer >; rel="type", < http://www.w3.org/ns/ldp#Resource >; rel="type" Using LDPCs also means that there is no need for a resource shape for the container itself. That means we can avoid the issues with having to mark one (and only one?) OSLC property of the container as its membership property, and not being able to provide two separate resource shapes.

Description

OSLC Core 3.0 Discovery defines QueryCapability and oslc:queryBase: The base URI to use for queries. Queries are invoked via HTTP GET on a query URI formed by appending a key=value pair to the base URI, as described in Query Capabilities section. But there is no Query Capabilities section in the Discovery document that describes what the results of such a GET would be, or addresses the OSLC Core 2.0 use of rdfs:member vs. ldp:contains.

https://web.archive.org/web/20151031160403/http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples#Specifying_the_shape_of_a_query provides examples that use rdfs:member. However, that documernt does not appear to be referenced by the specification.

The use of lpd:contains is preferable because it is consistent with other LDPCs, some of which are, in essence, query-based containers without support for oslc.where. However, rdfs:member appears to be the current query 2.0 usage, albeit not described in the OSLC Query 2.0 specification itself.

https://web.archive.org/web/20151031160403/http://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples#Specifying_the_shape_of_a_query also states:

Specify both via Query Resource Shape. In the Service resource in the definition of the Query Capability, add an oslc:resourceShape property-value to specify a complete Resource Shape that defines the shape of the query. The shape should specify both a resource type to be used for the results, and a member property to be used to represent individual query results. This will enable people and query builders to discover query-able fields and the shape specifies the form that will be returned.

However, although a resource shape can have more than one oslc:describes, that results in the referenced oslc properties applying to all those types. One way to avoiid that is to have a queryCapability reference two resource shjapes, one for the returned members, the other for the container. However, OSLC Core 2.0 specified oslc:Zero-or-one for the oslc:resourceShape of a query capability.

OSLC Core 3.0 Discovery does not describe the results of GET on a QueryCapability queryBase URL.

Details

Description

Attachments

Activity

People

Dates