The primitive is only "object". Edges are not any more special than other "special" objects like accounts, assets, auctions, sites, etc - they just have some extra validation.
Looking through the code I see there is a clear distinction between an actual edge (in the graph sense) implemented with bts::blockchain::edge_record type, which has from and to fields, and the concept of the edge_object discussed in this thread and in bytemaster's blog post, implemented with the bts::blockchain:object_record type, which has the actual data and the _owners field or a pointer to use the _owners of another object (which I presume points to the source node of the "edge").
My question is if in the original graph example I gave in this thread the E1 "edge" would be represented as object_record with obj_type == edge_object and two edge_records (one from N1 to E1 and the other from E1 to N2), or would there be a single edge_record going from N1 to N2 that somehow gets associated with an object_record with obj_type == edge_object.
If it is the former, can we just use regular graph terminology and call the "edges" in the BitShares Object Graph special vertices (perhaps named edge_objects). In which case, the actual edges (in graph terminology) would have no information associated with them other than the from and to fields (no weights for example). It would also not make any sense to have these edges go directly from a vertex where obj_type != edge_object to a vertex where obj_type != edge_object. The edge_objects would be special from all other vertices in the graph in the sense that they have particular validation semantics and can only have one outgoing edge (assuming you guys decide to not allow an "edge" be the source of an "edge" as bytemaster suggested because of the non-constant time validation consequence).
Or you know, stop trying to make edges point to other edges (unless there is a good reason for this feature), and build the graph database the traditional way...