public abstract class GraphTripleStoreBase extends Object implements TripleStore
| Modifier and Type | Method and Description |
|---|---|
void |
add(Triple t)
Add a triple to this triple store.
|
void |
clear()
Clear this store, ie remove all triples from it.
|
void |
close()
Destroy this triple store - discard the indexes.
|
boolean |
contains(Triple t)
Answer true iff this triple store contains the (concrete) triple
t. |
boolean |
containsByEquality(Triple t) |
void |
delete(Triple t)
Remove a triple from this triple store.
|
ExtendedIterator<Triple> |
find(Triple t)
Answer an ExtendedIterator returning all the triples from this store that
match the pattern
m = (S, P, O). |
boolean |
isEmpty()
Answer true iff this triple store is empty.
|
ExtendedIterator<Node> |
listObjects()
Answer an setwise iterator over all the objects of triples in this store.
|
ExtendedIterator<Node> |
listPredicates()
Answer an iterator over all the predicates of triples in this store.
|
ExtendedIterator<Node> |
listSubjects()
Answer an setwise iterator over all the subjects of triples in this store.
|
int |
size()
Answer the size (number of triples) of this triple store.
|
public void close()
close in interface TripleStorepublic void add(Triple t)
add in interface TripleStorepublic void delete(Triple t)
delete in interface TripleStorepublic void clear()
clear in interface TripleStorepublic int size()
size in interface TripleStorepublic boolean isEmpty()
isEmpty in interface TripleStorepublic ExtendedIterator<Node> listSubjects()
TripleStorelistSubjects in interface TripleStorepublic ExtendedIterator<Node> listPredicates()
TripleStorelistPredicates in interface TripleStorepublic ExtendedIterator<Node> listObjects()
TripleStorelistObjects in interface TripleStorepublic boolean contains(Triple t)
t.contains in interface TripleStorepublic boolean containsByEquality(Triple t)
public ExtendedIterator<Triple> find(Triple t)
m = (S, P, O).
Because the node-to-triples maps index on each of subject, predicate, and (non-literal) object, concrete S/P/O patterns can immediately select an appropriate map. Because the match for literals must be by sameValueAs, not equality, the optimisation is not applied for literals. [This is probably a Bad Thing for strings.]
Practice suggests doing the predicate test last, because there are "usually" many more statements than predicates, so the predicate doesn't cut down the search space very much. By "practice suggests" I mean that when the order went, accidentally, from S/O/P to S/P/O, performance on (ANY, P, O) searches on largish models with few predicates declined dramatically - specifically on the not-galen.owl ontology.
find in interface TripleStoreLicenced under the Apache License, Version 2.0