oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] RE: OSLC Query Capability question
- From: David Honey1 <DavidHoney@uk.ibm.com>
- To: Jad El-Khoury <jad@kth.se>
- Date: Fri, 31 Aug 2018 15:21:22 +0100
Hi Jad,
The Query 2.0 specification was very
vague about oslc.orderBy.
In a paged response, a server should return a first page that contains
the first member as ordered by the specified sort keys, and the last page
should contain the last member as ordered by the specified sort keys. However,
the specification wasn't even explicit about that. Within a page, or within
a complete non-paged response, the specification did not explicitly say
what a server should do or how a client might determine the ordering of
members.
There was some thought that some implementations
might rely upon the lexical ordering of RDF/XML, but we did not find any
evidence of IBM applications doing this. In general, the TC agreed that
relying on the lexical ordering of RDF serialization formats was not a
good mechanism for a client to determine the order of members in a query
response. Lexical ordering in Turtle is undefined, but is the preferred
serialization format for use in OSLC specifications. If an OSLC 2.0 client
wants to determine ordering of members within a query response, then the
only safe mechanism is for the client to parse the member's properties
and perform its own sorting. For a non-paged response, this makes oslc.orderBy
completely useless. The TC felt this was unsatisfactory and should be addressed
in Query 3.0.
For the draft Query 3.0 specification,
we propose improving this by introducing a new oslc:order
pseudo-property (a bit like oslc:score)
whose integer value represented the order position of a member. A client
may thus determine the ordering within a query response, paged or non-paged,
in all supported RDF serialization forms. Of course, OSLC 2.0 clients won't
know how to process that.
Best regards,
David
From:
Jad El-Khoury <jad@kth.se>
To:
"oslc-core@lists.oasis-open.org"
<oslc-core@lists.oasis-open.org>
Cc:
Andrii Berezovskyi
<andriib@kth.se>, Axel Reichwein <axel.reichwein@koneksys.com>,
Ricardo Herrera <ricardo.herrera@koneksys.com>
Date:
31/08/2018 12:14
Subject:
[oslc-core]
RE: OSLC Query Capability question
Sent by:
<oslc-core@lists.oasis-open.org>
Dear Core TC,
I am not sure if the Core TC is meant to
deal with public questions, but we got a question from Ricardo (Koneksys)
about the OSLC Query and I thought maybe someone from this TC can help?
Ricardo cannot directly send emails to
this mailing list. But I found the question interesting myself.
Anyone that can clarify how the reponse
for a query request with âoslc.orderâ meant to work?
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management,
Mechatronics Division
BrinellvÃgen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70
773 93 45
jad@kth.se,
https://www.kth.se/profile/jad
From: Ricardo Herrera [mailto:ricardo.herrera@koneksys.com]
Sent: Friday, 31 August 2018 01:57
To: oslc-core@lists.oasis-open.org
Cc: Andrii Berezovskyi <andriib@kth.se>; Jad El-Khoury <jad@kth.se>;
Axel Reichwein <axel.reichwein@koneksys.com>
Subject: OSLC Query Capability question
Good day, I'm implementing an OSLC adapter where I need
to use the oslc.orderBy clause in a QueryCapability, I couldn't find in
2.0 spec (neither in 3.0) the standard way to keep the order of the members
in the Query Resource representation.
This is what I could find in 2.0:
"The OSLC client then uses HTTP GET to request a Query
Resource representation of the query results. The Query Resource representation
will contain property values about the query and a collection of resources
that match the query criteria."
This description does not mention any shape for the Query
Resource representation and less for a given important order of the members.
So far I've seen examples that uses this shape:
=====================================================
<http://example.com/services/requirements/query>
a oslc:ResponseInfo;
oslc:totalCount
3;
rdfs:member
<http://example.com/services/requirements/6802>
,
<http://example.com/services/requirements/2875>
,
<http://example.com/services/requirements/103>
.
<http://example.com/services/requirements/6802>
a oslc_rm:Requirement
;
dcterms:title
"..." .
dcterms:description
"..." ;
<http://example.com/services/requirements/2875>
a oslc_rm:Requirement
;
...
<http://example.com/services/requirements/103>
a oslc_rm:Requirement
;
...
=====================================================
However rdfs:member predicate is not enough to establish
an order. OSLC 3.0 focus on the use of LDP containers but I think does
not meet this requirement also. I was thinking the solution should be something
like:
=====================================================
<http://example.com/services/requirements/query>
a oslc:ResponseInfo;
oslc:totalCount
3;
oslc:members
[ a rdf:Seq ; rdf:li <http://example.com/services/requirements/6802>
; rdf:li <http://example.com/services/requirements/2875>;
rdf:li <http://example.com/services/requirements/103>
]
=====================================================
but I wanted to know whether you have something different
to address this scenario that I missed.
Thanks in advance.
Regards,
Ricardo.
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]