Re: [oslc-core] Notes from the OSLC Query subgroup Meeting

["Jim Amsden" <jamsden@us.ibm.com>]

I meant ldp:contains, sorry.


Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:      
 David Honey1/UK/Contr/IBM
To:      
 "Jim Amsden"
<jamsden@us.ibm.com>
Cc:      
 "OASIS OSLC Core
TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:      
 12/07/2017 12:51 PM
Subject:    
   Re: [oslc-core]
Notes from the OSLC Query subgroup Meeting

---

https://www.w3.org/TR/ldp/#ldpcshows use of ldp:contains rather than ldp:member. I can't recall ever using
ldp:member. 

I'll update the issue with a specific proposal based on ldp:DirectContainer
where we use both ldp:contains and rdfs:member. That would be compatible
with most existing usage and consistent with OSLC Core 3.0 LDPC usage.

David. 



From:        "Jim
Amsden" <jamsden@us.ibm.com> 
To:        "OASIS
OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
Date:        07/12/2017
17:45 
Subject:        [oslc-core]
Notes from the OSLC Query subgroup Meeting 
Sent by:        <oslc-core@lists.oasis-open.org>

---

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



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