oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Notes from the OSLC Query subgroup Meeting
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: "OASIS OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
- Date: Thu, 7 Dec 2017 12:45:46 -0500
Here's my notes from the issues we discussed
today.
[x] OSLC query results representation
This appears underspecified in the OSLC
Core 2.0 query specification. The best source of information is in https://open-services.net/bin/view/Main/OSLCCoreSpecRDFXMLExamples#Specifying_the_shape_of_a_query.
This document appears to be loosely connected to OSLC Core 2.0 and is the
best representation of the working group’s intention.
Since ldp:member is a subproperty of
rdfs:member, we can formally define the query results MUST be provided
using rdfs:member, and MAY (also) be provided using ldp:member properties
[x] oslc.where and/or oslc.searchTerms
needs implementation options
OSLC query should treat oslc.where and
oslc.searchTerms as separate capabilities that should be implementation
options.
Proposal is to specify both clauses
MAY be supported as separate features. Use error codes if the query includes
something the server doesn’t support.
Return HTTP status 501, with something
in the response body including an oslc.Error.
oslc.where and oslc.searchTerms can
be used together. Might need another oslc.Error if the server can’t support
that.
[ ] OSLC query results are provided
in RDF, therefore oslc.orderBy has no meaning
oslc.orderBy may be a hang over from
the V1 query spec that supported limit and offset for queries. These properties
were removed from OSLC 2.0 Query probably because of its explicit support
for paging.
The Query 2.0 spec describes oslc.orderBy
as ordering the rdfs:member triples in the RDF/XML result document. But
this ordering can have no meaning in RDF, unless the client does lexical,
not RDF parsing of the query result. An RDF parser would not preserve any
ordering of the triples in the resource representation.
There are no examples of oslc.orderBy,
so it is unclear this was thought out too much. It is described in the
XML and
oslc.orderBy does have implications
for paging to order the contents between the pages - each new page would
contain different triples based on the sorting.
LDP paging uses PageSortCriteria to
allow clients to give servers some information on how the page the results.
Paging should not be coupled to oslc.orderBy. In the absence of any page
sort criteria, servers could certainly leverage any orderBy to inform paging
by default.
But OSLC query orderBy shouldn’t be
used just for paging. It would be better for clients to use PateSortCriteria
for paging, and oslc.orderBy for ordering query results as intended in
the 2.0 spec.
SPARQL does not return query results
in RDF unless a CONSTRUCT clause is used. The results are in a SPARQL result
set which is an XML or JSON file that has specific lexical syntax that
supports ordering.
OSLC Query could use something similar,
the query results could be defined by an XML file that does support lexical
ordering, but might happen to also be RDF/XML (which would not be relevant).
The implication is that the query result is intended to be treated lexically,
not as an RDF serialization format.
Alternatively oslc.orderBy could be
treated similarly to oslc.searchTerms. oslc.searchTerms calculates a score
for each member. orderBy could do something similar, attaching <member>
orderBy <int> triples that specify the resulting order. Then clients
could use RDF and in-memary capabilities to access the ordering.
[ ] OSLC core 3.0 paging is incorrect
LDP paging should be MAY, OSLC 2.0 Paging should be SHOULD.
https://issues.oasis-open.org/browse/OSLCCORE-141
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]