왜 TopBraid Composer FE는 다중 OR 조건을 SPIN 규칙 필터로 다시 그룹화 했습니까?

Question

저는 TopBraid Composer Free Edition (TBC FE) 버전 5.1.3을 사용하고 있습니다. SPIN 규칙/CONSTRUCT 쿼리를 작성하고 있습니다. 쿼리의 일부에 여러 OR 조건이있는 FILTER 문이 있습니다. 내가 TBC FE의 SPIN 규칙을 저장할 때, 이진 세트가되도록 논리합 조건을 재편성 또는의,

FILTER (
(?orgString = SUBSTR("AF X"^^xsd:string, 1, 4)) || 
(?orgString = SUBSTR("J X"^^xsd:string, 1, 4)) || 
(?orgString = SUBSTR("AR X"^^xsd:string, 1, 4)) || 
(?orgString = SUBSTR("N X"^^xsd:string, 1, 4)) || 
(?orgString = SUBSTR("NS X"^^xsd:string, 1, 4)) || 
(?orgString = SUBSTR("MC X"^^xsd:string, 1, 4)) 
) . 

을 :하지만

FILTER (
(((((?orgString = SUBSTR("AF X"^^xsd:string, 1, 4)) || 
    (?orgString = SUBSTR("J X"^^xsd:string, 1, 4))) || 
    (?orgString = SUBSTR("AR X"^^xsd:string, 1, 4))) || 
    (?orgString = SUBSTR("N X"^^xsd:string, 1, 4))) || 
    (?orgString = SUBSTR("NS X"^^xsd:string, 1, 4))) || 
    (?orgString = SUBSTR("MC X"^^xsd:string, 1, 4)) 
) . 

나는 다음과 같이 TBC FE에 입력 내 질문은 : 재편성하는 이유는 무엇입니까? 나는이 재 그룹화를하지 않은 다른 SPARQL 편집기와 끝점을 사용했습니다. 나는 이것이 내 코드를 (비용) 읽는 것을 더 어렵게 만든다고 주장한다. 그래서 나는 그 이익이 무엇인지 궁금하다.

또한 재 그룹화가 필요하지 않은 경우 TBC FE에서 해제 할 수 있습니까?

감사합니다.

추 신 : 그렇습니다. 리터럴 문자열의 하위 문자열을 가져 오는 것이 어리석은 것처럼 보입니다. 참깨에서 TBF FE로 저장 한 내 RDF 파일을로드 할 때 내 리터럴 문자열을 잘라내는 Sesame 버그를 피하기 위해이 작업을하고 있습니다. 버그가보고되었으며 해결되었습니다. 문제가 해결되면 참깨 버전을 업그레이드하고 이러한 추한 부분 문자열을 제거합니다.

Answer 1

Jena가 쿼리하는 방식으로 TBC FE가 아닙니다. 왼쪽 연관에있는 이진 연산자의 경우 파서는 식 트리 ((E1 op E2)에서 E3으로)를 만들고이를 인쇄합니다. 그것은 간단하고 안전합니다; 표현식을 인쇄하는 것이 우선시되지 않습니다.

쓸 수있는 다른 방법 당신의 FILTER 어떤 도움이됩니다 경우

?orgString IN (SUBSTR("AF X", 1, 4), SUBSTR("J X", 1, 4), ...) 

입니다.