Copyright ©2005 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The RDF Query Language SPARQL expresses queries over RDF graphs. This document defines a protocol for communicating those queries to an RDF data service. This protocol is being developed by the W3C RDF Data Access Working Group (DAWG), part of the Semantic Web Activity as described in the activity statement .
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a first Public Working Draft of the SPARQL protocol produced by the RDF Data Access Working Group, (part of the Semantic Web Activity) for review by W3C Members and other interested parties. It reflects the best effort of the editors to reflect implementation experience and incorporate input from various members of the WG, but is not yet endorsed by the WG as a whole. Please send comments to the public public-rdf-dawg-comments@w3.org, a mailing list with a public archive. The procotol defined by this document is intended to provide access to RDF query services. The working group would appreciate feedback and suggestions from developers of RDF applications.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced under the 5 February 2004 W3C Patent Policy. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing [and excluding] a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
Per section 4 of the W3C Patent Policy, Working Group participants have 150 days from the title page date of this document to exclude essential claims from the W3C RF licensing requirements with respect to this document series. Exclusions are with respect to the exclusion reference document, defined by the W3C Patent Policy to be the latest version of a document in this series that is published no later than 90 days after the title page date of this document.
The Semantic Web is based in part on RDF, which is a flexible and extensible way to represent, and reason about, information describing World Wide Web resources. The promise of the Semantic Web rests in part on the promise of ad hoc, arbitrary data aggregation and integration. RDF is crucial to this promise, as is a uniform means of interacting with remote or local RDF storage services. At present there are many different methods of accessing remote RDF storage servers; and even in those cases where the basic access protocol is based on an existing standard, there is no consensus about protocol features, extensibility points, service descriptions and advertisements, data-passing conventions, etc.
This document describes SPARQL, a protocol for accessing RDF data and for conveying RDF queries from query clients to query processors. The SPARQL Protocol has been designed for compatability with the SPARQL Query Language for RDF but is designed to convey queries from other RDF query languages as well. In what follows the SPARQL protocol is described in two ways: first, as an abstract protocol independent of any concrete realization, implementation, or binding to another protocol; second, as a concrete protocol implementation based on HTTP. Other concrete realizations of the abstract protocol described herein are encouraged.
When in this document the words must, must not, should, should not, may and recommended appear as emphasized text, they must be interpreted as described in RFC 2119.
The SPARQL abstract protocol is constituted by its types, operations, and responses.
The abstract protocol uses the following types, which fall into three categories: W3C XML Schema types, which are relevant to all abstract protocol operations and borrowed from W3C XML Schema Datatypes; protocol types, which are relevant to abstract protocol operations; and query types, which are relevant to query operations.
The string
datatype represents character strings in XML. The value space of
string is the set of finite-length sequences of characters (as defined
in [XML 1.0 (Second Edition)]) that match the Char production from
[XML 1.0 (Second Edition)]. A character is an atomic unit of
communication; it is not further specified except to note that every
character has a corresponding Universal Character Set code point,
which is an integer.
The type boolean
boolean
has the value space required to support the mathematical concept of
binary-valued logic: {true, false}.
anyURI
represents a Uniform Resource Identifier Reference (URI). An anyURI
value can be absolute or relative, and may have an optional fragment
identifier (i.e., it may be a URI Reference). This type should be used
to specify the intention that the value fulfills the role of a URI as
defined by RFC 2396, as amended by RFC 2732.
positiveInteger
is derived from nonNegativeInteger by setting the value of
minInclusive to be 1. This results in the standard mathematical
concept of the positive integer numbers. The value space of
positiveInteger is the infinite set {1,2,...}.
An OperationProcessor
, which identifies a SPARQL
processing service, is an anyURI
to which
a OperationContext
is conveyed.
An OperationTarget
is
an RDFGraph
or an anyURI
which identifies a
RDF graph resource and against which a protocol operation is
executed.
A OperationTargetSet
is a set of one or more
distinct OperationTarget
.
An OperationPoint
is any anyURI
,
identifying either an OperationProcessor
or an OperationTarget
, to which
an RDF query, or other protocol operation, is conveyed.
RDFGraph
is a canonically serialized
RDF graph, that
is, instanceOf(http://www.w3.org/1999/02/22-rdf-syntax-ns#). RDF/XML is the canonical way to
serialize RDFGraph
. There are other, semantically
equivalent ways to serialize RDF graphs, and concrete protocols
may allow for their use in addition to RDF/XML.
Some abstract protocol operations require a succinct, RDF query
language indpendent way to represent the selection of all RDF triples
from an RDF graph. The SPARQL abstract protocol uses the
asterisk, * (Unicode 002A), as the lexical representation
of AllGraphTriples
.
The SPARQL protocol is intended to convey RDF queries from many
different RDF query languages. The type defined
here, RDFGraphQuery
, is a string
which represents a legal
query from any RDF query language. No grammar is given in this
specification for RDFGraphQuery
.
Some RDF query languages support the notion of distinct query
results: duplicate query results are winnowed before being returned to
the client. DistinctQueryResults
is a key-value
pair, distinct: boolean
, where the value is a
boolean: if true
, distinct results must
be returned to the client; if false
, distinct
results may not be returned to the client.
Some RDF query languages support the notion of limiting the number
of query results; LimitQueryResults
is a key-value
pair, limit: positiveInteger
, where
the value is a positiveInteger
, which is the maximum
number of query results that are to be returned to the client via the
protocol.
A QueryBundle
is a
set—{RDFGraphQuery
| AllGraphTriples
| anyURI
[,
DistinctQueryResults
, LimitQueryResults
]}—comprised
of either an RDFGraphQuery
or
an AllGraphTriples
or an anyURI
(which, when
dereferenced, returns an RDFGraphQuery
); an
optional DistinctQueryResults
; an
optional LimitQueryResults
.
Some RDF query languages, including SPARQL Query Language for RDF,
allow for yes-no or boolean queries—called in this
document BooleanQueryResult
—the results of which is
a boolean value.
instanceOf(http://www.w3.org/2001/sw/DataAccess/rf1/)CHANGEME
A well-formed instance of SPARQL Variable Binding Results XML Format, an XML vocabulary for exchanging the variable results format provided by the SPARQL Query Language for RDF.
A QueryResult
is either
an RDFGraph
, BooleanQueryResult
,
or VariableBindingSet
.
The SPARQL Abstract Protocol defines three kinds of
response: success
, fault
,
and informational
. Success responses indicate that the
protocol operation was successfully executed; fault responses indicate
that the protocol operation was not successfully executed;
informational responses either provide additional information about an
abstract protocol operation or describe specific conditions relevant
to particular abstract protocol operations.
In response to abstract protocol operations, conforming implementations must return a response type indicating the status of the operation. Additionally, conforming implementations should return an RDF graph describing the response for machine processing. For some kinds of protocol operations, conforming implementations may return more than one response code.
The SPARQL abstract protocol defines the following responses.
Response | Type | Description |
---|---|---|
OK |
Success | Operation completed successfully |
RequestAccepted |
Informational | Operation was accepted but no further information provided. |
RequestRefused |
Informational | Operation was refused for an unspecified reason. |
MalformedRequest |
Fault | Operation faulted because of some error in the request |
Unauthorized |
Fault | Operation request not authenticated |
Forbidden |
Fault | Operation faulted because it's forbidden. |
NotFound |
Fault | Operation faulted because target not found. |
OperationPointError |
Fault | Operation faulted because of unspecified error in OperationPoint |
UnsupportedOperation |
Fault | Operation faulted because it is unsupported for the identified graph. |
Unavailable |
Fault | Operation faulted because service or graph is temporarily unavaiable. |
TemporarilyMoved |
Fault | Service or graph has temporary moved to new location. |
PermanentlyMoved |
Fault | Resource or graph has permanently moved to new location. |
The SPARQL Abstract Protocol is made up of two
operations: Query
and GetGraph
.
On the Web data can be passed from one entity to another in a variety of ways. A datum can be included in a request between entities. Or it can be treated as a first-class web resource, given a dereferenceable URI, and passed by reference—that is, a URI identifying the datum can be included in a request or response between entities, with the shared expectation that the URI will be dereferenced in order to retrieve a representation of the datum. It is desirable for a variety of reasons that the SPARQL Absract Protocol be agnostic as to the various ways in which SPARQL concrete protocol designs may pass data between entities.
In the context of the Web, passing data by reference means passing data—whether queries, query targets, other operation targets, or other data—by way of passing a URI that, when dereferenced, returns a representation of that data. For example, consider the utility of authoritative sets of rules for processing subsets of OWL or RDFS. One way to share such rulesets on the Web is by giving them authoritative, or at least conventionally well-known, URIs, so that they can be retrieved when needed. We anticipate the same utility for stable URIs identifying authoritative or canonical RDF queries, including SPARQL Query Language for RDF queries. And the same considerations that apply to RDF queries are likely to apply to canonical or authoritative RDF graphs.
Alternately, in some situations, it's easier or more elegant to
pass data by value, which means here passing data in requests or
responses between entities by directly including that data in those
requests or responses in some realized representational form. Thus, in
some of the protocol operation definitions in this section, it is
permissible to include a string
that is a
valid RDFGraphQuery
in some RDF query language
grammar. And in other operations it is permissible to include
an RDFGraph
with or against which some operation is to be
performed.
Finally, in yet other situations, it may not be practical either to
pass a datum by value, perhaps because the datum is not yet known, or
to pass the datum by reference, perhaps because no such URI exists. In
some of these situations, it may make good sense to pass the data by
query or by "computed value". Passing by query means passing arguments
in which the literal representational form is a query that is to be
executed against a graph, the QueryResult
s of which are
used in some protocol operation.
The definitions of abstract operations, types, responses presented in this document are such as to constrain SPARQL concrete protocols as little as possible with regard to these ways of passing data on the Web.
All of the abstract protocol operations defined here, with the
exception of makeGraph
, are equally well conveyed to
an RDF graph as to an operation processing service. This
specification, therefore, aims to be agnostic as to which kind of
entity these operations are conveyed. But in the case where an
operation is conveyed to an RDF graph, that RDF
graph must be considered the
implicit OperationTarget
against which the operation is
to be executed. Thus, an OperationPoint
is defined as
an anyURI
that identifies either an OperationTarget
or
an OperationProcessor
. If it identifies the latter, then
the request must also include either an OperationTarget
or
an OperationTargetSet
. If it identifies the former, then
the request may include
an OperationTargetSet
, and conformant
implementations must treat
the OperationPoint
as the target against which an
operation is to be executed. The getOptions
operation may be used to determine the type of
an OperationPoint
.
Query(QueryBundle, OperationPoint[, (OperationTarget | OperationTargetSet)]) → {QueryResult, Response}
Identifier: http://www.w3.org/2005/01/sparqlP#Query
Conceptually, the arguments to the Query
operation are
threefold: (1) the query; (2) an entity responsible for handling the
query, in some manner unspecified herein; and (3) the target or
targets against which the query is to be
executed. The QueryBundle
contains or points to, via URI,
the query itself, as well as some information about how query results
are to be handled: whether some upper bound on the number of returned
results is required, and whether results should be
distinct. The OperationPoint
identifies the entity to
which the query is conveyed. The optional OperationTarget
or OperationTargetSet
identifies the RDF graph or graphs
against which the query is to be executed.
The Query
operation must convey a
query to an OperationPoint
and must
return the results of the query. The results of the Query
operation must include one of these response
types: OK
, MalformedRequest
, Unauthorized
,
Forbidden
, NotFound
, OperationPointError
,
UnsupportedOperation
, Unavailable
, TemporarilyMoved
,
or PermanentlyMoved
.
For example, Query({*, distinct: true}, http://example/1.rdf) should convey
to http://example/1.rdf the AllGraphTriples
query to be executed against http://example/1.rdf. However,
Query({"select ?a where (?a, rdf:type, foaf:Person)", limit: 5},
http://example2/qsp, {http://example/3.rdf, 2.rdf,
http://example2/3.rdf}) does not rely on an implicit
identification of the target of the operation; it conveys the query to
the OperationPoint
http://example2/qsp, to be
executed against the target set
{http://example/3.rdf, 2.rdf,
http://example2/3.rdf}, and it requests that a maximum of 5
query results be returned.
Query
is a REQUIRED protocol operation.
GetGraph(OperationPoint[, (OperationTarget | OperationTargetSet)]) → (1*RDFGraph, 1*Response)
Identifier: http://www.w3.org/2005/01/sparqlP#GetGraph
GetGraph
is a simple operation, essentially requesting
a representation of one, or distinct representations of more than
one, RDFGraph
(s), identified by one or
more anyURI
s, from an OperationPoint
.
Thus, GetGraph
returns the
serialized RDFGraph
identified by OperationTarget
or all of
the separately serialized RDFGraph
s identifed
by OperationTargetSet
. SPARQL concrete
protocols should specify expected behavior in the
case where one or more members of the OperationTargetSet
are unavailable, but one or more are available, for
retrieval. The results of the GetGraph
operation must include one or more of these response
types: OK
, MalformedRequest
, Unauthorized
,
Forbidden
, NotFound
, OperationPointError
,
UnsupportedOperation
, Unavailable
, TemporarilyMoved
,
or PermanentlyMoved
.
For example, GetGraph(http://example/qsp,
{http://example/1.rdf, http://example/2.rdf/, 3.rdf}) is a
request, conveyed to http://example/qsp, for
three RDFGraph
s: http://example/1.rdf, http://example/2.rdf,
and 3.rdf. Likewise, GetGraph(http://example/3.rdf)
is a request, conveyed to http://example/3.rdf for
the RDFGraph
identified by http://example/3.rdf.
GetGraph
is an OPTIONAL protocol operation.
GetServiceDescription(OperationPoint[, (OperationTarget | OperationTargetSet)]) → (1*RDFGraph, 1*Response)
Identifier: http://www.w3.org/2005/01/sparqlP#GetServiceDescription
The GetServiceDescription
operation returns
an RDFGraph
that describes the protocol and query
language options for a particular RDFGraph
or for OperationProcessor
. The
results of the GetServiceDescription
operation must
include one or more of these response types: OK
,
MalformedRequest
, Unauthorized
,
Forbidden
, NotFound
, OperationPointError
,
UnsupportedOperation
, Unavailable
, TemporarilyMoved
,
or PermanentlyMoved
.
For example, GetServiceDescription(http://example/qsp)
returns—on the assumption that http://example/qsp
identifies an OperationProcessor
—an
RDFGraph
describing the protocol and query language
options, as well as the available QueryTarget
s. Likewise,
GetServiceDescription(http://example/qsp, 2.rdf) returns
an RDFGraph
describing the protocol and query language
options that may be invoked with 2.rdf as
an OperationTarget
. Finally,
GetServiceDescription(http://example/3.rdf) returns
an RDFGraph
describing the protocol and query language
options that may be invoked with http://example/3.rdf as
an OperationPoint
or OperationTarget
.
GetServiceDescription
is an OPTIONAL protocol
operation.
SPARQL Abstract Response Type | HTTP Response Code |
---|---|
OK |
200 OK |
GraphCreated |
201 Created |
OperationRequestAccepted |
202 Accepted |
PermanentlyMoved |
301 Moved Permanently |
TemporarilyMoved |
307 Temporary Redirect |
MalformedRequest , MalformedQuery
|
400 Bad Request |
Unauthorized |
401 Unauthorized |
Forbidden |
403 Forbidden |
NotFound |
404 Not Found |
NoDeletionPerformed , RequestRefused |
409 Conflict |
OperationPointError |
500 Internal Server Error |
UnsupportedOperation |
501 Not Implemented |
Unavailable |
503 Service Unavailable |
Parameter Name | Parameter Value Type | Parameter Semantics | Cardinality |
---|---|---|---|
query | FIXME | Contains a legal RDF query language ...FIXME... | max 1 |
query-uri | anyURI | Identifies a legal RDF query language... | max 1 |
query-lang | anyURI | Identifies the type of RDF query language (FIXME) contained in the query parameter | max 1 |
graph-id | string or anyURI | Identifies a target graph...SOURCE/FROM (FIXME) | 0 or 1 |
distinct | boolean | DistinctQueryResults | 0 or 1 |
limit | integer | LimitQueryResults | 0 or 1 |
If query is present, query-lang must also be present, except where the type of the query is SPARQL...FIXME.
@@ need discussion of each one, but examples work for now to make the point
@@ need to add more examples: non-sparql query example; conditional get; cache-control; authentication; faults; response bodies in RDF; Allow, Expect, Accept-Range
@@ sort out the return types: xml var bindings, rdf subgraphs, var bindings in rdf, booleans
@@ show the alternate query form for queries that are too long to be conveyed via GET and query parameters...
1.1 query: One query against one RDF graph. Value of graph is "http://my.example/3.rdf"; value of the query is "SELECT ?a ?b ?c WHERE (?a, ?b, ?c)".
GET /qps?query-lang=http...&graph-id=http%3A%2F%2Fmy.example%2F3.rdf&query=SELECT+%3Fa%2C+%3Fb%2C+%3Fc+WHERE+%28%3Fa%2C+%3Fb%2C+%3Fc%29&distinct=true&limit=10 HTTP/1.1 User-Agent: my-sparql-client/0.0 Host: my.example
200 OK HTTP/1.1 Server: my-sparql-server/0.0 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <results xmlns="http://www.w3.org/2001/sw/DataAccess/rf1/result"> <result> <a uri="http://work.example.org/alice/"/> <b uri="http://work.example.org/#name"/> <c>Alice</c> </result> <result> <a uri="http://work.example.org/bob/"/> <b uri="http://work.example.org/#name"/> <c xml:lang="en">Bob</c> </result> </results>
1.2 query: One query, passed by reference, against one RDF graph
GET /qps?graph=http%3A%2F%2Fmy.example%2F3.rdf&query-uri=http%3%2F%2Fmy.example%2Fquery.spql HTTP/1.1 User-Agent: my-sparql-client/0.0 Host: my.example
200 OK HTTP/1.1 Server: my-sparql-server/0.0 Content-Type: application/rdf+xml <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:iswc="http://annotation.semanticweb.org/2004/iswc#" xml:base="http://www.mindswap.org/2004/iswc"> <iswc:InProceedings rdf:ID="server-side-xptr-paper"> <rdfs:seeAlso rdf:resource="iswc.html"/> <iswc:title>A Semantic Web Resource Protocol: XPointer and HTTP</iswc:title> <iswc:author rdf:resource="#bijan"/> <iswc:author rdf:resource="http://clark.dallas.tx.us/kendall/foaf.rdf"/> <iswc:author rdf:resource="#bryan"/> <iswc:conference rdf:resource="#ISWC2004"/> <iswc:year>2004</iswc:year> <iswc:topic rdf:resource="http://annotation.semanticweb.org/2004/iswc#Semantic_Web_Middleware"/> </iswc:InProceedings> </rdf:RDF>
1.3 query: One query against multiple RDF Graphs
GET /qps?graph=2.rdf&graph=4.rdf&graph=http%3A%2F%2Ffoaf.example%2Ffoaf%3fid=50&query=SELECT+%2A HTTP/1.1 User-Agent: my-sparql-client/0.0 Host: my.example
200 OK HTTP/1.1 Server: my-sparql-server/0.0 Content-Type: multipart/mime
2.1 GetGraph: Retrieve graph with content negotiation for RDF/XML
GET /qps?graph=1.rdf HTTP/1.1 Accept: application/rdf+xml;q=0.9,text/n3;q=0.2 Accept-Encoding: gzip,deflate,compress;q=0.9 Accept-Charset: utf-8 User-Agent: my-sparql-client/0.0 Host: my.example
200 OK HTTP/1.1 Server: my-sparql-server/0.0 Content-Type: application/rdf+xml <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF>...</rdf:RDF>
2.2 GetGraph Retrieve RDF graph with content negotiation for N3
GET /3.rdf HTTP/1.1 Accept: text/n3 Accept-Encoding: gzip,deflate,compress;q=0.9 Accept-Chareset: utf-8 User-Agent: my-sparql-client/0.0 Host: my.example
200 OK HTTP/1.1 Content-Type: text/n3 @prefix foaf: <http://xmlns.com/foaf/0.1/%gt; . [] foaf:name "Johnny Lee Outlaw" ; foaf:mbox <mailto:jlow@example.com> .
2.3 GetGraph: Retrieve multiple RDF graphs
GET /qps?graph=2.rdf&graph=4.rdf HTTP/1.1 User-Agent: my-sparql-client/0.0 Host: my.example
200 OK HTTP/1.1 Content-Type: multipart/related ...
(Note: I've adapated most of this from the extended EBNF in RFC 2616. Some of the descriptive text below is quoted directly from RFC 2616.)
→
A right-arrow character indicates the return types of a protocol operation.
instanceOf(<anyURI>)
Indicates a well-formed, and optionally valid, instance of an XML vocabulary identified by <URI>. For example, instanceOf(http://www.w3.org/1999/02/22-rdf-syntax-ns#) indicates a well-formed instance of RDF/XML. Representation types other than XML may be expressed in the same notation even if they do not define well-formedness or validity or define it differently than XML.
key: value
Two elements separated by a comma indicates a key-value pair.
A | B
Elements separated by a bar indicate alternatives.
{A, B, C}
Elements enclosed in curly braces and separated by a comma indicate a set of elements.
+(*A, 1*5B)
Elements, including optionals and repetitions, enclosed in +( and ), and separated by commas, indicate a bag—an unordered collection with duplicates.
(*A, 1*5B)
Elements, including optionals and repetitions, enclosed in parentheses, and separated by commas, indicate a list—an ordered collection with duplicates.
C(A, B)
A name followed by elements, including optionals, enclosed in parentheses and separted by commas indicate the arguments of an operation, C.
[A]
Elements enclosed in square brackets indicate optional elements.
*A
The asterisk character preceding an element indicates repetition. The full form is <n>*<m>element indicating at least <n> and at most <m> occurrences of element. Default values are 0 and no-upper-bound so that *(element) allows any number, including zero; 1*element requires at least one; and 1*2element allows one or two.
<n>(A)
Indicates <n> repetitions of A.
[A_B_C]
A string of bold upper case letters, separated by _, enclosed in square brackets indicates the abstract name of some HTTP query parameter.
From RFC 2616, "A program that establishes connections for the purpose of sending requests."
A program that establishes connections for the purpose of sending SPARQL abstract protocol requests.
From RFC 2616, "An application program that accepts connections in order to service requests by sending back responses."
A program that accepts connections in order to service SPARQL abstract protocol operations by returning the results of those operations and appropriate response types.
From RFC 2616, "The server on which a given resource resides or is to be created."
There are at least two ways to conceptualize and implement a SPARQL server in a heterogenous environment like the Web. The first way is graph-centric: the resources exposed to SPARQL operations are RDF graphs. The second way is service-centric: the primary resource exposed is a service that receives requests for SPARQL operations and responds accordingly. In this document a service-centric SPARQL server is known as an Operation Processor Service.
A service or graph endpoint; i.e., a class of Web resource, identified by URI, that encompasses both SPARQL Operation Processor Services and RDF graphs. The SPARQL protocol conveys protocol operation requests, including queries, from SPARQL clients to Operation Points and returns the responses to clients.
A computer language for querying RDF graphs. For example, SPARQL Query Language for RDF, RDQL, and SeRQL are RDF query languages.
A legal sentence in a particular RDF query language grammar.
From RDF Semantics, 6.1 RDF Triples, "An RDF triple contains three components: the subject, which is an RDF URi reference or a blank node; the predicate, which is an RDF URI reference; [and] the object, which is an RDF URI reference, a literal or a blank node."
A base or told RDF triple is one that exists explicitly in an RDF graph or knowledge base. For example, in the RDF graph
@prefix triumph: <http://triumph.example/schema/#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . <http://triumph.example/part/0d92ie433> rdf:type triumph:part ; rdfs:label "Accelerator Cable MK3" ; triumph:part-number "LCD 100-04BSPT" .
the RDF triple (http://triumph.example/part/0d92ie433, rdf:type, triumph:part) is a told or base triple.
A virtual or inferred triple is one that does not exist explicitly in an RDF graph or knowledge base; it exists as a result of some inference or reasoning operation on the graph.
From RDF Semantics, 6.2 RDF Graph, "An RDF graph is a set of RDF triples. The set of nodes of an RDF graph is the set of subjects and objects of triples in the graph."
A set of abstract protocol operations, basic types, and responses for conveying operation requests from clients to servers and for conveying operation results from servers to clients.
A concrete implementation—concrete opereations, types, and responses—of the abstract protocol which may itself be realized by means of another, existing concrete protocol; for example, HTTP or SOAP.
Some abstract protocol operations specify results that are to be returned by the server that executes those operations. Query and other operation results are to be distinguished from the response codes that the server may be required to return.
The Internet Media Type of a Query Result.
An RDF graph against which a protocol operation, including a query, is to be executed.
Joseki, DIG, AtomAPI, Annotea Protocol, REST, SS XPtr stuff, HTTP 1.1 spec, TAG URIs, WebArch
My thanks to members of DAWG, especially Bryan Thompson, Andy Seaborne, and Eric Prud'hommeaux, as well as to my UMD colleagues Bijan Parisa, Jim Hendler, Ron Alford, and the members of the Mindlab Semantic Web Undergraduate Social—all of whom helped make this document possible.
CVS Change Log:
$Log: Overview.html,v $ Revision 1.3 2018/10/09 13:31:07 denis fix validation of xhtml documents Revision 1.2 2017/10/02 10:30:41 denis add fixup.js to old specs Revision 1.1 2005/01/14 16:23:57 matthieu new entry Revision 1.14 2005/01/14 15:06:05 eric result namespace Revision 1.13 2005/01/14 14:50:24 eric validated ids with '+' in them Revision 1.12 2005/01/14 14:39:29 eric typo Revision 1.11 2005/01/14 14:37:40 eric fixed some anchors Revision 1.10 2005/01/14 02:37:04 eric + fixed SOTD per kendall's correction Revision 1.9 2005/01/13 15:30:08 eric + fixed some borken links Revision 1.8 2005/01/13 14:33:14 eric + fixed some more ids Revision 1.7 2005/01/13 14:32:12 eric added ids Revision 1.6 2005/01/13 14:10:23 eric finished simple XML validation Revision 1.5 2005/01/13 13:06:51 eric validating Revision 1.4 2005/01/13 12:52:44 eric + added abstract and SOTD + getting into form for TR publication Revision 1.3 2005/01/13 12:24:15 eric + switched to http://www.w3.org/2005/01/sparqlP# namespace - concearned that poor editing blurred the distinctinon between the class Query and the parameter query Revision 1.2 2005/01/13 11:14:25 eric added change log