기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Neptune에 적용되는 SPARQL 표준 규정 준수 다음 섹션에서는 적용 가능한 SPARQL 표준을 나열한 후 Neptune의 SPARQL 구현이 해당 표준에서 확장되거나 변경된 방식에 대한 구체적인 세부 정보를 제공합니다. **Topics** + [SPARQL에 적용 가능한 표준](#feature-sparql-applicable-standards) + [Neptune SPARQL의 기본 네임스페이스 접두사](#sparql-default-prefixes) + [SPARQL 기본 그래프 및 이름이 부여된 그래프](#sparql-default-graph) + [Neptune에서 지원되는 SPARQL XPath 생성자 함수](#access-graph-sparql-xpath-constructors) + [쿼리 및 업데이트를 위한 기본 IRI](#opencypher-compliance-default-iri) + [Neptune의 xsd:dateTime 값](#access-graph-sparql-xsd-date-time) + [Neptune의 특수 부동 소수점 값 처리](#feature-overview-special-values-comparisons) + [Neptune 임의 길이 값의 제한 사항](#feature-overview-arbitrary-length-values) + [Neptune, SPARQL에서 Equals 비교 확장](#feature-overview-sparql-not-equal) + [Neptune SPARQL에서 범위를 벗어난 리터럴 처리](#feature-overview-sparql-out-of-range) Amazon Neptune은 SPARQL 그래프 쿼리 언어를 구현할 때 다음 표준을 준수합니다. ## SPARQL에 적용 가능한 표준 + SPARQL은 2013년 3월 21일의 W3C [SPARQL 1.1 쿼리 언어](https://www.w3.org/TR/sparql11-query/) 권장 사항에 의해 정의됩니다. + SPARQL 업데이트 프로토콜 및 쿼리 언어는 W3C [SPARQL 1.1 업데이트](https://www.w3.org/TR/sparql11-update/) 사양에 의해 정의됩니다. + 숫자 형식의 경우 SPARQL은 [W3C XML 스키마 정의 언어(XSD) 1.1 파트 2: 데이터 형식](https://www.w3.org/TR/xmlschema11-2/) 사양을 따릅니다. 이는 IEEE 754 사양([IEEE 754-2019 - 부동 소수점 산술에 대한 IEEE 표준](https://standards.ieee.org/content/ieee-standards/en/standard/754-2019.html). 자세한 내용은 [Wikipedia IEEE 754 페이지](https://en.wikipedia.org/wiki/IEEE_754) 참조)과 일치합니다. 그러나 `IEEE 754-1985` 버전 이후에 도입된 기능은 사양에 포함되지 않습니다. ## Neptune SPARQL의 기본 네임스페이스 접두사 Neptune은 기본적으로 SPARQL 쿼리에 사용할 다음 접두사를 정의합니다. 자세한 내용은 SPARQL 사양의 [접두사가 추가된 이름](https://www.w3.org/TR/sparql11-query/#prefNames)을 참조하십시오. + `rdf`  – `http://www.w3.org/1999/02/22-rdf-syntax-ns#` + `rdfs` – `http://www.w3.org/2000/01/rdf-schema#` + `owl`  – `http://www.w3.org/2002/07/owl#` + `xsd`  – `http://www.w3.org/2001/XMLSchema#` ## SPARQL 기본 그래프 및 이름이 부여된 그래프 Amazon Neptune은 트리플마다 이름이 있는 그래프를 연결합니다. 기본 그래프는 이름이 있는 모든 그래프의 조합으로 정의됩니다. **쿼리에 대한 기본 그래프** `FROM NAMED`와 같은 `GRAPH` 키워드 또는 구문을 통해 그래프를 명시적으로 지정하지 않고 SPARQL 쿼리를 제출하는 경우 Neptune은 항상 DB 인스턴스의 모든 트리플을 고려합니다. 예를 들어 다음 쿼리는 Neptune SPARQL 엔드포인트의 모든 트리플을 반환합니다. `SELECT * WHERE { ?s ?p ?o }` 1개 이상의 그래프에 나타나는 triples는 한 번만 반환합니다. 기본 그래프 사양에 대한 사항은 SPARQL 1.1 쿼리 언어 사양의 [RDF 데이터 세트](https://www.w3.org/TR/sparql11-query/#rdfDataset)를 참조하십시오. **로드, 삽입 또는 업데이트에 대한 이름이 있는 그래프 지정** 트리플을 로드, 삽입 또는 업데이트할 때 이름이 있는 그래프를 지정하지 않으면 Neptune에서 URI `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`로 정의된 이름이 있는 대체 그래프를 사용합니다. 트리플 기반 형식을 사용하여 Neptune `Load` 요청을 발행하면 `parserConfiguration: namedGraphUri` 파라미터를 사용하여 모든 트리플에 사용할 이름이 있는 그래프를 지정할 수 있습니다. `Load` 명령 구문에 대한 사항은 [Neptune 로더 명령](load-api-reference-load.md) 단원을 참조하십시오. **중요** 이 파라미터를 사용하지 않고 이름이 있는 그래프를 지정하지 않으면 대체 URL `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`을 사용합니다. 이름이 있는 그래프 대상을 명시적으로 제공하지 않고 `SPARQL UPDATE`를 통해 트리플을 로드하는 경우에도 이 이름이 있는 대체 그래프를 사용합니다. 쿼드 기반 형식 N-Quads를 사용하여 데이터베이스의 트리플마다 이름이 있는 그래프를 지정할 수 있습니다. **참고** N-Quads를 사용하면 이름이 있는 그래프를 비워 둘 수 있습니다. 이 경우 `http://aws.amazon.com/neptune/vocab/v01/DefaultNamedGraph`를 사용합니다. `namedGraphUri` 파서 구성 옵션을 사용하여 N-Quads의 이름이 있는 기본 그래프를 재정의할 수 있습니다. ## Neptune에서 지원되는 SPARQL XPath 생성자 함수 SPARQL 표준을 사용하면 SPARQL 엔진이 확장 가능한 XPath 생성자 함수 세트를 지원할 수 있습니다. Neptune은 현재 다음과 같은 생성자 함수를 지원합니다. 여기서 `xsd` 접두사는 `http://www.w3.org/2001/XMLSchema#`로 정의됩니다. + `xsd:boolean` + `xsd:integer` + `xsd:double` + `xsd:float` + `xsd:decimal` + `xsd:long` + `xsd:unsignedLong` ## 쿼리 및 업데이트를 위한 기본 IRI Neptune 클러스터에는 여러 엔드포인트가 있기 때문에 쿼리 또는 업데이트의 요청 URL을 기본 IRI로 사용하면 상대 IRI를 확인할 때 예상치 못한 결과가 발생할 수 있습니다. [엔진 릴리스 1.2.1.0](engine-releases-1.2.1.0.md)부터 Neptune은 명시적 기본 IRI가 요청의 일부가 아닌 경우 기본 IRI로 `http://aws.amazon.com/neptune/default/`를 사용합니다. 다음 요청에서는 기본 IRI가 요청의 일부입니다. ``` BASE INSERT DATA { "n1" } BASE SELECT * { ?p ?o } ``` 결과는 다음과 같습니다. ``` ?p ?o http://example.org/default/id n1 ``` 그러나 이 요청에는 기본 IRI가 포함되지 않습니다. ``` INSERT DATA { "n1" } SELECT * { ?p ?o } ``` 이 경우 결과는 다음과 같습니다. ``` ?p ?o http://aws.amazon.com/neptune/default/id n1 ``` ## Neptune의 xsd:dateTime 값 성능상의 이유로 Neptune에서는 항상 날짜/시간 값을 협정 세계시(UTC)로 저장합니다. 이렇게 하면 직접 비교가 매우 효율적으로 수행됩니다. 또한 특정 시간대를 지정하는 `dateTime` 값을 입력하면 Neptune에서는 값을 UTC로 변환하고 해당 시간대 정보를 버립니다. 그런 다음, 나중에 `dateTime` 값을 검색하면 이 값은 원래 시간대의 시간이 아닌 UTC로 표시되며 원래 시간대가 무엇인지 더 이상 알 수 없습니다. ## Neptune의 특수 부동 소수점 값 처리 Neptune은 다음과 같이 SPARQL에서 특수 부동 소수점 값을 처리합니다. ### Neptune의 SPARQL NaN 처리 Neptune에서 SPARQL은 쿼리에 `NaN` 값을 사용할 수 있습니다. 신호와 quiet `NaN` 값 사이에는 구별이 없습니다. Neptune은 모든 `NaN` 값을 quiet로 취급합니다. 의미상 `NaN`보다 크거나 작거나 같은 값은 없으므로 `NaN`을 비교할 수 없습니다. 즉, 이론적으로 비교의 한 쪽에 있는 `NaN` 값은 다른 쪽의 *어느 값*과도 일치하지 않습니다. 하지만 [XSD 사양](https://www.w3.org/TR/xmlschema-2/#double)에서는 두 `xsd:double` 또는 `xsd:float` `NaN` 값을 같은 것으로 취급합니다. 이 사양은 Neptune에서 `IN` 필터, 필터 표현식의 등호 연산자 및 정확한 일치 시맨틱(삼중 패턴의 객체 위치에 `NaN`이 있음)에도 적용됩니다. ### Neptune의 SPARQL 무한 값 처리 Neptune에서 SPARQL은 쿼리에 `INF` 또는 `-INF` 값을 사용할 수 있습니다. `INF`는 다른 숫자 값보다 큰 값을 비교하고 `-INF`는 다른 숫자 값보다 작은 값을 비교합니다. 일치하는 부호가 있는 두 INF 값은 형식에 관계없이 서로 동등하게 비교합니다(예: 부동 `-INF`를 이중 `-INF`와 동등하게 비교). `NaN`보다 크거나 작거나 같은 값은 없으므로 `NaN`과 비교할 수 없습니다. ### Neptune의 SPARQL Negative Zero 처리 Neptune은 음수 0 값을 부호 없는 0으로 정규화합니다. 음수 0 값은 쿼리에 사용할 수 있지만 데이터베이스에 기록되지 않으며 부호 없는 0과 동일하게 비교합니다. ## Neptune 임의 길이 값의 제한 사항 Neptune은 SPARQL의 XSD 정수, 부동 소수점 및 10진수 값의 저장 크기를 64비트로 제한합니다. 더 큰 값을 사용하면 `InvalidNumericDataException` 오류가 발생합니다. ## Neptune, SPARQL에서 Equals 비교 확장 SPARQL 표준은 값 표현식에 대한 3진 논리를 정의합니다. 여기서 값 표현식은 `true`, `false` 또는 `error`로 평가할 수 있습니다. [SPARQL 1.1 사양](https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal)에 정의된 용어 동일성에 대한 기본 시맨틱은 `FILTER` 조건의 `=` 및 `!=` 비교에 적용되며, 사양의 [연산자 테이블](https://www.w3.org/TR/sparql11-query/#OperatorMapping)에서 명시적으로 비교할 수 없는 데이터 유형을 비교할 때 `error`가 발생합니다. 이 동작은 다음 예제와 같이 직관적이지 않은 결과를 초래할 수 있습니다. 데이터: ``` "127.0.0.1"^^ ``` 쿼리 1: ``` SELECT * WHERE { ?o . FILTER(?o = "127.0.0.2"^^) } ``` 쿼리 2: ``` SELECT * WHERE { ?o . FILTER(?o != "127.0.0.2"^^) } ``` 릴리스 1.0.2.1 이전에 Neptune에서 사용한 기본 SPARQL 시맨틱을 사용하면 두 쿼리 모두 빈 결과를 반환합니다. 그 이유는 사용자 지정 데이터 형식 ``에 대해 지정된 명시적 비교 규칙이 없으므로 `?o := "127.0.0.1"^^`에 대해 평가할 때 `?o = "127.0.0.2"^^`는 `false`가 아니라 `error`를 생성하기 때문입니다. 결과적으로 두 번째 쿼리의 부정 버전도 `error`를 생성합니다. 두 쿼리 모두에서 `error`는 후보 솔루션이 필터링되도록 합니다. 릴리스 1.0.2.1부터 Neptune은 사양에 따라 SPARQL 부등식 연산자를 확장했습니다. 엔진이 사용자 정의 및 비교 불가 내장 데이터 형식 간에 비교하는 방법에 대한 추가 규칙을 정의할 수 있는 연산자 확장성에 대한 [SPARQL 1.1](https://www.w3.org/TR/sparql11-query/#operatorExtensibility) 단원을 참조하십시오. 이 옵션을 사용하면 Neptune은 리터럴 값과 데이터 형식이 구문적으로 같은 경우 연산자 매핑 표에 명시적으로 정의되지 않은 두 데이터 형식의 비교를 `true`로 평가하고 그렇지 않으면 false로 평가합니다. `error`는 어떤 경우에도 생성되지 않습니다. 이러한 새로운 시맨틱을 사용하면 두 번째 쿼리가 빈 결과 대신 `"127.0.0.1"^^`를 반환합니다. ## Neptune SPARQL에서 범위를 벗어난 리터럴 처리 XSD 시맨틱은 `integer` 및 `decimal`을 제외한 각 숫자 형식을 해당 값 범위를 이용해 정의합니다. 이러한 정의는 각 형식을 값 범위로 제한합니다. 예를 들어 `xsd:byte` 범위의 범위는 -128에서 \+127까지(경계값 포함)입니다. 이 범위를 벗어나는 모든 값은 유효하지 않은 것으로 간주됩니다. 형식의 값 범위를 벗어나는 리터럴 값을 할당하려고 시도(예: `xsd:byte`를 리터럴 값 999로 설정하려는 경우)하면 Neptune은 반올림하거나 자르지 않고 범위를 벗어난 값을 그대로 사용합니다. 하지만 해당 형식은 리터럴 값을 나타낼 수 없기 때문에 숫자 값으로 유지되지 않습니다. 즉, 정의된 `xsd:byte` 값 범위를 벗어나는 값이라도 Neptune은 `"999"^^xsd:byte`를 사용합니다. 하지만 데이터베이스에 이러한 값이 유지되면 삼중 패턴의 객체 위치에서 정확한 일치 시맨틱에서만 사용할 수 있습니다. 범위를 벗어난 리터럴은 숫자 값으로 취급되지 않기 때문에 범위 필터를 실행할 수 없습니다. SPARQL 1.1 사양에서는 [범위 연산자](https://www.w3.org/TR/sparql11-query/#OperatorMapping)를 `numeric`*-operator-*`numeric`, `string`*-operator-*`string`, `literal`*-operator-*`literal` 등의 형태로 정의합니다. Neptune은 `invalid-literal`*-operator-*`numeric-value`와 같은 범위 비교 연산자를 실행할 수 없습니다.