| QUERY-1 |
A query capability SHOULD specify exactly one oslc:resourceShape and that shape SHOULD describe the
query result container.
|
| QUERY-2 |
The resource shape referenced by oslc:resourceShape MUST declare at least one OSLC property with
oslc:isMemberProperty "true"^^xsd:boolean, and that property SHOULD specify exactly one
oslc:valueShape
referencing a resource shape that describes the referenced members of that container.
|
| QUERY-3 |
The resource shape referenced by oslc:valueShape in the query result container's resource shape
SHOULD declare the properties that can be used in oslc.select and optionally
oslc.where.
|
| QUERY-4 |
Where a member resource supports nested properties, for example, the foaf:name of a
dcterms:creator, the member resource shape MAY provide a oslc:valueShape for that
property.
|
| QUERY-5 |
Servers MUST support a GET on the oslc:queryBase of a query capability. |
| QUERY-6 |
Servers SHOULD support POST on the oslc:queryBase of a query capability to avoid clients having to
construct URIs that are too long for a GET.
|
| QUERY-7 |
A GET or POST request on the oslc:queryBase of a query capability MAY use
zero, one or more of the OSLC query parameters listed in Table 1.
|
| QUERY-8 |
For a successful operation, the response status code MUST be 200 OK for a non-paged result, or for
an OSLC paged result.
|
| QUERY-9 |
For a successful operation, the response body MUST be RDF that includes a query result container whose subject
is the oslc:queryBase.
|
| QUERY-10 |
If a GET or POST on a oslc:queryBase neither specifies oslc.where nor
oslc.searchTerms, the server MUST return a query response describing all the resources that have
one or more of the RDF types specified by the oslc:resourceType of the
oslc:QueryCapability that defines the oslc:queryBase.
|
| QUERY-11 |
The response body for a successful GET or POST on a oslc:queryBase MUST
include a query result container whose subject is the oslc:queryBase URI.
|
| QUERY-12 |
The container SHOULD be a Linked Data Platform Container (LDPC) referencing each member resource found by
the query. The response SHOULD include a Link header that describes the type of LDPC returned. This
provides compatibility with OSLC Core 3.0 and its wider use of LDPCs. [LDP]
|
| QUERY-13 |
If the query capability that declared the base URI does not declare a oslc:resourceShape then the
container MUST include an rdfs:member reference to each of the result members.
|
| QUERY-14 |
If the query capability that declared the base URI declares a oslc:resourceShape and that resource
shape defines a container property with oslc:isMemberProperty "true"^^xsd:boolean then the query
result container MUST include the specified member property referencing each of query result member.
|
| QUERY-15 |
A query capability MAY support Resource paging as described in [OSLC-Core-30-Part1].
|
| QUERY-16 |
A paged response MAY occur if paging is supported and the request includes a oslc.paging=true query
parameter, or automatically if the server determines that the total query result set exceeds some implementation
dependent threshold.
|
| QUERY-17 |
The query parameters MAY contain characters that MUST be URL encoded when transmitted in an HTTP request.
|
| QUERY-18 |
An OSLC domain specification MAY use some or all of these query parameters, and SHOULD use these rather than
defining new query parameters that have the same or very similar meanings. Each of these query parameters
SHOULD appear at most once in a query. The behavior is undefined when a query parameter appears more than
once.
|
| QUERY-19 |
Implementations MAY support the use of the wildcard in property names and nested properties.
|
| QUERY-20 |
A space character MAY be used to delimit the binary_op term in the
compound_term term to improve readability.
|
| QUERY-21 |
If the range of a property includes literal values from more than one datatype, then a typed literal MUST
be used in order to avoid ambiguity. Otherwise a plain literal MAY be used and the service SHOULD infer
the datatype.
|
| QUERY-22 |
The string_esc term represents an arbitrary sequence of characters. The sequence of
characters is enclosed in double quote (") characters. Therefore, the double quote character itself MUST
be escaped. More generally, all occurrences of the double quote character in the string MUST be replaced
by the sequence \" and all occurrences of the backslash character \ in the actual value MUST be replaced
by the sequence \\ in the escaped value. This escaping process MUST be reversed to give the actual value
of the string.
|
| QUERY-23 |
The scoped_term represents the ability to query on nested properties. Servers MAY choose not
to support such nested property queries, and SHOULD respond with
501 Not Implemented
if they are not supported.
|
| QUERY-24 |
An [XMLLiteral], such as "abc"^^rdf:XMLLiteral, MUST be supported. A server MAY treat
the literal in the same way as a plain string literal with the data type removed such as
"abc".
A plain string literal, such as "abc" MUST be supported. A server MAY treat the literal
in the same way as an XML literal string such as "abc"^^rdf:XMLLiteral.
An xsd:string typed literal [xsdDatatypes], such as "abc"^^xsd:string, MUST be
supported. A server MAY treat the literal in the same way as an XML literal string such as
"abc"^^rdf:XMLLiteral.
Servers MAY validate the string for compliance to an [XMLLiteral].
|
| QUERY-26 |
The values true and false MUST be supported.
The xsd:boolean [xsdDatatypes] values "true"^^xsd:boolean and
"false"^^xsd:boolean MUST be supported and MUST have the same meaning as
true and false respectively.
The values "true" and "false" MAY be supported, and if so, MUST have the
same meaning as true and false respectively.
A language tagged literal, such as "true"@en MAY be supported and MAY have implementation
and/or locale dependent behavior.
|
| QUERY-27 |
The operators =, !=, and in MUST be supported.
Other operators MAY be supported and MAY have implementation-dependent semantics.
|
| QUERY-28 |
Values that are conformant with an xsd:dateTime [xsdDatatypes] [xsdDateTime], such as
"2018-01-30T12:25:00"^^xsd:dateTime, MUST be supported.
Plain string literals whose string value conforms to an xsd:dateTime, such as
"2018-01-30T12:25:00", MAY be supported, and if so, MUST have the same meaning as an
xsd:dateTime typed literal such as "2018-01-30T12:25:00"^^xsd:dateTime”.
|
| QUERY-29 |
The operators =, !=, <, >,
<=, >=, and in MUST be supported, and MUST have the
semantics of a
xsd:dateTime
comparison.
|
| QUERY-30 |
Decimal literals with or without a decimal point, such as 42 and 42.0, MUST
be supported if the server supports xsd:decimal property values.
An xsd:decimal typed literal [xsdDatatypes], such as "42"^^xsd:decimal or
"42.0"^^xsd:decimal, MUST be supported if the server supports
xsd:decimal property values.
A plain string literal with a decimal value, such as "42" or "42.0", MAY be
supported, and if so, MUST have the same meaning as the xsd:decimal typed literal.
|
| QUERY-31 |
The operators =, !=, <, >,
<=, >=, and in MUST be supported if the server supports
xsd:decimal property values, and if so, MUST have the semantics of a
xsd:decimal comparison.
|
| QUERY-32 |
Decimal literals with or without a decimal point, such as 42 and 42.0, MUST
be supported if the server supports xsd:double property values.
An xsd:double typed literal [xsdDatatypes], such as "42"^^xsd:double or
"42.0"^^xsd:double, MUST be supported if the server supports
xsd:double property values.
A plain string literal with a double value, such as "42" or "42.0", MAY be
supported, and if so, MUST have the same meaning as the xsd:double typed literal.
|
| QUERY-33 |
The operators =, !=, <, >,
<=, >=, and in MUST be supported if the server supports
xsd:double property values, and if so, MUST have the semantics of an
xsd:double comparison.
|
| QUERY-34 |
Decimal literals with or without a decimal point, such as 42 and 42.0, MUST
be supported if the server supports xsd:float property values.
An xsd:float typed literal [xsdDatatypes], such as "42"^^xsd:float or
"42.0"^^xsd:float, MUST be supported if the server supports
xsd:float property values.
A plain string literal with a float value, such as "42" or "42.0", MAY be
supported, and if so, MUST have the same meaning as the xsd:float typed literal.
|
| QUERY-35 |
The operators =, !=, <, >,
<=, >=, and in MUST be supported if the server supports
xsd:float property values, and if so, MUST have the semantics of an
xsd:float comparison.
|
| QUERY-36 |
Decimal literals without a decimal point, such as 42, MUST be supported.
An xsd:integer typed literal [xsdDatatypes], such as "42"^^xsd:integer,
MUST be supported.
An xsd:decimal typed literal [xsdDatatypes] without a decimal point, such as
"42"^^xsd:decimal, MAY be supported, and if so, MUST have the same meaning as an
xsd:integer typed literal.
A plain string literal with a decimal value, such as "42", or a language tag string with
a decimal value, such as "42"@en, MAY be supported, and if so, MUST have the same meaning
as a decimal value.
|
| QUERY-37 |
The operators =, !=, <, >,
<=, >=, and in MUST be supported and MUST have the
semantics of an xsd:integer comparison.
|
| QUERY-38 |
A plain string literal, such as "abc" MUST be supported.
An xsd:string typed literal [xsdDatatypes], such as "abc"^^xsd:string, MUST be
supported. A server MUST treat the literal in the same way as an plain string literal string such as
"abc".
An [XMLLiteral], such as "abc"^^rdf:XMLLiteral, MUST be supported. A server MAY treat
the literal in the same way as a plain literal string such as "abc".
A string with a language tag, such as "abc"@en, MAY be supported. The string MAY be
treated as a plain string literal, or it MAY be treated as a language specific string that only
matches a string with an identical value and language tag.
|
| QUERY-39 |
The operators =, !=, and in MUST be supported.
Servers MUST implement, and SHOULD document, one of the following semantics:
- case sensitive string compare
- case insensitive string compare
-
case insensitive string pattern match where
% means match zero or more characters, and
_ means match any single character.
A server MAY choose which of the above to apply based on whether the string contains a %
or
_ character, and/or the property being compared. A server SHOULD document if this is the
case.
Other operators MAY be supported and MAY have implementation-dependent semantics. A server MAY report
such usage as unsupported.
|
| QUERY-40 |
A uri_ref_esc such as <http://example.org> MUST be supported.
A PrefixedName such as oslc:Zero-or-many, MAY be supported. If supported, the value MUST
be treated as equivalent to its corresponding uri_ref_esc.
|
| QUERY-41 |
The operators =, !=, and in MUST be supported. A server MUST
implement this as a case-sensitive URI string comparison.
Other operators MAY be supported and MAY have implementation-dependent semantics, or a server MAY
report such usage as unsupported.
|
| QUERY-43 |
An OSLC domain specification that supports full-text search SHOULD specify which resource properties may be
supported in a full-text search.
|
| QUERY-44 |
When oslc.searchTerms is used in the request, each matching resource (hit) in the response MAY
contain an oslc:score property. Note that oslc:score is not purely a property of the
resource since it also depends on the search terms. It is therefore a pseudo-property whose validity is
limited to the HTTP response, and for a paged response, its subsequent pages.
|
| QUERY-45 |
The oslc:score property MUST be a non-negative number and SHOULD be in the range from 0-100.
Results MUST be ordered with the entry with the largest oslc:score occurring first.
|
| QUERY-46 |
The oslc.orderBy query parameter MAY be used with oslc.searchTerms. When
oslc.orderBy is used with oslc.searchTerms the result MUST be first sorted in
descending order by the oslc:score pseudo-property, and then by the other sort keys specified in
oslc.orderBy. This behavior is like prepending the list of sort keys specified in
oslc.orderBy with the key -oslc:score. However, the pseudo-property
oslc:score MUST NOT appear explicitly in oslc.orderBy.
|
| QUERY-47 |
The oslc.where query parameter MAY be used with oslc.searchTerms. When
oslc.where is used with oslc.searchTerms and is supported, then the set of resources
searched for matches MUST be restricted to only those resources that satisfy the conditions in
oslc.where.
|
| QUERY-48 |
A paged response SHOULD reflect the ordering of members specified by oslc.orderBy. The first
page SHOULD contain the members that are ordered first, and any subsequent pages SHOULD contain members
ordered after the members in the previous page.
|
| QUERY-49 |
The query result MAY include a oslc:order property whose positive integer value reflects the
ordering of the the members specified by oslc.orderBy.
|
| QUERY-50 |
For a paged response, the smallest oslc:order value in a page MUST be greater than largest
oslc:order value in any previous page.
|
| QUERY-51 |
If oslc.orderBy is not specified, the ordering of the results is undefined and MAY be
implementation-dependent.
|
| QUERY-52 |
If oslc.select is not specified, the response MAY include some or none of the properties of
members in the query result container.
|
| QUERY-53 |
Servers SHOULD avoid returning a large number of properties of members by default. |
| QUERY-54 |
If a server chooses to include a multi-valued property by default, and the query response is not paged, it
MUST include all the values of that property.
|
| QUERY-55 |
If oslc.where specifies a property that has a defined namespace prefix but the property is not
known, an implementation MAY either:
-
Respond with a
400 Bad Request as described in Error Handling.
- Execute the query and return a normal query response.
|
| QUERY-56 |
Servers SHOULD accept the value rdf:nil. If specified as the only property, servers SHOULD omit
all properties of the member resources. If oslc.select specifies rdf:nil and other
properties, servers MAY choose to respond with 400 Bad Request, or ignore the
rdf:nil, or have other implementation dependent behavior.
|
| QUERY-57 |
Implementations MAY support the use of the wildcard for immediate and/or nested properties of member
resources. Servers SHOULD document any restriction on the use of the wildcard.
|
| QUERY-58 |
A server MAY include additional member properties in the response to those specified in the
oslc.select query parameter |
| QUERY-59 |
Servers MAY support a oslc.paging query parameter. Implementations MAY choose to ignore the
parameter.
|
| QUERY-60 |
Servers that support paging of query results SHOULD use a paged response when
oslc.paging=true
is specified.
|
| QUERY-61 |
Servers MAY also provide a paged response if the oslc.paging parameter is not specified and the
query result includes a large number of members or a large number of RDF statements.
|
| QUERY-62 |
Servers MAY support a oslc.pageSize query parameter. Implementations MAY choose to ignore the
parameter, or MAY use it as a hint for how a response should be paged and use page boundaries that do not
exactly match the specified page size.
|
| QUERY-63 |
If a GET or POST of a oslc:queryBase cannot be executed, the response
MUST include a response body whose RDF contains at least one oslc:Error describing the cause of the
error.
|
| QUERY-64 |
If the error is due to use of oslc.where, oslc.searchTerms, oslc.orderBy,
or oslc.select and that query parameter is not supported, the response status SHOULD be
501 Not Implemented. Implementations that do not support a specific query parameter need not parse
or validate its value.
|
| QUERY-65 |
If the error is due to a supported but malformed query parameter value, such as one that does not match the
supported syntax, then the response status code SHOULD be 400 Bad Request.
|
| QUERY-66 |
If the error is due to a supported oslc.where, oslc.select, or
oslc.orderBy parameter, and its value references a namespace that is not defined by default or with
oslc.prefix, the response status code SHOULD be 400 Bad Request.
|
| QUERY-67 |
If oslc.where specifies a property that has a defined namespace prefix, and the property is defined
in the resource shape for the query capability with oslc:queryable of
"false"^^xsd:boolean, the server MUST Respond with a 400 Bad Request.
|
| QUERY-68 |
If a query uses a supported query parameter, and the parameter value is syntactically valid, but the
implementation does not support a specific use of such a query parameter, the response status SHOULD be
501 Not Implemented. For example, this might apply if a specific use of the wildcard in
oslc.select is not supported.
|
| QUERY-69 |
If the query is valid, but the server failed to execute the request in some unexpected way, then the response
status SHOULD be 500 Internal Server Error.
|
