oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: OSLC Query Property Tree and Member List Patterns
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: OASIS (oslc-core@lists.oasis-open.org) <oslc-core@lists.oasis-open.org>
- Date: Fri, 1 Dec 2017 12:32:16 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]