OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [oslc-core] OSLC Query work group, preparation for next week's meeting

Thanks for the great work you are doing on OSLC Query. This is very helpful and much appreciated. I especially appreciate how you've organized, explained and put into context the issues.

I'll put most of my comments directly in the issues and only summarize here:


You have not used section elements to designate normative clauses. We have not done this consistently in other documents either, but is would be a good practice going forward. Just something to consider.


Depending on whether we retain the notion of graph and member list patterns, the terms that may need to be defined are:
graph pattern
qeury URL
full graph pattern
property tree pattern
member list pattern

I see you have intentionally removed them. So perhaps the following terms would be useful:

Query Capability


Here's some initial content:

The primary goal of OSLC is to enable loosely coupled, standards-based, and simple integration between tools that could be implemented on many different technical architectures. Although OSLC makes the assumptions that tools will typically be based on the WWW REST architecture, use browser based user interfaces, and support RDF resource representations, it makes no assumptions about how the resources are stored and managed. One important integration requirement is typically some sort of query capability that allows client applications to access selected properties of selected resources. Since HTTP does not specify any query capability, and different tools may use different DBMS implementations to manage their data sources, there is no obvious standard query language that OSLC could leverage. SPARQL may have been a reasonable choice since it is a standard query language for RDF resources, and may RDF data sources support SPARQL endpoints. However, there are many tools that are candidates for integration that use SQL, MongoDB, JanusGraph, proprietary, etc. DBMS implementations, and implementing a SPARQL endpoint on these technologies would be quite difficult.

OSLC Core defines an optional query capability to address this need. The goals of OSLC query capability are to:Basic Concepts

Should define query capability as a service provided by the service provider to access select properties of selected resources through GET on the queryBase URL.

Discovering a Query Capability

I think we should simplify this to something like: Servers SHOULD use ldp:member for 3.0 and SHOULD use rdfs:member for 2.0 compatibility. The members are defined by their QueryCapability oslc:resourceType which defines what rdf:type a member is expected to have. The oslc:resourceShape would then be optional and unnecessary. Servers MAY specify the oslc:resourceShape to describe the query result member properties in some other format, and if so MUST specify oslc:isMemberProperty in that shape.

Using the query capability

Should the table separate oslc.where and oslc.searchTerms into different tables? Do all the other clauses apply to both? If not, then they should be separate.

Query Result Containers

"found by the query" should be "matching the query".

Why are ldp:contains and rdfs:member both required? Since ldp:contains is a subproperty of rdfs:member, can't we rely on that simplification to only provide one or the other? How about ldp:contains SHOULD for OSLC query 3.0, and rdfs:member SHOULD for OSLC 2.0 compatibility?

We need an example using the QueryCapability::resourceShape to define the member.

Query Result Paging

Also needs to deal with the orderBy issue.

The query parameters do not need to be URL encoded if they are in a POST entity request body.

Re: where clause referencing properties (or any clause for that matter) can this be simplified by the absence or presence of a constraining shape? That is, if a server is closed, it has the shape and it would be an error if the referenced property isn't in the shape. If the the server is open, it wouldn't have the constraining shape? Or would it just not be an error if the reference property isn't in the shape if provided?

Regarding the issues with data types, OSLC thends to use XSD data type semantics, same as RDF.

A description of uri_ref_escape is missing in the oslc.where Syntax. Perhaps this should be uri_ref with can be tither <url> or prefix:name as defined in OSLC Core 3.0.

Motivate why space is limited to a single space (for encoding with a single %20 I assume).

10.6 oslc.properties: the first paragraph could be expanded a bit to be clearer. I think it means that the query result menbers resulting from an oslc.select could be further refined to include only those properties specified in oslc.properties. But I'm not sure. needs an example too.

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data

From:        David Honey1 <DavidHoney@uk.ibm.com>
To:        oslc-core@lists.oasis-open.org
Date:        01/04/2018 03:08 PM
Subject:        [oslc-core] OSLC Query work group, preparation for next week's meeting
Sent by:        <oslc-core@lists.oasis-open.org>

Martin is going to schedule a meeting of the OSLC Query work group for Thursday next week.
For core members interested in OSLC Query, please prepare for the meeting by:
  1. Reviewing the draft spec at https://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/oslc-query.html. I have included indented red editorial comment that helps to discuss open issues and reference the related issues in the tracker. In most cases, the draft spec reflects the proposals for the issues but has editorial comment explaining the issue(s).
  2. Review the issues below. I propose that we work through them in that order and we carry over any undecided ones over to the subsequent meeting and so on.
    Issue link Title
    Fundamental usage issues:
    https://issues.oasis-open.org/browse/OSLCCORE-102Query result container issues in Query spec
    https://issues.oasis-open.org/browse/OSLCCORE-123Query spec does not describe what properties are returned if oslc.select is not specified
    https://issues.oasis-open.org/browse/OSLCCORE-148How to specify that no member properties should be returned
    https://issues.oasis-open.org/browse/OSLCCORE-124Query spec doesn't say whether POST with application/x-www-form-urlencoded should be supported
    https://issues.oasis-open.org/browse/OSLCCORE-126What properties can be defined in the oslc.where of a query

Best regards,

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]