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: "Nicholas Crossley" <nick_crossley@us.ibm.com>
- To: oslc-core@lists.oasis-open.org
- Date: Fri, 5 Jan 2018 14:12:02 -0800
I'm trying to catch up with some of the
discussions on query.
- On resource shapes: "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.'"
If I'm a query builder, and I find a query capability in the service record,
and there's a type but no resource shape, how do I know what properties
I can query for? How do I find a resource for that type before I've run
a query?
- I'm confused by this recommendation,
and not sure what value it adds to the spec: "Servers SHOULD use ldp:member
for 3.0 and SHOULD use rdfs:member for 2.0 compatibility."
What if I am a server and want to be compatible with both versions of clients?
What does the above mean for clients trying to be compatible with either,
or both? What if I need to be compatible with a server that is OSLC 2.0
compliant, and uses neither ldp:member nor rdfs:member (e.g., RQM)?
- I don't understand the issue
with uri_ref_esc, this is defined in the Core spec.
Nick.
From:
"Jim Amsden"
<jamsden@us.ibm.com>
To:
oslc-core@lists.oasis-open.org
Date:
01/05/2018 12:36 PM
Subject:
Re: [oslc-core]
OSLC Query work group, preparation for next week's meeting
Sent by:
<oslc-core@lists.oasis-open.org>
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]