Use of oslc.properties and oslc.select in OSLC Queries, reply from Arthur

FYI...

----- Forwarded by David
Honey1/UK/Contr/IBM on 03/09/2018 10:34 -----

From:      
 Arthur Ryman <*******@******>

To:      
 

Date:      
 02/09/2018 13:33

Subject:    
   Re: Use of oslc.properties
and oslc.select in OSLC Queries

David,

Nice to hear from you. Glad that OSLC is still thriving.

Your understanding is partially correct. oslc.properties is used for

queries that return a subgraph rooted at the node specified by the

target URL. oslc.select applies to resource container URLs. The

meaning of those two query parameters is explained in [1] and [2]. I

wrote those specs in an attempt to describe how IBM products had

implemented their own query APIs.

The decision to drop oslc.properties should be based on how people

have implemented the spec. If no one has implemented support for

oslc.properties, then go ahead and drop it, otherwise you'll get

negative feedback when you publish a new version.

[1] https://open-services.net/bin/view/Main/OslcSimpleQuerySemanticsV1

[2] https://open-services.net/bin/view/Main/OslcSimpleQuerySparqlV1

-- Arthur

On Fri, Aug 31, 2018 at 1:05 PM David Honey1 <>
wrote:

>

> Hi Arthur,

>

> I'm working on a draft OSLC Query 3.0 specification and the OSLC Core
technical committee asked that I email you about the use of oslc.properties
and oslc.select in OSLC Queries to get some clarification since you were
a key contributor to the Query 2.0 specification.

>

> It is the TC's understanding that:

>

> oslc.properties (selective properties) was originally intended to
support clients GETting a subset of a resource's properties.

> When used with a GET on a query base URI, it acts using the query
base URI as its starting subject, whereas oslc.select acts using each query
result member's subject.

>

>

> Is our understanding is correct?

>

> If so, the use of oslc.properties on an OSLC Query seems to add little
value. A query result container (whose subject is the query base URI) has
very few properties. Its content is mostly a reference to the member resources
found by the query, and omitting those references does not seem to satisfy
any use case we can think of. The TC is considering removing oslc.properties
from the OSLC Query 3.0 specification because it just seems to add unnecessary
confusion. However, if there is a real use case for oslc.properties in
an OSLC Query, we would like to use that as an example to explain the difference
between oslc.properties and oslc.select. Can you think of such a use case?

>

> Thanks,

> David

>

>

>

> 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

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