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: [OASIS Issue Tracker] (OSLCCORE-143) OSLC query does not specify how oslc.orderBy affects the results


    [ https://issues.oasis-open.org/browse/OSLCCORE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68529#comment-68529 ] 

David Honey commented on OSLCCORE-143:
--------------------------------------

The spec is rather unclear on whether oslc.orderBy applies only to use of oslc.searchTerms or not.

In our last query working group meeting, there was a suggestion that we introduce a new property, perhaps oslc:order of type xsd:integer. This would represent the ordering of the returned members, analogous to oslc:score representing the full-text score ordering. There is a slight risk in doing so. If a domain has used oslc:order as a property, then the result of the query is that the additional oslc:order representing ordering may clash or conflict with real resource properties that might not even be an integer. However, if an implementation has done that, I think that's a defect in the implementation. It should not use a public namespace with vocabulary terms that are not defined as part of that public vocabulary, and instead use a private namespace.

The advantage of introducing oslc:order (as a MAY rather than a MUST) is that it provides clients with a sorted membership, even in cases where a paged response is not used. If that property is absent, then for the non-full-text-search use case, I think that spec needs to be clearer about inferring ordering. 

The other point relates to oslc.select and https://issues.oasis-open.org/browse/OSLCCORE-123. If we agree that proposal, that would have to exclude oslc:order. In other words, if oslc.select is omitted, return the query result container and only one statement for each member and its oslc:order value.


> OSLC query does not specify how oslc.orderBy affects the results
> ----------------------------------------------------------------
>
>                 Key: OSLCCORE-143
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-143
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>          Components: Query
>            Reporter: David Honey
>            Assignee: James Amsden
>
> OSLC Query 2.0 describes an oslc.orderBy query parameter. However, our returned results use unordered representations such as a list of statements with rdfs:member. If the query response is non-paged, then oslc.orderBy serves no purpose - a consumer cannot determine the order from the returned RDF.
> It potentially serves a purpose for a paged response (either LDPC paging, or OSLC paging), where the first page should contain a subset of the sorted members starting at the beginning and so on. The OSLC Query 2.0 does not describe this usage pattern so it's unclear whether anything more was intended.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]