Virtuoso, Stardog, 4store, Allegrograph, Oracle11g와 같은 트리플 스토어에서 문장을 삽입하고 삭제하는 것과 관련된 질문이 있습니다.트리플 스토어에 문장 삽입하기
새 문을 삽입 할 때 저장소에 유추 된 문을 삽입합니까? 아니면 모든 쿼리 실행시 추론 된 문을 얻기 위해 추론자가 사용됩니까? 문을 제거 할 때와 같은 질문이 유추 된 문을 제거합니까?
Virtuoso, Stardog, 4store, Allegrograph, Oracle11g와 같은 트리플 스토어에서 문장을 삽입하고 삭제하는 것과 관련된 질문이 있습니다.트리플 스토어에 문장 삽입하기
새 문을 삽입 할 때 저장소에 유추 된 문을 삽입합니까? 아니면 모든 쿼리 실행시 추론 된 문을 얻기 위해 추론자가 사용됩니까? 문을 제거 할 때와 같은 질문이 유추 된 문을 제거합니까?
그 대답은 데이터베이스에 따라 다르기 때문에 "올바른"방법은 없으며, 내가 아는 한 각각의 방식이 조금 다릅니다. 그리고 쿼리 시간 추론을 구체화하거나 수행해야 할 이유가 없습니다. 당신은 두 가지 중 일부를 할 수 있으며, 무엇이라도한다면 그것을 구현하는 "올바른"방법입니다.
구체화가 사용되는 경우 (모든 추론이 데이터베이스에 저장 됨) 진리 유지 관리는 특히 까다로운 문제입니다. 모두 추론을 피할 수 있지만 그 접근에는 몇 가지 명백한 단점이 있습니다. 따라서 시스템은 구체화 된 체계를 가지게되어 추론을위한 파생 트리가 저장되어 업데이트로 인해 영향을받는 추론 만 다시 계산됩니다. 그러나 이것은 모든 쓰기 및 대량로드 속도를 저하시키는 비용입니다.
쿼리 타임 추론 또한 진리 유지 관리의 문제를 해결합니다. 추론은 저장되는 것이 아니라 평가하는 동안 즉석에서 계산되지만, 이는 더 어려운 쿼리를 실행하는 대가로 발생합니다.
BigData, OWLIM, 오라클, 내가 추론 할 때 알고있는 Stardog는 쿼리시 모든 추론을 수행합니다. Virtuoso와 AllegroGraph에 대해서는 잘 모르겠습니다. AllegroGraph가 RacerPro를 사용했거나 최소한 사용해 왔다고 가정 할 때, 나는 그것이 실현되었다고 추측 할 수 있습니다. 그러나 그것은 단지 추측입니다. 나는 4Store가 어떤 추론을했는지는 몰랐다.
materialization을 유지한다고해서 반드시 파생 트리를 저장해야한다는 의미는 아닙니다. 동의하지 않으면 +1. AllegroGraph는 쿼리 다시 쓰기와 구체화를 결합한다고 생각하지만 완전히 확신 할 수는 없습니다. –