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 TripleStore
public void add(Triple t)
add
in interface TripleStore
public void delete(Triple t)
delete
in interface TripleStore
public void clear()
clear
in interface TripleStore
public int size()
size
in interface TripleStore
public boolean isEmpty()
isEmpty
in interface TripleStore
public ExtendedIterator<Node> listSubjects()
TripleStore
listSubjects
in interface TripleStore
public ExtendedIterator<Node> listPredicates()
TripleStore
listPredicates
in interface TripleStore
public ExtendedIterator<Node> listObjects()
TripleStore
listObjects
in interface TripleStore
public boolean contains(Triple t)
t
.contains
in interface TripleStore
public 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 TripleStore
Licenced under the Apache License, Version 2.0