SPARQL 프로토콜 및 RDF 질의 언어(SPARQL)는 RDF를 위한 질의 언어이자 프로토콜입니다. 이 문서는 SPARQL 프로토콜을 명시하며,
SPARQL 질의 및 업데이트를 SPARQL 처리 서비스에 전달하고 그 결과를
HTTP를 통해 이를 요청한 엔티티에 반환하기 위한 수단을 설명합니다. 이 프로토콜은 W3C
SPARQL 워킹 그룹에서 개발했으며, 시맨틱 웹 활동의 일부로서
활동 선언문에 설명되어 있습니다.
이 문서의 상태
이 절은 이
문서가 게시된 시점의 상태를 설명합니다. 현재 W3C
간행물 목록과 이 기술 보고서의 최신 개정판은
W3C 표준 및 초안
색인에서 확인할 수 있습니다.
이 문서는 초안 문서이며 언제든지 다른
문서로 갱신, 대체 또는 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로
인용하는 것은 적절하지 않습니다.
향후 이 예정 권고안의 업데이트에는
새 기능이 포함될 수 있습니다.
이 문서는
W3C
특허
정책에 따라 운영되는 그룹에서 작성했습니다.
W3C는
이 그룹의 산출물과 관련하여 이루어진
모든 특허 공개의 공개 목록을
유지합니다. 해당 페이지에는
특허 공개 지침도 포함되어 있습니다. 개인이
필수 청구항을 포함한다고 믿는 특허를 실제로
알고 있는 경우, 그 개인은
W3C 특허 정책 제6절에 따라
정보를 공개해야 합니다.
이 문서는 SPARQL 1.2 프로토콜, 즉 클라이언트에서 SPARQL 프로세서로 SPARQL 질의와 업데이트를
전달하기 위한 수단을 설명합니다. SPARQL 프로토콜은
SPARQL 1.2 질의
언어 및
SPARQL 1.2
업데이트와의 호환성을 위해 설계되었습니다. 이 문서는 주로
SPARQL 질의 및 업데이트 서비스와 클라이언트 구현에 관심 있는 소프트웨어 개발자를 대상으로 합니다.
SPARQL 프로토콜은 두 가지 HTTP 작업으로 구성됩니다. SPARQL 질의 언어 질의를 수행하기 위한
질의 작업과 SPARQL 업데이트 언어 요청을 수행하기 위한
업데이트
작업입니다. SPARQL 프로토콜 클라이언트는 요청을 처리하고
원래 클라이언트로 HTTP 응답을 되돌려 보내는 SPARQL 프로토콜 서비스에 HTTP 요청을 보냅니다.
별도의 문서는 REST 아키텍처 스타일에서 그래프 컬렉션을 관리할 목적으로
HTTP 작업을 사용하는 방법을 설명하는 SPARQL 1.2 그래프 저장소
프로토콜을 설명합니다.
1.1 문서 규약
이 문서에서 해야 한다, 해서는 안 된다,
하는 것이 좋다, 하지 않는 것이 좋다,
및 할 수 있다라는 단어를 사용하고, 그 단어들이 강조 텍스트로 나타나는 경우,
[RFC2119]에
설명된 대로 해석해야 합니다.
SPARQL 프로토콜은 query와 update라는 두 작업으로 구성됩니다. 프로토콜 작업은 다음의 조합을
정의합니다.
요청이 전송되는 HTTP 메서드.
HTTP 요청 URI에 포함되는 HTTP 질의 문자열 매개변수.
HTTP 요청 본문에 포함되는 메시지 콘텐츠.
HTTP 응답 본문에 포함되는 메시지 콘텐츠.
SPARQL 1.2 프로토콜은 HTTP 위에 구축됩니다. 요청과 응답에 대한 모든 HTTP 요구사항은
준수해야 합니다.
2.1 버전 공지
엔드포인트로 질의 또는 업데이트 작업을 보낼 때, 이 작업의 버전은
구문상의 version 지시자를 사용하거나,
version 매개변수(사용된 HTTP 메서드에 따라 달라짐)를 전달하여
공지할 수 있습니다.
버전이 구문과 매개변수 양쪽 모두에 표시된 경우,
둘은 동일해야 합니다.
서로 다를 경우,
파서는 매개변수의 버전을 사용하고 불일치에 대한 경고를 낼 수 있습니다.
이전 파서와 가능한 한 폭넓은 호환성을 유지하기 위해,
SPARQL 1.2 전용 기능을 사용하는 질의에 한해서만
버전을 공지하는 것이 권장됩니다(즉, SPARQL 1.2 전용 기능을 사용하지 않는
질의의 경우 버전을 공지하지 않는 것이 좋습니다).
작업에 대한 응답도 버전 공지를 포함할 수 있습니다.
SPARQL 결과 버전 또는 RDF 버전은 요청에 지정된
작업 버전과 반드시 같지는 않습니다.
대신 버전 공지는 응답과 그 형식에 따라 달라지며, 예를 들면 SPARQL 1.2 질의 결과 JSON
형식 또는 RDF 1.2 Turtle과 같습니다.
query 작업은 SPARQL 질의를 서비스로 보내고 그 질의의 결과를 받는 데 사용됩니다.
질의 작업은 HTTP GET 또는 HTTP POST 메서드 중 하나로 호출되어야 합니다.
이 작업에 대한 클라이언트 요청은 정확히 하나의 SPARQL 질의 문자열
(매개변수 이름: query)을 포함해야 하며,
버전(매개변수 이름: version)을 포함할 수 있고,
0개 이상의 기본 그래프 URI(매개변수 이름: default-graph-uri)와 명명된 그래프
URI(매개변수 이름: named-graph-uri)를 포함할 수 있습니다.
질의 요청에 대한 응답은 질의 형식과
콘텐츠 협상 [RFC9110]에 따라
SPARQL 결과 또는 RDF에 대응하는 형식이어야 합니다.
그러한 형식의 예는 다음과 같습니다.
query (정확히 1개) version (0개 또는 1개) default-graph-uri (0개 이상) named-graph-uri (0개 이상)
없음
없음
URL 인코딩 POST를 통한 query
POST
없음
application/x-www-form-urlencoded
URL 인코딩되고 앰퍼샌드로 구분된 질의 매개변수. query (정확히 1개) version (0개 또는 1개) default-graph-uri (0개 이상) named-graph-uri (0개 이상)
POST 직접 전송을 통한 query
POST
default-graph-uri (0개 이상) named-graph-uri (0개 이상)
application/sparql-query (선택적 version 미디어 유형
매개변수 포함)
인코딩되지 않은 SPARQL 질의 문자열
query 요청의 매개변수는 다음 세 가지 옵션 중 하나에 따라
전송되어야 합니다.
2.2.1 GET을 통한 query
프로토콜 클라이언트는 HTTP GET 메서드를 통해 프로토콜 요청을 보낼 수 있습니다.
GET 메서드를 사용할 때, 클라이언트는 모든 매개변수를 URL
퍼센트 인코딩해야 하며,
위에 주어진 이름으로 질의 매개변수 문자열 [RFC3986]로
포함해야 합니다.
HTTP 질의 문자열 매개변수는 앰퍼샌드
(&) 문자로 구분되어야 합니다. 클라이언트는 질의 문자열 매개변수를 임의의 순서로 포함할 수 있습니다.
HTTP 요청은 메시지 본문을 포함해서는 안 됩니다.
2.2.2
URL 인코딩 매개변수와 함께 POST를 통한 query
프로토콜 클라이언트는 매개변수를 URL 인코딩하여 HTTP POST 메서드를 통해
프로토콜 요청을 보낼 수 있습니다. 이 메서드를 사용할 때, 클라이언트는 모든 매개변수를 URL
퍼센트 인코딩 [RFC3986]해야
하며, 위에 주어진 이름을 사용하여 요청 본문 내의 매개변수로
application/x-www-form-urlencoded 미디어 유형을 통해 포함해야 합니다. 매개변수는
앰퍼샌드(&) 문자로 구분되어야 합니다. 클라이언트는
매개변수를 임의의 순서로 포함할 수 있습니다. HTTP 요청의 콘텐츠 유형 헤더는
application/x-www-form-urlencoded로 설정되어야 합니다.
2.2.3 POST 직접 전송을 통한
query
프로토콜 클라이언트는 HTTP 요청 메시지 본문으로 질의를 직접, 인코딩하지 않은 채 포함하여
HTTP POST 메서드를 통해 프로토콜 요청을 보낼 수 있습니다. 이
방식을 사용할 때, 클라이언트는 SPARQL 질의 문자열을 인코딩하지 않은 채 포함해야 하며,
요청의 메시지 본문에는 그 외 아무것도 포함해서는 안 됩니다. 클라이언트는 HTTP 요청의
콘텐츠 유형 헤더를 application/sparql-query로 설정해야 하며, 선택적
version 미디어 유형 매개변수를 포함할 수 있습니다. 클라이언트는 선택적
default-graph-uri 및 named-graph-uri
매개변수를 요청 URI의 HTTP 질의 문자열 매개변수로 포함할 수 있습니다. 여기서 UTF-8만이 유효한
문자셋이라는 점에 유의하십시오.
2.2.4 RDF 데이터셋 지정
SPARQL 질의는 RDF 데이터셋에 대해 실행됩니다.
질의에 대한 RDF 데이터셋은 SPARQL 프로토콜의
default-graph-uri 및 named-graph-uri 매개변수를 통해 지정하거나,
FROM 및 FROM NAMED 키워드를 사용하여 SPARQL 질의 문자열 안에서
지정할 수 있습니다. 프로토콜 요청과 SPARQL 질의 문자열 양쪽에 서로 다른 RDF 데이터셋이
지정된 경우, SPARQL 서비스는 프로토콜 요청에 주어진 RDF
데이터셋을 사용하여 질의를 실행해야 합니다.
서비스가 프로토콜 클라이언트가 RDF 데이터셋을 지정하는 것을 허용하지 않는 경우,
서비스는 HTTP 응답 코드 400으로 질의를 거부할 수 있음에 유의하십시오.
프로토콜 요청이나 SPARQL 질의 문자열 어느 쪽에도 RDF 데이터셋이 지정되지 않은 경우,
구현은 구현에서 정의한 기본 RDF 데이터셋에 대해 질의를 실행할 수 있습니다.
2.2.5 허용되는 응답 형식
프로토콜 클라이언트는 클라이언트가 소비할 수 있는 응답 형식을 요청하기 위해
HTTP 콘텐츠 협상 [RFC9110]을
사용하는 것이 좋습니다. 가능한 응답 형식에 대한 자세한 내용은 아래를 참조하십시오.
2.2.6 성공 응답
SPARQL 프로토콜은 작업의 성공 또는 실패를 나타내기 위해 HTTP에서 정의한 응답 상태 코드를 사용합니다.
각 상태 코드의 자세한 정의는 HTTP 명세
[RFC9110]를 참조하십시오.
프로토콜 서비스는 성공적인 질의에 대해
2XX HTTP 응답 코드를 사용하는 것이 좋지만, HTTP에 따라 대신 3XX 응답 코드를
사용할 수 있습니다.
성공적인 질의 작업에 대한 응답의 콘텐츠 유형은 응답 본문의 형식에 대해 정의된
미디어 유형이어야 합니다.
2.2.7 실패 응답
실패한 질의 작업에 적용되는 HTTP 응답 코드는 다음을 포함합니다.
요청에 제공된 SPARQL 질의가 SPARQL 문법에서 정의한 언어의 올바른 문자 시퀀스가 아닌 경우
400, 또는
서비스가 질의를 실행하지 못한 경우 500. SPARQL 프로토콜 서비스가 질의 실행을 거부하는 경우에도
500 응답 코드를 반환할 수 있습니다. 이 응답은
서버가 이후의 동일한 요청 하나 또는 여러 요청을 처리할 수 있는지 여부를 나타내지 않습니다.
실패한 질의 요청의 응답 본문은 구현 정의입니다. 구현은
실패한 질의 요청에 대한 사람이 읽을 수 있거나 기계가 처리할 수 있는
(또는 둘 다의) 정보를 제공하기 위해 HTTP 콘텐츠 협상을 사용할
수 있습니다.
프로토콜 서비스는 HTTP에 따라 다른 실패 조건에 대해 다른 4XX 또는 5XX HTTP 응답 코드를
사용할 수 있습니다.
2.3 업데이트 작업
update 작업은 SPARQL 업데이트 요청을 서비스로 보내는 데 사용됩니다. 업데이트
작업은 HTTP POST 메서드를 사용하여 호출되어야 합니다. 이 작업에 대한
클라이언트 요청은 정확히 하나의 SPARQL 업데이트 요청 문자열(매개변수
이름: update)을 포함해야 하며, 버전(매개변수 이름:
version)과 0개 이상의 기본 그래프
URI(매개변수 이름: using-graph-uri) 및 명명된 그래프 URI(매개변수 이름:
using-named-graph-uri)를 포함할 수 있습니다. 업데이트 요청에 대한 응답은
HTTP 응답 상태 코드를 통해 요청의 성공 또는 실패를 나타냅니다.
HTTP 메서드
질의 문자열 매개변수
요청 콘텐츠 유형
요청 메시지 본문
URL 인코딩 POST를 통한 update
POST
없음
application/x-www-form-urlencoded
URL 인코딩되고 앰퍼샌드로 구분된 질의 매개변수. version (0개 또는 1개) update (정확히 1개) using-graph-uri (0개 이상) using-named-graph-uri (0개 이상)
application/sparql-update (선택적 version 미디어 유형
매개변수 포함)
인코딩되지 않은 SPARQL 업데이트 요청 문자열
update 요청의 매개변수는 다음 두 가지 옵션 중 하나에 따라
전송되어야 합니다.
2.3.1
URL 인코딩 매개변수와 함께 POST를 통한 update
프로토콜 클라이언트는 매개변수를 URL 인코딩하여 HTTP POST 메서드를 통해
업데이트 프로토콜 요청을 보낼 수 있습니다. 이 방식을 사용할 때, 클라이언트는 모든 매개변수를 URL
퍼센트
인코딩해야 하며, 위에 주어진 이름을 사용하여 요청 본문 내의 매개변수로
application/x-www-form-urlencoded 미디어 유형을 통해 포함해야 합니다. 매개변수는
앰퍼샌드(&) 문자로 구분되어야 합니다. 클라이언트는
매개변수를 임의의 순서로 포함할 수 있습니다. HTTP 요청의 콘텐츠 유형 헤더는
application/x-www-form-urlencoded로 설정되어야 합니다.
2.3.2 POST 직접 전송을 통한
update
프로토콜 클라이언트는 HTTP 요청 메시지 본문으로 업데이트 요청을 직접, 인코딩하지 않은 채 포함하여
HTTP POST 메서드를 통해 업데이트 프로토콜 요청을 보낼 수 있습니다. 이
방식을 사용할 때, 클라이언트는 SPARQL 업데이트 요청 문자열을 인코딩하지 않은 채 포함해야
하며, 요청의 메시지 본문에는 그 외 아무것도 포함해서는 안 됩니다. 클라이언트는 HTTP 요청의
콘텐츠 유형 헤더를 application/sparql-update로 설정해야 하며, 선택적
version 미디어 유형 매개변수를 포함할 수 있습니다. 클라이언트는 선택적
using-graph-uri 및
using-named-graph-uri 매개변수를 요청 URI의 HTTP 질의 문자열 매개변수로 포함할
수 있습니다.
2.3.3 RDF 데이터셋 지정
SPARQL 업데이트 요청은 SPARQL 서비스가 관리하는 RDF 그래프의 변경 가능한 컨테이너인
그래프 저장소에 대해 실행됩니다. SPARQL 업데이트 DELETE/INSERT 작업의
WHERE 절은 그래프 저장소의 하위 집합인
RDF 데이터셋의 데이터와 매치됩니다.
업데이트 작업에 대한 RDF 데이터셋은 USING, USING NAMED 및/또는
WITH 키워드를 사용하여 작업 문자열 자체 안에 지정할 수 있으며, 또는
using-graph-uri 및
using-named-graph-uri 매개변수를 통해 지정할 수도 있습니다.
USING, USING NAMED 또는 WITH 절을 사용하는 작업을
포함하는 SPARQL 1.2 업데이트 요청을 이 프로토콜로 전달할 때
using-graph-uri 또는 using-named-graph-uri
매개변수를 제공하는 것은 오류입니다.
SPARQL 업데이트 프로세서는 업데이트 프로토콜 작업에서 using-graph-uri=g
매개변수가 나타날 때마다 SPARQL 1.2 업데이트 요청의 모든 작업에 대해
USING <g> 절이 포함된 것처럼 처리하는 것이 좋습니다. 마찬가지로 SPARQL 업데이트 프로세서는
업데이트 프로토콜 작업에서 using-named-graph-uri=g 매개변수가 나타날 때마다
SPARQL 1.2 업데이트 요청의 모든 작업에 대해
USING NAMED <g> 절이 포함된 것처럼 처리하는 것이 좋습니다.
2.3.4 성공 응답
SPARQL 프로토콜은 작업의 성공 또는 실패를 나타내기 위해 HTTP에서 정의한 응답 상태 코드를 사용합니다.
각 상태 코드의 자세한 정의는 HTTP 명세
[RFC9110]를 참조하십시오.
프로토콜 서비스는 성공적으로 처리된 업데이트 요청에 대해
2XX HTTP 응답 코드를 사용하는 것이 좋지만, HTTP에 따라 대신
3XX
응답 코드를 사용할 수 있습니다.
성공적인 업데이트 요청의 응답 본문은 구현 정의입니다. 구현은
완료된 업데이트 요청에 대한 사람이 읽을 수 있고
기계가 처리할 수 있는 정보를 모두 제공하기 위해 HTTP 콘텐츠 협상을 사용할
수 있습니다.
2.3.5 실패 응답
실패한 업데이트 요청에 대한 HTTP 응답 코드는 다음이어야 합니다.
SPARQL 업데이트 요청 문자열이 SPARQL 업데이트 문법에서 정의한 언어의 올바른 문자 시퀀스가 아닌 경우
400, 또는
서비스가 업데이트 요청을 실행하지 못한 경우 500. SPARQL 프로토콜 서비스가
업데이트 요청 실행을 거부하는 경우에도 500 응답 코드를 반환할 수 있습니다. 이 응답은
서버가 이후의 동일한 요청 하나 또는 여러 요청을 처리할 수 있는지 여부를
나타내지 않습니다.
실패한 업데이트 요청의 응답 본문은 구현 정의입니다. 구현은
실패한 업데이트 요청에 대한 사람이 읽을 수 있거나 기계가 처리할 수 있는
(또는 둘 다의) 정보를 제공하기 위해 HTTP 콘텐츠 협상을 사용할
수 있습니다.
프로토콜 서비스는 HTTP에 따라 다른 실패 조건에 대해 다른 4XX 또는 5XX HTTP 응답 코드를
사용할 수 있습니다.
2.4 기준 IRI 결정
SPARQL 질의 또는 SPARQL 업데이트 요청 문자열의 BASE 키워드는
Uniform
Resource Identifier (URI): Generic
Syntax 5.1.1절 "콘텐츠에 포함된 기준 URI"에 따라 상대 IRI를 해석하는 데
사용되는 기준 IRI를 정의합니다. SPARQL 프로토콜은
질의 URI를 역참조하지 않으므로 5.1.3절은 적용되지 않습니다. 마지막으로 5.1.4절에 따라
SPARQL 프로토콜 서비스는 자체 기준 URI를 정의해야 하며,
이는 서비스 엔드포인트일 수 있습니다.
3. SPARQL 프로토콜
요청 예(정보 제공)
다음 HTTP 추적 예는 여러 다른 시나리오에서 query 및 update
작업을 호출하는 방법을 보여 줍니다. 일부 예제 추적은
완전한 HTTP 추적에서 다음과 같은 방식으로 추상화되었습니다.
일부 예에서 문자열 "EncodedQuery"는 예에 주어진
SPARQL 질의 문자열에 해당하는 URL 인코딩 문자열을 나타내며, 문자열 "UnencodedQuery"는
예에 주어진 정확한 SPARQL 질의 문자열을 인코딩 없이 나타냅니다.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?who ?g ?mbox
FROM <http://www.example/publishers>
FROM NAMED <http://www.example/alice>
FROM NAMED <http://www.example/bob>
WHERE { ?g dc:publisher ?who .
GRAPH ?g { ?x foaf:mbox ?mbox }
}
는 이 HTTP 추적에 보인 것처럼 SPARQL 질의 서비스
http://www.example/sparql/로 전달됩니다.
GET /sparql/?query=EncodedQuery HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
응답은 다음과 같습니다.
HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
...
</sparql>
3.1.8 모호한
RDF 데이터셋을 사용하는 SELECT
이 SPARQL 질의
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?who ?g ?mbox
FROM <http://www.example/publishers>
FROM NAMED <http://www.example/john>
FROM NAMED <http://www.example/susan>
WHERE { ?g dc:publisher ?who .
GRAPH ?g { ?x foaf:mbox ?mbox }
}
는 이 HTTP 추적에 보인 것처럼 SPARQL 질의 서비스
http://www.example/sparql/로 전달됩니다.
GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fmorepublishers
&named-graph-uri=http%3A%2F%2Fwww.example%2Fbob&named-graph-uri=http%3A%2F%2Fwww.example%2Falice HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
이 프로토콜 작업에는 모호한 RDF 데이터셋이 포함되어 있습니다. 질의에 지정된 데이터셋이
프로토콜에(default-graph-uri 및 named-graph-uri
매개변수를 통해) 지정된 데이터셋과 다릅니다. 적합한 SPARQL
프로토콜 서비스는 프로토콜에 지정된 RDF 데이터셋에 대해 질의를 실행하여
이 모호성을 해결해야 합니다.
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?name
WHERE { ?x foaf:name ?name
ORDER BY ?name }
는 이 HTTP 추적에 보인 것처럼 SPARQL 질의 서비스
http://www.example/sparql/로 전달됩니다.
GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fwww.example%2Fmorepublishers HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
오류 응답은 다음과 같습니다.
HTTP/1.1 400 Bad Request
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: text/plain; charset=UTF-8
4:syntax error, unexpected ORDER, expecting '}'
3.1.10 질의 요청
거부 오류가 있는 SELECT
이 SPARQL 질의
PREFIX bio: <http://bio.example/schema/#>
SELECT ?valence
FROM <http://another.example/protein-db.rdf>
WHERE { ?x bio:protein ?valence }
ORDER BY ?valence
는 이 HTTP 추적에 보인 것처럼 SPARQL 질의 서비스
http://www.example/sparql/로 전달됩니다.
GET /sparql/?query=EncodedQuery&default-graph-uri=http%3A%2F%2Fanother.example%2Fprotein-db.rdf HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
오류 응답은 다음과 같습니다.
HTTP/1.1 500 Internal Server Error
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: text/plain
SPARQL Processing Service: Query Request Refused
Your request could not be processed because http://another.example/protein-db.rdf
could not be retrieved within the time alloted.
HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4 DAV/1.0.3
Connection: close
Content-Type: application/sparql-results+xml
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
<head>
<variable name="summary"/>
</head>
<results>
<result>
<binding name="summary">
<literal>Chiefs vs. Cleveland @ Cleveland Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. Jacksonville @ Arrowhead Stadium</literal>
</binding>
</result>
<result>
<binding name="summary">
<literal>Chiefs vs. New England @ Gillette Stadium</literal>
</binding>
</result>
...
<result>
<binding name="summary">
<literal>Chiefs vs. Oakland @ Network Associates Coliseum</literal>
</binding>
</result>
</results>
</sparql>
3.1.12 직접 POST를
사용하는 긴 SELECT 질의
SPARQL 질의는 2.1.3 POST 직접 전송을 통한 query에 설명된 것처럼
URL 인코딩 없이 직접 POST될 수도 있습니다. 이전 예에서 사용한 동일한 질의가 이 HTTP 추적에 보인 것처럼
SPARQL 질의 서비스
http://www.example/sparql/로 전달됩니다.
POST /sparql/?default-graph-uri=http%3A%2F%2Fanother.example%2Fcalendar.rdf HTTP/1.1
Host: www.example
User-agent: sparql-client/0.1
Content-Type: application/sparql-query
UnencodedQuery
응답은 이전 예와 동일합니다.
3.1.13 국제화를
사용하는 SELECT
SPARQL 질의는 국제화된 문자나 문자 집합을 포함할 수 있습니다. 이 SPARQL 질의
는 SPARQL 질의 서비스 http://www.example/sparql/로 전달됩니다. 이 질의는
SPARQL 1.2 구문을 사용하지만 구문적으로 1.2 버전을 공지하지 않으므로,
GET 요청은 version=1.2 매개변수를 사용하여 발행됩니다. 이는
이 HTTP 추적에 보입니다.
GET /sparql/?query=PREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0APREFIX%20ex%3A%20%3Chttp%3A%2F%2Fexample.org%2F%3E%0ASELECT%20%3Fname%20%3Fperson%0AWHERE%20%7B%20%3C%3C%28%20_%3Aa%20foaf%3Aname%20%3Fname%20%29%3E%3E%20ex%3AstatedBy%20%3Fperson%20.%20%7D&version=1.2
Host: www.example
User-agent: sparql-client/0.1
HTTP/1.1 200 OK
Date: Wed, 03 Aug 2005 12:48:25 GMT
Server: Apache/1.3.29 (Unix)
Connection: close
Content-Type: application/sparql-results+xml
<?xml version="1.0"?>
<sparql xmlns="http://www.w3.org/2005/sparql-results#">
...
</sparql>
3.1.15
직접 POST를 사용하는 1.2 질의 및 1.2 응답의 SELECT
아래 질의는 isTRIPLE 함수를 사용합니다. 이것은 SPARQL 1.2 기능이므로,
구문적으로 버전을 공지합니다.
VERSION "1.2"
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX ex: <http://example.org/>
SELECT ?statement ?person
WHERE { ?statement ex:statedBy ?person . FILTER (isTRIPLE(?statement)) }
질의가 구문적으로 버전을 공지하지만, SPARQL 클라이언트는
version=1.2 미디어 유형을 사용하여 직접
POST 요청을 보내기로 결정합니다. 버전이 이미 구문적으로 공지된 경우 이는 허용되지만 필수는 아닙니다.
이는 이 HTTP 추적에 보입니다.
업데이트 요청은 Content-Type이
application/sparql-update인 POST 요청으로 전송할 수 있습니다.
POST /test HTTP/1.1
Host: localhost:8888
Accept: */*
Content-Type: application/sparql-update
Content-Length: 27
INSERT DATA { <a> <p> <b> }
3.2.3
데이터셋을 지정하고 POST 직접 전송을 사용하는 UPDATE
업데이트 요청의 데이터셋은 using-graph-uri 및
using-named-graph-uri 매개변수를 사용하여 지정할 수 있습니다.
아래에는 http://localhost:8888/test로 전송되고 기본 그래프
http://localhost:8888/people이 있는 데이터셋을 지정하는 예제 요청의 직렬화가
표시되어 있습니다.
URL 인코딩 매개변수로 업데이트 요청을 POST할 때, 데이터셋 매개변수
using-graph-uri 및 using-named-graph-uri는
직렬화된 요청과 함께 POST 본문에 지정됩니다.
아래에는 다음 질의를 위해
http://localhost:8888/test로 전송된 예제 요청의 직렬화가
http://localhost:8888/test로 전송되고 명명된 그래프
http://localhost:8888/alice/foaf.rdf
및 http://localhost:8888/eve/foaf.rdf가 있는 데이터셋을 지정하는
예제 요청의 직렬화가 아래에 표시되어 있습니다.
SPARQL 프로토콜 서비스에 대한 서비스 거부 공격의 가능한 출처는 적어도 두 가지가 있습니다.
첫째, 제약이 부족한 질의는 매우 많은 수의 결과를 낳을 수 있으며, 이를
처리, 조립 또는 반환하는 데 많은 컴퓨팅 자원이 필요할 수 있습니다. 또 다른 가능한
출처는 자원 크기, 가져와야 하는 자원의 수 또는 크기와 수의 조합 때문에
매우 복잡한 RDF 데이터셋 설명을 포함하는 질의입니다. 서비스는 이러한 설명을
대역폭, CPU 또는 보조 저장장치를 포함한 상당한 자원 지출 없이 조립하지 못할 수
있습니다. 어떤 경우에는 그러한 지출이 실질적으로 서비스 거부 공격을 구성할 수
있습니다. SPARQL 프로토콜 서비스는 자신이 가져오는 자원 또는 외부 자원이
가져와지는 속도에 제한을 둘 수 있습니다. SPARQL 질의
처리 서비스에 대한 서비스 거부 공격의 다른 출처도 있을 수 있습니다.
SPARQL 프로토콜 서비스는 클라이언트를 대신하여 다른 출처 서버에 HTTP 요청을 보낼 수 있으므로,
다른 사이트나 서비스에 대한 공격 벡터로 사용될 수 있습니다. 따라서 SPARQL
프로토콜 서비스는 사실상 제3자 클라이언트를 위한 프록시처럼 동작할 수 있습니다. 이러한 서비스는
자신이 가져오는 자원 또는 외부 자원이 가져와질 수 있는 속도에 제한을 둘
수 있습니다. SPARQL 프로토콜 서비스는 제3자 출처 서버 또는
서비스와 관련하여 추적을 용이하게 하는 방식으로 클라이언트 요청을 기록할
수 있습니다.
SPARQL 프로토콜 서비스는 이러한 질의와 그 밖의 비용이 크거나, 또는 달리
안전하지 않은 질의를 탐지하고, 질의에 시간 또는 메모리 제한을 부과하거나, 서비스(및 다른 서비스)의
서비스 거부 공격에 대한 취약성을 줄이기 위해 다른 제한을 부과하도록 선택할 수 있습니다. 또한
그러한 질의 요청의 처리를 거부할
수 있습니다.
SPARQL 프로토콜 서비스는 업데이트 작업을 통해 기반 데이터를 제거, 삽입 및 변경할 수 있습니다.
악의적이거나 파괴적인 업데이트로부터 보호하기 위해, 구현은
업데이트 작업을 구현하지 않도록 선택할 수 있습니다. 또는 구현은 업데이트 작업의 무단 호출을
방지하기 위해 HTTP 인증 메커니즘이나 다른 구현 정의 메커니즘을 사용하도록 선택할 수 있습니다.
서로 다른 IRI가 동일한 외형을 가질 수 있습니다. 서로 다른 문자 체계의 문자는 비슷해 보일 수
있습니다(키릴 문자 "о"는 라틴 문자 "o"와 비슷해 보일 수 있음). 결합
문자가 뒤따르는 문자는 다른 문자와 동일한 시각적 표현을 가질 수 있습니다(LATIN SMALL LETTER E 뒤에
COMBINING ACUTE ACCENT가 오는 경우 LATIN SMALL LETTER E
WITH ACUTE와 동일한 시각적 표현을 가짐). SPARQL 사용자는 데이터의 IRI와 일치하는 IRI로
질의를 구성하도록 주의해야 합니다. 유사한 문자의 매칭에 대한 자세한 정보는 Unicode
보안 고려사항
및 국제화된 자원 식별자
(IRI) 8절에서 찾을 수 있습니다.
5. 적합성
비규범으로 표시된 절뿐 아니라, 이 명세의 모든 작성 지침, 도표, 예제 및 참고는
비규범입니다. 이 명세의 그 밖의 모든 것은 규범입니다.
이 문서의 핵심 단어 MAY는
여기에 보인 것처럼 모두
대문자로 나타날 때, 그리고 그때에만
BCP 14
[RFC2119] [RFC8174]에
설명된 대로 해석해야 합니다.
5.1 적합성
SPARQL 1.2 프로토콜(이 문서)의 각 부분 상태는 다음과 같습니다.
1절 소개: 규범
2절 SPARQL 프로토콜 작업: 규범
3절: SPARQL 프로토콜 요청 예: 정보 제공
4절: 정책 고려사항: 규범
5절: 적합성: 규범
6절: 이전 권고안 이후의 변경 사항: 정보 제공
A.1절: 규범적 참고 문헌: 규범
A.2절: 기타 참고 문헌: 정보 제공
적합한 SPARQL 프로토콜
서비스는 다음을 만족합니다.
이 문서("SPARQL 1.2 프로토콜")에 설명된 방식으로 query 작업 또는
update 작업 중 하나를 구현해야 합니다.