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
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: oslc-core@lists.oasis-open.org
- Date: Fri, 5 Jan 2018 15:36:08 -0500
David,
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:
Overall
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.
Terminology
Depending on whether we retain the notion
of graph and member list patterns, the terms that may need to be defined
are:
graph
graph pattern
qeury URL
self-subject
multi-subject
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
Motivation
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:- Provide a common, platform and data
source independent query capability
- Define a simple, easy to use query language
- Base the query language syntax on common
practice (e.g., National Library of Congress Contextual Query Language
(CQL): https://www.loc.gov/standards/sru/cql/)
- Provide query results as RDF resources
in response to HTTP GET requests
- Minimize the implementation burden for
OSLC servers
- Provide flexible options for implementing
select query capability features
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
919-525-6575
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: - 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).
- 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.
Best regards,
David
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]