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

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

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

David Honey commented on OSLCCORE-140:
--------------------------------------

Existing implementations may expect there to be at least one OSLC property in the resource shape of the query result container marked with oslc:isMemberProperty. 

Currently the only mechanism to discover the resource shape for the members is to look for the OSLC property with oslc:isMemberProperty "true"^^xsd:boolean and then get its oslc:valueShape.

Dropping  oslc:isMemberPropertyis likely to break such implementations in both respects. We should strive for the best 2.0 compatibility that we can.

Regarding ldp:contains versus rdfs:member. https://www.w3.org/2012/ldp/wiki/ContainerHierarchy defines ldp:contains as follows:

ldp:contains a rdf:Property, owl:ObjectProperty;
  rdfs:label "contains";
  rdfs:domain ldp:Container;
  rdfs:range ldp:Resource;
  rdfs:comment """
    the ldp:contains relation relates an ldp:Container to a ldp:Resource ( ie a document of some form )
  """ .

I don't see any reference to rdfs:member. Even if there were, I think it unlikely that implementations will use OWL inferencing to realize that ldp:contains is a valid substitute for rdfs:member. For the best backwards compatibility, I think that we must continue to use rdfs:member as the default member predicate if a query capability does not provide a resource shape, and support the use of rdfs:member if such a resource shape is provided and explicity says that rdfs:member is the oslc:isMemberProperty.


> OSLC Core 3.0 Discovery does not describe the results of GET on a QueryCapability queryBase URL.
> ------------------------------------------------------------------------------------------------
>
>                 Key: OSLCCORE-140
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-140
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: Core, Query
>            Reporter: James Amsden
>            Assignee: James Amsden
>
> 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.



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