Module org.apache.jena.core
Package org.apache.jena.mem

Class GraphTripleStoreBase

java.lang.Object
org.apache.jena.mem.GraphTripleStoreBase
All Implemented Interfaces:
TripleStore
Direct Known Subclasses:
GraphTripleStoreMem
public abstract class GraphTripleStoreBase extends Object implements TripleStore

  • Method Details

    • close

      public void close()
      Destroy this triple store - discard the indexes.
      Specified by:
      close in interface TripleStore

    • add

      public void add(Triple t)
      Add a triple to this triple store.
      Specified by:
      add in interface TripleStore

    • delete

      public void delete(Triple t)
      Remove a triple from this triple store.
      Specified by:
      delete in interface TripleStore

    • clear

      public void clear()
      Clear this store, ie remove all triples from it.
      Specified by:
      clear in interface TripleStore

    • size

      public int size()
      Answer the size (number of triples) of this triple store.
      Specified by:
      size in interface TripleStore

    • isEmpty

      public boolean isEmpty()
      Answer true iff this triple store is empty.
      Specified by:
      isEmpty in interface TripleStore

    • listSubjects

      public ExtendedIterator<Node> listSubjects()
      Description copied from interface: TripleStore
      Answer an setwise iterator over all the subjects of triples in this store.
      Specified by:
      listSubjects in interface TripleStore

    • listPredicates

      public ExtendedIterator<Node> listPredicates()
      Description copied from interface: TripleStore
      Answer an iterator over all the predicates of triples in this store.
      Specified by:
      listPredicates in interface TripleStore

    • listObjects

      public ExtendedIterator<Node> listObjects()
      Description copied from interface: TripleStore
      Answer an setwise iterator over all the objects of triples in this store.
      Specified by:
      listObjects in interface TripleStore

    • contains

      public boolean contains(Triple t)
      Answer true iff this triple store contains the (concrete) triple t.
      Specified by:
      contains in interface TripleStore

    • containsMatch

      public boolean containsMatch(Triple t)
      Description copied from interface: TripleStore
      Answer true iff this triple store contains the triple match t.
      Specified by:
      containsMatch in interface TripleStore

    • find

      public ExtendedIterator<Triple> find(Triple t)
      Answer an ExtendedIterator returning all the triples from this store that match the pattern 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.

      Specified by:
      find in interface TripleStore

    • stream

      public Stream<Triple> stream(Node sm, Node pm, Node om)
      Answer a Stream returning all the triples from this store that match the pattern 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.

      Specified by:
      stream in interface TripleStore