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] RE: OSLC Query Capability question


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]