This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
OslcCore
>
OSLCCoreQueryNextDRAFT
(25 May 2010,
DaveJohnson
)
(raw view)
---+ OSLC Core Query Syntax %RED%v.Next%ENDCOLOR% DRAFT By: The [[OslcCore][OSLC Core Workgroup]] %TOC{depth="2"}% ---+ Overview %RED%This document includes query syntax features that will be in a later version of OSLC Core Query Syntax. It is a copy of the OSLC Core Query Syntax v2 specification taken in May 25, 2010 -- one which still includes oslc.from, oslc.limit and oslc.offset, all of which were removed from the OSLC Core Query Syntax v2 specification during convergence.%ENDCOLOR% This document defines a standard set of OSLC query parameters that other OSLC domain specifications *MAY* use to query resources. ---+ Graph Patterns The OSLC standard query parameters define _graph patterns_ that are matched against the resources managed by the service, which we view as comprising an RDF graph. The pattern matching process begins at some _starting subject resource_ and matches a set of triples in the RDF graph. The starting subject resources used for pattern matching are determined by the the Query Capability. A Query Capability defines a starting subject resource, namely the base URI itself. The result of the query is the set of all triples matched by the pattern, beginning the matching processing with the starting subject resource defined by the Query Capability. The full graph pattern defined by the query parameters is composed of two kinds of graph pattern, which we refer to as _property tree patterns_ and _member list patterns_. These patterns MAY be used individually or MAY be combined in a single query, but one or the other *MUST* be present. The result of matching the full graph pattern is the union of the results of matching each kind of pattern. ---++ Property Tree Patterns A property tree pattern is defined by the presence of the =oslc.properties= query parameter. In RDF, the data model of a resource is viewed as consisting of a set of properties of the resource. The values of these properties are either literal values, such as numbers, strings, and dates, or links to other resources, which may have their own properties. Linked resources may link to other resources, and so on, to arbitrary depths. However, the scope of the query is limited to the boundaries of the service as defined by the appropriate domain specification. Properties of linked resources may be viewed as nested properties of the initial resource. The =oslc.properties= query parameter lets you match both the immediate and nested properties of a starting subject resource. ---++ Member List Patterns A member list pattern is defined by the presence of at least one of the following query parameters: =oslc.from=, =oslc.where=, =oslc.searchTerms=, =oslc.orderBy=, =oslc.offset=, =oslc.limit=, and =oslc.select=. In this pattern, the starting subject resource is viewed as a container of other resources. The members of the container are defined by one or more multi-valued membership properties of the starting subject resource. The membership properties are either given by the =oslc.from= query parameter, or default to the properties described as membership properties (via =oslc:isMemberProperty=) in the Resource Shape of the starting subject resource. The pattern matching process is defined by the following sequence of steps. Default processing is done in steps where the corresponding query parameter is not present: 1 =oslc.from= - create the member list defined by membership properties of the starting subject resource, and arrange it in some order 1 =oslc.where= - filter the member list, keeping only those member resources that satisfy the boolean test on the member resource properties 1 =oslc.searchTerm= - score each member resource using a full text search on it text-valued properties, and sort them in descending order of score 1 =oslc.orderBy= - sort the members using the sort keys, using the full text search score as the primary key 1 =oslc.offset= - discard the specified number of member resources from the start of the list 1 =oslc.limit= - discard any member resources beyond the specified number from the end of the list 1 =oslc.select= - match the immediate and nested properties of the member resources (like in =oslc.properties=) ---++ Prefixed Names In addition to the preceeding query parameters, we also define =oslc.prefix= which is used to define the prefixes for prefixed names that appear in the other query parameters. The =oslc.prefix= query parameter is not itself part of the graph pattern. Other specifications MAY use =oslc.prefix= to define prefixes for prefixed name used other query parameters. ---+ Query Parameters The query parameters defined here are intended to satsify simple query requirements, and be easy to both use and implement. More complex query requirements should be satisfied using a full query language, e.g. SQL or SPARQL. This specification formally defines the syntax of the query parameters using [[http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form][Backus-Naur Form]] (BNF) and informally illustrates their semantics with simple examples. For a more complete definition of the semantics see [[OslcSimpleQuerySemanticsV1][OSLC Simple Query Semantics V1]]. The query parameters MAY contain characters that MUST be URL encoded when transmitted in an HTTP request. The examples below show unencoded query parameters for clarity. See [[#URL_Encoding][URL Encoding]] for a further discussion of this topic. This specification defines the syntax of a set of related query parameters that MAY be used to perform queries. We have adopted a consistent naming convention for these query parameters to identify them as common across all OSLC specifications, namely all query parameter names are prefixed with the characters " =oslc.= " The following sections define these query parameters. 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. In the following sections, syntax is formally defined using a common extended form of BNF. Informal definitions and comments are delimited by /* and */. ---++ oslc.prefix This query parameter does NOT define a graph pattern. It is used by other query parameters that contain prefixed names. In the following examples, property names include a URI prefix, i.e. =dc:= or =foaf:=. An OSLC service SHOULD predefine URI prefixes for its properties. Here we assume that OSLC has predefined the Dublin Core ( =dc:=) and Friend of a Friend ( =foaf:=) prefixes. However, OSLC resources SHOULD also be open to new content, which means that new properties may not have predefined URI prefixes. We therefore need a way to define new URI prefixes in queries. The =oslc.prefix= query parameter lets you specify URI prefixes used in property names. For example, suppose the =foaf:= prefix was not predefined. The following URL illustrates the use of the =oslc.prefix= query parameter to define it: <blockquote><verbatim>http://example.com/bugs/4242?oslc.prefix=foaf=<http://xmlns.com/foaf/0.1/>&oslc.properties=foaf:lastName,...</verbatim></blockquote> ---+++ Syntax The syntax of the =oslc.prefix= query parameter is defined by the =oslc_prefix= term in the following BNF grammar: <blockquote><verbatim>oslc_prefix ::= "oslc.prefix=" prefix_defs prefix_defs ::= prefix_def ("," prefix_def)* prefix_def ::= prefix "=" uri_ref_esc prefix ::= PN_PREFIX PN_PREFIX ::= /* see "SPARQL Query Lanaguage for RDF", http://www.w3.org/TR/rdf-sparql-query/#rPN_PREFIX */ uri_ref_esc ::= /* an angle bracket-delimited URI reference in which > and \ are \-escaped. */</verbatim></blockquote> ---++ oslc.properties This query parameter defines a property tree pattern. The =oslc.properties= query parameter lets you specify the set of properties to match in a property tree pattern. Both immediate and nested properties may be specified. A nested property is a property that belongs to the resource referenced by another property. Nested properties are enclosed in brace brackets, and this nesting may be done recursively, i.e. a nested property may contain other nested properties. For example, suppose we have a bug report resource at the following URL: <blockquote><verbatim> http://example.com/bugs/4242</verbatim></blockquote> Suppose this bug resource has properties such as =dc:title=, =dc:description=, and =dc:creator=, and that =dc:creator= refers to a person resource that has properties such as =foaf:givenName= and =foaf:familyName=. Suppose you want a representation of the bug report that includes its =dc:title= and the =foaf:givenName= and =foaf:familyName= of the person refered to by its =dc:creator=. The following URL illustrates the use of the =oslc.properties= query parameter to include those properties: <blockquote><verbatim>http://example.com/bugs/4242?oslc.properties=dc:title,dc:creator{foaf:givenName,foaf:familyName} </verbatim></blockquote> ---+++++ Syntax The =oslc.properties= query parameter is defined by the =oslc_properties= term in the following BNF grammar: <blockquote><verbatim>oslc_properties ::= "oslc.properties=" properties properties ::= property ("," property)* property ::= identifier | nested_prop | wildcard identifier ::= PrefixedName PrefixedName ::= /* see "SPARQL Query Lanaguage for RDF", http://www.w3.org/TR/rdf-sparql-query/#rPrefixedName */ nested_prop ::= property "{" properties "}" wildcard ::= "*"</verbatim></blockquote> ---++ oslc.from This query parameter defines part of a member list pattern. If a member list pattern is defined but this query parameter is not present then it defaults to the set of all membership properties defined in the Resource Shape of the starting subject resource, i.e. the member list is the set of all resources that are related to the starting subject resource by one or more of the membership properties. The OSLC resource data model is defined in terms of the properties that a given type of resource may have. Some properties define attributes of resources and some define links to other related resources. Membership is an important kind of link property. Membership properties are in general multi-valued and relate a given subject resource to zero or more member resources. A resource may have more than one kind of membership property, in which case the members are all resources that are linked to the subject resource by some membership property. In general, there may be a very large number of member resources associated with a given subject resource, and it is often useful to search this set for member resources that satify some conditions. The =oslc.from= query parameter lets you specify which membership properties to use for this search. It is like the =FROM= clause in a SQL statement. The set of member resources thus defined may be further refined using boolean conditions specified in the =oslc.where= query parameter. The =oslc.from= query parameter is not restricted to membership properties. It *MAY* contain any property. For example, suppose the following URL represents the set of all change requests managed by a service: <blockquote><verbatim>http://example.com/requests</verbatim></blockquote> Suppose that this service manages two kinds of change requests, namely bugs and features, and that these are related to the base URL via the membership properties =cm:memberBug= and =cm:memberFeature=. An HTTP GET request on the base URL would return all the bugs and features. The following query would also return all the bugs and features since the base resource has only the two specified membership properties: <blockquote><verbatim>http://example.com/requests?oslc.from=cm.memberBug,cm:memberFeature </verbatim></blockquote> However, the following query would return only the bugs: <blockquote><verbatim>http://example.com/requests?oslc.from=cm:memberBug</verbatim></blockquote> ---+++++ Syntax The syntax of the =oslc.from= query parameter is defined by the =oslc_from= term in the following BNF grammar: <blockquote><verbatim>oslc_from ::= "oslc.from=" identifiers identifiers ::= identifier ("," identifier)* </verbatim></blockquote> ---++ oslc.where This query parameter defines part of a member list pattern. If a member list pattern is define but this query parameter is not present then it defaults to the boolean condition =true=, i.e. it matches all members of the member list. As discussed in the section on =oslc.from=, a resource may have an associated set of related resources defined by one or more membership properties. Service consumers often need to search for subsets of these related resources that satisfy certain conditions. The =oslc.where= query parameter lets you specify the conditions that these related resources must satisfy. It is like the =WHERE= clause of a SQL statement. For example, suppose that the following URL represents the set of all bug resources managed by a service, and that is has a single membership property, =cm:memberBug=: <blockquote><verbatim>http://example.com/bugs </verbatim></blockquote> Suppose bug reports have a =dc:identifier= property that gives their bug number, e.g. ="4242"=. The following URL filters this set and selects only those bugs that have a =dc:identifier= property whose value is ="4242"=: <blockquote><verbatim>http://example.com/bugs?oslc.where=dc:identifier="4242" </verbatim></blockquote> Note that in the preceding query, the =oslc.from= query parameter is absent so it defaults to all the membership properties, and in this case there is only one, namely =cm:memberBug=. Conditions may use the usual binary comparison operators and be combined using the boolean conjunction operator, " =and= ". For example, suppose bugs have =cm:severity= and =dc:created= properties. The following example finds high severity bugs created after April 1, 2010: <blockquote><verbatim>http://example.com/bugs?oslc.where=cm:severity="high" and dc:created>"2010-04-01" </verbatim></blockquote> The following URL illustrates the use of nested properties. It finds the set of bugs created by John Smith: <blockquote><verbatim>http://example.com/bugs?oslc.where=dc:creator{foaf:givenName="John" and foaf:familyName="Smith"}</verbatim></blockquote> ---+++ Syntax The syntax of the =oslc.where= query parameter is defined by the =oslc_where= term in the following BNF grammar: <blockquote><verbatim>oslc_where ::= "oslc.where=" compound_term compound_term ::= simple_term (space? boolean_op space? simple_term)* simple_term ::= term | scoped_term space ::= " " /* a space character */ boolean_op ::= "and" term ::= identifier_wc comparison_op value | identifier_wc space in_op space? in_val scoped_term ::= identifier_wc "{" compound_term "}" identifier_wc ::= identifier | wildcard comparison_op ::= "=" | "!=" | "<" | ">" | "<=" | ">=" in_op ::= "in" in_val ::= "[" value ("," value)* "]" value ::= uri_ref_esc | literal_value literal_value ::= boolean | decimal | string_esc (LANGTAG | ("^^" PrefixedName))? boolean ::= "true" | "false" decimal ::= /* see "XML Schema Part 2: Datatypes Second Edition", http://www.w3.org/TR/xmlschema-2/ */ string_esc ::= /* a string enclosed in double quotes, with certain characters escaped. See below. */ LANGTAG ::= /* see "SPARQL Query Lanaguage for RDF", http://www.w3.org/TR/rdf-sparql-query/#rLANGTAG */</verbatim></blockquote> ---+++++ =boolean_op= The =boolean_op= term represents a boolean operation that lets you combine simple boolean expressions to form a compound boolean expression. The only boolean operation allowed is " =and= " which represents conjunction. The boolean operator " =or= " for disjunction is not allowed in the interests of keeping the syntax simple. The effect of " =or= " in the simple case of testing a property for equality with one of several values can be achieved through the use of the " =in= " operator. For example, the following query finds bugs with severity " =high= " or " =medium= ": <blockquote><verbatim> http://example.com/bugs?oslc.where=cm:severity in ["high","medium"]</verbatim></blockquote> ---+++++ =space= The =space= term represents a single space character. A space character *MAY* be used to delimit the =binary_op= term in the =compound_term= term to improve readability. ---+++++ =comparison_op= The =comparison_op= term represents one of the following binary comparison operators: | = | test for equality | | != | test for inequality | | < | test less-than | | > | test greater-than | | <= | test less-than or equal | | >= | test greater-than or equal | ---+++++ =in_op= The =in_op= term represents the operator " =in= " which is a test for equality to any of the values in a list. The list is a comma-separated sequence of values, enclosed in square brackets, whose syntax is defined by the term =in_val=. ---+++++ =value= The =value= term represents either a URI reference ( =uri_ref_esc=) or a literal value ( =literal_value=). ---+++++ =literal_value= The =literal_value= term represents either a plain literal or a typed literal. A plain literal is a quoted string ( =string_esc=), optionally followed by a language tag ( =LANGTAG=). For example, ="Bonjour"@fr= is a plain literal with a language tag for French. If the range of a property is National Language strings and no language tag is provided in a literal value, then the service *SHOULD* infer the language tag from the HTTP request or provide a default value. A typed literal is formed by suffixing a quoted string ( =string_esc=) with "^^" followed by the prefixed name ( =PrefixedName=) of a datatype URI. 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. The terms =boolean= and =decimal= are short forms for typed literals. For example, =true= is a short form for ="true"^^xsd:boolean=, =42= is a short form for ="42"^^xsd:integer= and =3.14159= is a short form for ="3.14159"^^xsd:decimal=. ---+++++ =decimal= The =decimal= term represents a [[http://www.w3.org/TR/xmlschema-2/#decimal][decimal]] number as defined in [[http://www.w3.org/TR/xmlschema-2/][XML Schema Part 2: Datatypes Second Edition]]. As mentioned above, this term is a short form for typed literals whose datatype URIs are either =xsd:integer= or =xsd:decimal=. An integer literal value is a special case of a decimal literal value, namely one in which the decimal point is omitted from the lexical representation. For example, =42= is a valid decimal number which happens also to be a valid integer and so it is a short form for the typed literal ="42"^^xsd:integer=. ---+++++ =string_esc= The =string_esc= term represents an arbritrary sequence of characters. The sequence of characters is enclosed in double quote (") characters. Therefore, the double quote character itself *MUST* be escaped. All occurances of the double quote character in the string *MUST* be replaced by the sequence \" and all occurances of the backslash character (\) *MUST* be replaced by the sequence \\. This escaping *MUST* be undone to give the actual value of the string. ---++ oslc.searchTerms This query parameter defines part of a member list pattern. If a member list pattern is defined but this query parameter is not present then the matching process assigns an effective score of 0 to each member of the list and does *NOT* change the order of the member list Resource properties often contain text so it is useful to search for resources that contain specified terms. The =oslc.searchTerms= query parameter lets you perform a [[http://en.wikipedia.org/wiki/Full_text_search][full text search]] on a set of resources. In a full text search, each resource is matched against the list of search terms and assigned a numeric score. A high score indicates a good match. The matching resources are returned in the response, sorted by the score in descending order. Each resource that is returned in the response is annoted with a special property, =oslc:score=, that gives its match score. An OSLC domain specification that supports full text search *SHOULD* specify which resource properties are indexed so that search results are consistent across implementations. 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. 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= occuring first. 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=. The =oslc.limit= and =oslc.offset= query parameters *MAY* be used in combination with =oslc.searchTerms=. For example, the following query returns the top 10 bugs that deal with database performance: <blockquote><verbatim>http://example.com/bugs?oslc.limit=10&oslc.searchTerms="database","performance" </verbatim></blockquote> The =oslc.where= query parameter *MAY* be used with =oslc.searchTerms=. When =oslc.where= is used with =oslc.searchTerms= then the set of resources searched for matches *MUST* be restricted to only those resources that satisfy the conditions in =oslc.where=. For example, the following query returns the top 10 high severity bugs that deal with database performance: <blockquote><verbatim>http://example.com/bugs?oslc.where=cm:severity="high"&oslc.limit=10&oslc.searchTerms="database","performance" </verbatim></blockquote> ---+++++ Syntax The syntax of the =oslc.searchTerms= query parameter is defined by the =oslc_searchTerms= terms in the following BNF grammar: <blockquote><verbatim>oslc_searchTerms ::= "oslc.searchTerms=" search_terms search_terms ::= string_esc (, string_esc)* </verbatim></blockquote> ---++ oslc.orderBy This query parameter defines part of a member list pattern. If a member list pattern is define but this query parameter is not present then there are no sort keys and the matching process does *NOT* change the order of the member list. The =oslc.orderBy= query parameter lets you sort the result set. It is like the =ORDER BY= clause of a SQL statement. You can specify a list of one or more immediate or nested properties of the resources in the member list, and a sort direction for each where " =+= " means ascending order and " =-"= means descending order. The following example sorts the high severity bugs by the family and given names of the creator, with most recently created first: <blockquote><verbatim>http://example.com/bugs?oslc.orderBy=dc:creator{+foaf:familyName,+foaf:givenName},-dc:created &oslc.where=cm:severity="high"</verbatim></blockquote> The properties in the =oslc.orderBy= list are sort keys. The member list is sorted by the sort keys, in the indicated direction. The sorting order of the property values *MUST* be the same as that used for evaluating the binary comparison operators in the =oslc.where= query parameter. Each sort key *SHOULD* be the name of a single-valued property of the each resource in the result set. The sorting behavior is undefined if the sort key properties are not single-valued. ---+++++ Syntax The syntax of the =oslc.orderBy= query parameter is defined by the =oslc_orderBy= term in the following BNF grammar: <blockquote><verbatim>oslc_orderBy ::= "oslc.orderBy=" sort_terms sort_terms ::= sort_term ("," sort_term)* sort_term ::= scoped_sort_terms | ("+" | "-") identifier scoped_sort_terms ::= identifier "{" sort_terms "}" </verbatim></blockquote> ---++ oslc.offset This query parameter defined part of a member list query. If a member list query is defined but this query parameter is not present then it has an effective value of 0 and the matching process does *NOT* discard any resources from the start of the member list. The =oslc.offset= query parameter lets you specify where in result set to begin the contents of the HTTP response. An =oslc.offset= of 0 omits no members of the result set. When you use =oslc.offset= used in conjunction with =oslc.limit=, you can break up the member list into chunks that will be returned in the HTTP response. For example, the following query returns the next 100 most recent high severity bugs: <blockquote><verbatim>http://example.com/bugs?oslc.where=cm:severity="high"&oslc.orderBy=-dc:created&oslc.limit=100&oslc.offset=100</verbatim></blockquote> ---+++++ Syntax The syntax of the =oslc.offset= query parameter is defined by the =oslc_offset= term in the following BNF grammar: <blockquote><verbatim>oslc_offset ::= "oslc.offset=" nonNegativeInteger nonNegativeInteger ::= /* see "XML Schema Part 2: Datatypes Second Edition", http://www.w3.org/TR/xmlschema-2/ */</verbatim></blockquote> ---+++++ =nonNegativeInteger= The =nonNegativeInteger= term represents a [[http://www.w3.org/TR/xmlschema-2/#nonNegativeInteger][non-negative integer]] value (reference: XSD Datatypes). ---++ oslc.limit This query parameter defines part of a member list pattern. If a member list pattern is defined and this query is not present then it has an effective value of infinity and the matching process does *NOT* discard any resources from the end of the member list. In practice, a result set may contain a large number of resources, so it is useful to limit the number of resources that are returned in the HTTP response. The =oslc.limit= query parameter lets you limit the number of resources included in the response. For example, the following query returns the 100 most recently created high severity bugs: <blockquote><verbatim>http://example.com/bugs?oslc.where=cm:severity="high"&oslc.orderBy=-dc:created&oslc.limit=100</verbatim></blockquote> ---+++++ Syntax The syntax of the =oslc.limit= query parameter is defined by the =oslc_limit= term in the following BNF grammar: <blockquote><verbatim>oslc_limit ::= "oslc.limit=" positiveInteger positiveInteger ::= /* see "XML Schema Part 2: Datatypes Second Edition", http://www.w3.org/TR/xmlschema-2/ */</verbatim></blockquote> ---+++++ =positiveInteger= The =positiveInteger= term represents a [[http://www.w3.org/TR/xmlschema-2/#positiveInteger][positive integer]] value (reference: XSD Datatypes). ---++ oslc.select This query parameter defines part of a member list pattern. If a member list pattern is defined but this query parameter is not present then the matching process does *NOT* match any properties of the resources in the member list. The =oslc.select= query parameter lets you specify which immediate and nested properties of the resources in the member list to match. It is like the =SELECT= clause of a SQL statement. The syntax of the =oslc.select= query parameter is the same as that of the =oslc.properties= query parameter. However, the property names that appear in the =oslc.select= query parameter are those that belong to the resources in the member list as opposed to those that belong to the starting subject resource. For example, the following URL finds the high severity bugs and includes their creation date and the family name of the creator in the HTTP response: <blockquote><verbatim> http://example.com/bugs?oslc.select=dc:created,dc:creator{foaf:familyName}&oslc.where=cm:severity="high"</verbatim></blockquote> ---+++++ Syntax The =oslc.select= query parameter is defined by the term =oslc_select= in the following BNF grammar: <blockquote><verbatim>oslc_select ::= "oslc.select=" properties</verbatim></blockquote> The =oslc.select= query parameter uses the same syntax as the =oslc.properties= query parameter. The difference between them is in the meaning of the identifers. In =oslc.properties=, the identifiers are the names of properties of the starting subject resource. In =oslc.select=, the starting subject resource has an associated list of member resources, and the identifers are the names of properties of the resources that are contained in the member list For example, suppose that a bug resource has the membership property =cm:comment= that relates it to comment resources, and that the bug and each comment have =dc:modified= properties that give their last modification dates. The following query specifes that the response should include the modification date of bug 4242 and the modification date of each of its comments: <blockquote><verbatim> http://example.com/bugs/4242?oslc.properties=dc:modified&oslc.from=cm:comment&oslc.select=dc:modified</verbatim></blockquote> ---+++++ =wildcard= As in the case of =oslc.properties=, the =wildcard= is equivalent to the list of all properties of the member resources. The query parameter =oslc.select=*= specifies that pattern *MUST* match all the properties of the resources in the member list. ---++ URL Encoding The query parameter syntax defined in this specification permits the use of characters that *MUST* be properly encoded when transmitted in HTTP requests. For example: Not encoded: <blockquote><verbatim>?oslc.where=dc:title="test case 1" and dc:modified>="2008-12-02T18:42:30"</verbatim></blockquote>Encoded: <br /><blockquote><verbatim>?oslc.where=dc%3Atitle%3D%22test%20case%201%22%20and%20dc%3Amodified%3E%3D%222008-12-02T18%3A42%3A30%22</verbatim></blockquote> <!-- *************************************************************************************** --> ---+ Appendix A: References These are the specifications referenced by the OSLC Core Query Guidance. * BNF [[http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form][Backus-Naur Form]] * CSS - [[http://www.w3.org/TR/CSS2/][Cascading Style Sheets Level 2 Revision 2 v2.1]] * Dublin Core - [[http://dublincore.org/documents/dces/][Dublin Core Metadata Element Set, Version 1.1]] * FOAF - [[http://xmlns.com/foaf/spec][Friend of a Friend (FOAF)]] * HTML5 Posting Message- [[http://www.w3.org/TR/html5/comms.html#posting-messages][ W3C HTML5 postMessage]] * HTTP - [[http://tools.ietf.org/html/rfc2616][Hyper-text Transfer Protocol (HTTP/1.1)]] * RDF/XML Concepts - [[http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/][RDF/XML Concepts and Abstract Syntax]] * RDF/XML Syntax - [[http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/][RDF / XML Syntax Specification (Revised)]] * URI Syntax - [[http://tools.ietf.org/html/rfc3986][URI Generic Syntax]] * Window Object - [[http://www.w3.org/TR/Window/#window-embedding][Window Object 1.0 Window.name]] * XML Namespaces - [[http://www.w3.org/TR/REC-xml-names/][Namespaces in XML 1.0 (Third Edition)]] * XML Base - [[http://www.w3.org/TR/xmlbase/][XML Base (Second Edition)]] * XSD Datatypes - [[http://www.w3.org/TR/xmlschema-2][XML Schema Part 2: Datatypes Second Edition]]
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r1 - 25 May 2010 - 13:23:20 -
DaveJohnson
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback