[oslc-core] Last call for comments Re: Proposed resolution for issue #42 - unknown selective and search properties in OSLC queries

[Arthur Ryman]

Mike,

The semantics of the query language is that selected properties are not 
required to exist. This translates to SPARQL OPTIONAL. The WHERE clause 
will match no results if the properties are absent. This is not actually 
an error. So an empty result is perfectly valid. I don't think it make 
sense to return an error: "The provider can return an OSLC Error resource 
to indicate to the consumer that the query will not succeed as 
constructed."

There should be some more explicit way to determine what properties are 
present, e.g. via a ResourceShape.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, Chief Architect, Reporting &
Portfolio and Strategy Management
IBM Software, Rational 

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile) 





From:   Michael F Fiedler <fiedler at us.ibm.com>
To:     oslc-core at open-services.net, 
Date:   04/09/2013 06:32 PM
Subject:        [oslc-core] Last call for comments Re: Proposed resolution 
for issue #42 - unknown selective and search properties in OSLC queries
Sent by:        "Oslc-Core" <oslc-core-bounces at open-services.net>



My plan for knocking off issues has not gone quite as planned - which is 
fine since the workgroup has had more pressing business.

I am re-circulating my proposed solution to issue 42 (relevant links 
below) for final comment.  If we have time in tomorrow's workgroup meeting 
we can discuss any comments, objections, etc.


Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170

Michael F Fiedler---02/25/2013 09:27:00 AM---Michael F Fiedler/Durham/IBM

Michael F Fiedler/Durham/IBM  
02/25/2013 09:27 AM



To

oslc-core at open-services.net, 

cc


Subject

Proposed resolution for issue #42 - unknown selective and search 
properties in OSLC queries




As agreed to in the last Core meeting, we will try to close an issue or 
two each meeting.   This week, I am providing a summary and proposed 
resolution for Issue #42.  Please comment on-list and we can discuss on 
Wed.


Core issue #42 [1] deals with service provider behavior when a consumer 
requests selective properties or attempts to filter/search using 
properties not known to the provider.   The e-mail thread describes three 
variations on the issue:

1. Client requests selective properties (oslc.select/oslc.properties) 
defined as optional in the spec and which are not supported by the 
provider [1]
2. Client requests selective properties not defined in the specification 
[1]
3. Client tries to filter or search (oslc.where) using a property not 
supported by the provider [2]

The issue was discussed on-list, in early 2012 workgroup meetings and it 
appears some side meetings were held as well to investigate the behavior 
of existing implementations.   Based on the discussions, the following 
informative text is proposed for the Core specification.   The workgroup 
should discuss the content and whether it goes in V2 or is deferred to V3.

To be inserted as a new sub-heading under "Unknown Properties and Content" 
[3]
=============
(This section is informative.)

A consumer can send an OSLC query with a request for selective properties 
(oslc.properties, oslc.select) which the provider does not recognize. 
These properties could be unsupported properties from an OSLC 
specification or properties not included in an OSLC specification.  When 
unsupported selective properties are present in an OSLC query, the 
provider is encouraged to ignore these properties and form the query 
response as if they were not present.  Other recognized selective 
properties on the query should be honored.

A consumer can send an OSLC query with a a request to search on specific 
properties (oslc.where) which the provider does not recognize.  These 
properties could be unsupported properties from an OSLC specification or 
properties not included in an OSLC specification.  When unsupported search 
properties are present, the provider is encouraged to follow the semantics 
of SPARQL WHERE as it relates to OSLC query (see: 
http://open-services.net/bin/view/Main/OslcSimpleQuerySparqlV1#Example_2_Searching_for_Resource
).  If the property is not present in the RDF graph of resources queried, 
no resources will match the query.   The provider can return an OSLC Error 
resource to indicate to the consumer that the query will not succeed as 
constructed.


[1] - 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-March/001257.html

[2] - 
http://open-services.net/pipermail/oslc-core_open-services.net/2012-April/001287.html

[3] - 
http://open-services.net/bin/view/Main/OslcCoreSpecification#Unknown_properties_and_content



Regards,
Mike

Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net