Summary of OSLC query workgroup meeting

We discussed the issues relating to the
semantics of comparison operators and literals.

The OSLC Query 2.0 spec is overly prescriptive,
stating:

Semantics of datatypes and
operations on these datatypes MUST work as defined in the SPARQL
Query Language (reference: SPARQL). 

This makes it impossible to satisfy
the specification using SQL on a relational database. It would require
such implementations to create RDF datasets and use SPARQL in addition
to an RDB based persistence. This is too burdensome. None of the current
RDB based Jazz applications that support OSLC query satisfy this mandatory
requirement. We need OSLC query to be reasonably simple to implement.

I'm going to write up a proposal for
review in 2 weeks time that:

Defines operators and semantics that
can be well-defined and easily implemented on most implementations. These
are the MUSTs.

Define operators and semantics whose
semantics might be implementation or even database vendor dependent. These
will be MAYs, and the semantics might be more loosely defined.

We also discussed OSLC paging and the
problem with URI lengths exceeding server limits (such as 1000 characters).
I will raise a core issue that describes the problem and a proposal to
also support POST with application/x-www-form-urlencoded body for getting
each page. Hopefully this can then be discussed in next week's core TC
meeting.

Best regards,

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