anchor.diff:  strategyA = PartitionStrategy.build().partitionKey("_partition").writePartition("a").addReadPartition("a").create()
   strategyB = PartitionStrategy.build().partitionKey("_partition").writePartition("b").addReadPartition("b").create()
   gA = GraphTraversalSource.build().with(strategyA).create(graph)
  -gA.addV() //// this vertex has a property of {_partition:"a"}
  +gA.addV() // this vertex has a property of {_partition:"a"}
   gB = GraphTraversalSource.build().with(strategyB).create(graph)
  -gB.addV() //// this vertex has a property of {_partition:"b"}
  +gB.addV() // this vertex has a property of {_partition:"b"}
   gA.V()
   gB.V()
   ----
  
positive.code: TinkerPop has a number of type-3 strategies distributed as part of its core library.  These strategies add generalized features to a traversal that are typically useful to end-users.  The following sections detail these strategies:
  
  ElementIdStrategy
  =================
  
  `ElementIdStrategy` provides control over element identifiers. Some Graph implementations, such as TinkerGraph, allow specification of custom identifiers when creating elements:
  
  
negative.code: By writing elements to particular partitions and then restricting read partitions, the developer is able to create multiple graphs within a single address space. Moreover, by supporting references between partitions, it is possible to merge those multiple graphs (i.e. join partitions).
  
  ReadOnlyStrategy
  ~~~~~~~~~~~~~~~~
  
  `ReadOnlyStrategy` is largely self-explanatory.  A `Traversal` that has this strategy applied will throw an `IllegalStateException` if the `Traversal` has any mutating steps within it.
  
  SubgraphStrategy
  ~~~~~~~~~~~~~~~~
  
  `SubgraphStrategy` is quite similar to `PartitionStrategy` in that it restrains a `Traversal` to certain vertices and edges as determined by a `Predicate` defined individually for each.
  
  