Re: [oslc-core] OSLC Query Property Tree and Member List Patterns

["Nicholas Crossley" <nick_crossley@us.ibm.com>]

Not all providers use rdfs:member (or ldp:member)
for query results. For example, RQM uses http://open-services.net/ns/qm#testCasefor test case queries, and corresponding predicates for queries for other
artifact types.

Nick.



From:      
 "Jim Amsden"
<jamsden@us.ibm.com>
To:      
 OASIS (oslc-core@lists.oasis-open.org)
<oslc-core@lists.oasis-open.org>
Date:      
 12/01/2017 09:32 AM
Subject:    
   [oslc-core]
OSLC Query Property Tree and Member List Patterns
Sent by:    
   <oslc-core@lists.oasis-open.org>

---

Summarizing some notes and TC discussion
on OSLC Query, and opening up the discussion for proposals to address the
issue of query results format. I believe the discussion below addresses
the issue David raised on the last TC call where there was no way to distinguish
between the triples that match the query and triples that are added by
the oslc.select query parameter. But it raises some new issues on OSLC
Core 3.0 that did not adequately specify the OSLC Query Capability in OSLC
Discovery.

References:

OSLC 2.0 Query Specification: https://open-services.net/bin/view/Main/OSLCCoreSpecQuery
OSLC V1 Query Semantics: https://open-services.net/bin/view/Main/OslcSimpleQuerySemanticsV1
OSLC Simple Query SPARQL Smeantics V1: https://open-services.net/bin/view/Main/OslcSimpleQuerySparqlV1
OSLC 2.0 Query Tutorial: http://open-services.net/resources/tutorials/oslc-primer/query-mechanisms/(provides
query results examples)

Historical Notes:

IBM Rational Team Concert OSLC 1.0 had a primitive query capability that
was also used as a model for OSLC Query Capability

OSLC Simple Query and OSLC 2.0 Query Capability refer to the same thing.
The primary goal of OSLC Query Capability was to make it easier for adopters
to implement the simple query mechanism, and also achieve some level of
interoperability.

OSLC Query syntax was derived from the National Library of Congress Contextual
Query Language (CQL): https://www.loc.gov/standards/sru/cql/


Differences between OSLC Simple Query V1 and OSLC Core 2.0 Query Capability:

1. oslc.from is removed - OSLC 2.0 Discovery oslcService oslc:queryCapability
oslc:QueryCapability oslc:queryBase is assumed to represent a collection
of resources whose members are defined by its oslc:resourceShape. 
2. oslc.offset removed - OSLC 2.0 pagination used instead
3. oslc.limit removed  - OSLC 2.0 pagination used instead

Property Tree Pattern is typically applied to individual resources with
a GET request and is used to support the OSLC 2.0 "Selective Properties"
capability. It is not clear if this needs to be considered part of OSLC
query anymore.

Member List Pattern is typically applied to the oslc:queryBase of the Service’s
QueryCapability which represents a collection of resources defined by its
oslc:resourceShape(s).

Although the OSLC query refers to the Full Graph Pattern as the union of
the triples returned by the property tree and member list patterns, I don't
recall seeing any example where oslc.properties is used with oslc.where
in the same query.

OSLC Simple Query V1 refers to members of the container are defined by
one or more multi-valued membership properties of the starting subject
resource. The membership properties are given by the the properties described
as membership properties (via oslc:isMemberProperty) in the Resource Shape
of the starting subject resource, and selected using the oslc.from query
parameter.

However, in OSLC Core 2.0 Query Capability, the starting subject resources
used for pattern matching are determined through OSLC Discovery. A Query
Capability defines a starting subject resource, namely the base URI itself
(see oslc:queryBase). The result of the query is the set of all (<queryBase>
rdfs:member <matchingResource>) triples matched by the pattern, beginning
the matching processing with the starting subject resource defined by the
Query Capability.

For the Member List Pattern, the oslc:queryBase URL is viewed as a container
of other resources. 

Default processing occurs in steps where the corresponding query parameter
is not present has some reasonable default:
1. oslc.where - filter the rdfs:member list, keeping only those member
resources that satisfy the boolean test on the member resource properties
2. oslc.searchTerms - score each member resource using a full text search
on its text-valued properties, and sort them in descending order of score
3. oslc.orderBy - sort the members using the sort keys, using the full
text search score as the primary key
4. oslc.select - match the immediate and nested properties of the member
resources (like in oslc.properties, but applied to each of the members,
not the baseURI resource)

Query results:

OSLC Simple Query V1 referred to the query results being a set of matching
triples - the triples returned from the processing steps above.

OSLC Core 2.0 Query Capability does not seem to define the results in any
particular resource representation and doesn't provide and results for
the example queries in the specification.

However, http://open-services.net/resources/tutorials/oslc-primer/query-mechanisms/indicates
that the ServiceProvider queryBase URI is interpreted as a container, and
a GET on that URL returns rdfs:member elements as <queryBase> rdfs:member
<memberResource>  triples. Applying member list pattern OSLC
queries to such a queryBase URL does return the matching resources in rdfs:member
triples. 

If the OSLC query includes an oslc.select, this can introduce additional
triples to the query result that result from navigating the nested properties
of resources related to members that match the query. That is, the oslc.select
is applied to each matching member. In this case there is no problem distinguishing
the matching members from these additional triples because the matching
members are given in the rdfs:member elements.

For example, consider this query:

http://example.com/proj1?oslc.where=dcterms:creator=<http:example.com/users/3>&oslc.select=dcterms:title

The results might be:

@prefix dcterms: <http://purl.org/dc/terms/>
.
@prefix foaf: <http://xmlns.com/foaf/0.1/>
.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
.

<http://example.com/proj1>
    rdfs:member
        <http://example.com/proj1/4244>
,
        <http://example.com/proj1/4247>
.

<http://example.com/proj1/4244>
    dcterms:title "Bug 4244" .

<http://example.com/proj1/4247>
    dcterms:title "Bug 4247" .

New Issues:

Issue: 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:member.
Since ldp:member is a subproperty of rdfs:member, OSLC Core 2.0 Query Capability's
use of rdfs:member to list the members of a GET on a queryBase URL is compatible
with the queryBase being an LDPC. However, this needs to be documented
in the OSLC Core 3.0 Discovery specification and referenced in the updated
OSLC Core 3.0 Query Capability specification.

See issue OSLCCORE-140

Issue: We need to consider separating Selective Properties (oslc.properties)
and OSLC Query Capability (oslc.where, oslc.select, etc.) on a queryBase
resource.  Or we need to formally specify what it would mean to use
them both in the same request URI query string.

Issue: OSLC Core 2.0 Query Capability does not need to be restricted
to just the discovered oslc:queryBase container. It could also be applicable
to any multi-valued property, possibly regardless of whether it is constrained
to be an oslc:isMemberProperty property or not. Although the removal of
oslc.from in OSLC Query 2.0 seems to imply that OSLC query perhaps only
applies to discovered oslc:queryBase URIs with their associated resource
shapes. We need to decide what it means to apply OSLC query string to any
URL if we choose to support that.







Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575