code could be written to manage all of this manually, but its much better if the platform takes care of it.[The astute reader will notice that the plain Java example has one advantage: it provides type safety. I'll have to say more about this in an upcoming post about types.]So: after working with graph databases for a while, many people believe that edges are actually the much more interesting and useful concept than nodes. Just like many data modelers think that the value of a data model is often more in the way the entities are connected by relationships than the details of the entities. Automatic management of relationships make things simple, and thats what any good database should do. Developers have enough to worry about, and graph databases provide real help here. Operations on a Graph Database (Part 3 - Types)We need to talk about properties, but before we can do that, we need to talk about types. In a previous post we looked at the various alternatives for typing and their pros and cons. Graph databases may take the two following approaches to typing, and anything in between: No types at all: nodes, edges and properties have no types; anything goes. Fully typed: nodes, edges and properties are all strongly typed; the graph database refuses to perform an operation that is not consistent with the type system. There are some graph databases on the market that require types for some elements (edges, for example) but dont allow types for others (nodes, or properties), so hybrids are possible.A totally untyped graph database has it easy: it allows an arbitrary number of properties, distinguished only by name and with arbitrary values. So the operations are:Defined on Node and/or Edge:setProperty( String label, Object value ); // returns nothinggetProperty( String label ); // returns the valuegetAllProperties(); // returns a set of all current property labelsA fully typed graph database needs to offer a much larger set of operations. They are:Defined on Node:bless( NodeType type ); // returns nothingunbless( NodeType type ); // returns nothinggetTypes(); // returns a set of all current NodeTypessetProperty( PropertyType type, Object value ); // returns nothinggetProperty( PropertyType type ); // returns the value of the PropertyDefined on Edge:bless( EdgeType type ); // returns nothingunbless( EdgeType type ); // returns nothinggetTypes(); // returns a set of all current EdgeTypessetProperty( PropertyType type, Object value ); // returns nothinggetProperty( PropertyType type ); // returns the value of the PropertyTo determine the available properties, one examines the meta-data available in the type system:Defined on NodeType and on EdgeTypegetPropertyTypes(); // returns a set of all possible properties defined by the typeThe abstract API Im listing here is the general case for a fully dynamically-typed hypothetical graph database. No product that Im aware of implements them all, but InfoGrid comes close. If you read the JavaDoc for MeshObject, for example (MeshObject is InfoGrids name for Node), you will find all of the above Node operations. The operations are also there for Relationships (InfoGrids name for Edge) except that for efficiency reasons 1) they are defined on