Question about arcs jackpark 10/25/13 9:52 AM I just read the O'Reilly Graph Database book. Very useful to me. Leaves me with some questions, mostly about the nature of arcs. The root question is this: why are not arcs also nodes? Reason for that is this: I notice in TinkerPop graphs, you can make property graphs; properties are also available inside arcs. So, what's the difference between an arc and any other vertex (node)? Identity? Why not allow an arc to become a vertex when it becomes an actor in some other relation? Consider this triple: {A, cause, B} Here, "cause" is the label of some outbound arc from A linking it to B. The meaning of that *instance* of a "cause" arc is precisely the triple itself. Thus, the "cause" arc in this example carries with it the assertion that someone made, which is that A is the cause of B, whatever A and B are. That causal assertion could be reified in a single node which says that A causes B, and be done with it, but why do that when the arc itself already says that? The assertion has a biography. Certainly, one could encapsulate that biography as a symbolic value in a property on the arc, which must be interpreted to point to some other, say, subgraph. But, at the same time, the assertion might be controversial in the sense that someone would want to link it to another assertion, e.g. {{A,cause,B}, disagreesWith, {A, cause, C}} So, what would it take to modify TinkerPop graphs to allow arcs to serve as simple arcs, or be treated as nodes to augment the way the graph is created/manipulated/interpreted ? Thanks in advance for thoughts. Jack ps: Neo4J's Cypher seems cool, almost as if one could implement Sowa's conceptual graphs with it. Re: Question about arcs Zach Kinstner 10/25/13 10:34 AM If I'm understanding your notes correctly, I've dealt with a similar situation. In my work on Fabric, I created a node type specialized for connecting two other nodes -- I call it a Factor.  It represents, essentially, a very bulked-up edge (arc).The nature of a Factor (F) is to connect nodes A and B, with lots of additional descriptive information about the connection. That could be done simply as an edge. To do other things, like connect F to the member M who created it, F needs to be a node.The basic node/edge structure looks like this (not all of these relationships exist in Fabric yet):[F] --- uses "from" node ---> [A][F] --- uses "to" node --> [B][M] --- creates ---> [F][User] --- agreesWith ---> [F][F] --- inspires ---> [F2]etc...Is that helpful for you?Zach Re: [TinkerPop] Re: Question about arcs jackpark 10/25/13 10:59 AM Hi Zach! Very useful along several dimensions, but uncertain about "Factor", which extends FabVertex, which extends FabObject. Don't see a "FabNode" or its equivalent, but that's another conversation! The whole Fabric concept plays closely to my game which is topic mapping in the service of http://www.knowledgefederation.org/ A topic map is a graph of lots of nodes (topics -- SubjectProxy objects), each of which is its own "frame-like" representation of all that is knowable about some subject 'out there'.  Seems like Fabric has similar motivations. It's fine to learn that "A causes B", but it's quite another thing to represent public outcry over that assertion when that assertion could be controversial (wicked problems come to mind). I need to make that specific assertion its own "topic" (node) in the graph. A vertex-AS-node would do that. So, while a really well-decorated vertex is nice, and apparently I can do that with the TinkerPop suite, I'm interested in taking a vertex to its next level (perhaps wrongly so, but it's what's on my mind for a long time); some vertexes are uncontroversially descriptive, but some represent powerful, possibly controversial claims; they are claims made from world views which are based either on empirical evidence, or hip shots from trolls. Either way, such assertions, in my view, ought to be nodes, first-class citizens in the graph. In my mind, I imagine two interfaces: INode and IVertex, where IVertex extends INode. Many thanks Jack > -- > You received this message because you are subscribed to the Google Groups > "Gremlin-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to gremlin-user...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. Re: [TinkerPop] Re: Question about arcs Zach Kinstner 10/25/13 11:27 AM Hi Jack,Thanks for that link -- I'll have to look into Knowledge Federation.I'm confused by "vertex-AS-node". What do you see as the difference between "vertex" and "node"?Maybe it's just a terminology issue. TinkerPop/Gremlin calls the elements "vertex" (g.addVertex) and "edge" (g.addEdge).Zach Re: [TinkerPop] Question about arcs Pieter Martin 10/25/13 11:41 AM Hi, In UML this is realized with an AssociationClass. Basically an association that is also a class. In my project I implemented this by creating a separate vertex to represent the class part of the association. Its probably going to bite me some day but for now I simply store the id of the association class's vertex on the edge that represents the association. So Person(vertex)--position(edge)--Company(vertex) the job edge stores the vertex id of Job(vertex) All of this is wrapped in java entities making it easier to manage. Person person = new Person(); Company company = new Company(); Job job = new Job(); person.addToPosition(company, job); or person.getPositions().add(company, job); I started extended gremlin (very experimental for now) to make it possible see properties on Job as though they reside on the edge. Cheers Pieter Re: [TinkerPop] Re: Question about arcs jackpark 10/25/13 11:53 AM I looked into the Blueprints code. Element gives us properties including identity. Each extension (Vertex and Edge) must have unique identities. In theory, that makes them addressable. That's useful. But, comparing the interfaces Vertex and Edge, Vertex is different in the sense that it has iterables for edges. Edge doesn't have those. Therefore, an Edge can never be used as a Vertex. I suppose, in that sense, I am asking what happens to the structure if some elements of the Vertex API were moved to Element so they could be shared by Edge. I have a hunch the graph blackbelts will conjure a laundry list of reasons not to do that, but in my own imagination, that's what I would want to try. Re: [TinkerPop] Question about arcs jackpark 10/25/13 11:57 AM Hi Pieter, That sounds like the "reification" mechanism used by some of the early version topic mappers -- Topic maps went through iterations where "associations" were not first-class citizens (topics), but the Topic Maps Reference Model dropped that distinction, so my topic maps implement every node as a topic node, even where it represents the predicate in a triple. I see no reason why that mechanism should "bite" you in the future. Re: [TinkerPop] Question about arcs Pieter Martin 10/25/13 12:49 PM Hi, Afraid I am not familiar with your metaphors. Sounds interesting though. The above is somewhat related to hypergraphs. Don't think tinkerpop have any hypergraph plans. UML supports nary associations, but alas it is rather complex and I do not plan on supporting it. Storing the id has already bitten me a bit. OrientDb allocates a tempory id to a vertex when it is first created. Only on commit does it get assigned its proper id. Unfortunately its to late as I already placed the temp id on the edge. Fortunately they have plans to assign the real id upfront. Further some db's, orientdb and neo4j that I know of, recycle ids which make storing the id anywhere somewhat dangerous. Cheers Pieter Re: [TinkerPop] Question about arcs jackpark 10/25/13 12:58 PM Indeed! The issue of object identifiers is, in my view, a big hairy problem. I prefer to assign my own identifiers, and some of the APIs allow that, except that they ignore what I send in and use their own. That's another topic. I am not talking about hypergraphs, just about simple graphs where the edges can also behave as vertex objects when needed. Re: [TinkerPop] Question about arcs Zach Kinstner 10/25/13 1:37 PM simple graphs where the edges can also behave as vertex objects when needed. In your suggestion, is an edge is a subclass of a vertex, or are they effectively combined into the same thing?  In either case, it seems like an unlikely change. The clear distinction between vertices and edges affects database architectures (I assume -- haven't built one) in a major way, and can improve performance. A database might, for example, store two copies of an edge (one with each associated vertex) to avoid extra look-ups.It seems like the "Factor" approach above should work for you. I'm not sure about Pieter's approach. As he mentioned, it's caused some problems, and to me it feels less "graph-like". Re: [TinkerPop] Question about arcs Pieter Martin 10/26/13 3:14 AM Hi, I don't think a edge is going to also optionally be a vertex anytime soon. With a hypergraph one can model a ternary relationship and pretend that the 3rd vertex in the relationship represents the edge as vertex. My understanding is that in blueprints a ternary relationship would normally be modelled with an extra vertex in the middle. Similar in a way to those many to many relationship tables in rdbms. In my case I opted not to do that as it seemed to be a lot more complex and less efficient, code to write and maintain (3 edges as oppose to 1, and a extra vertex). When the ternary relationship needs to maintain insertian order (list or orderedset semantics) it becomes even more complex with a lot of vertex and edge babysitting. However as Zach says my current solution is not very graph like with that sneaky vertex id stored on the edge. What will be interesting is a hypergraph extension on top of blueprints. Especially if it places no additionaly constraints on the underlying db. I.e. the underlying does not need to support hypergraphs natively. I do not actually know of any blueprints implementation that supports hypergraphs. Cheers Pieter Re: [TinkerPop] Question about arcs jackpark 10/26/13 8:04 AM My understanding of a hypergraph is that an edge can connect any number of vertices. One edge, many vertices. That's not what I am talking about. So, notions of "hypergraph" are not an aspect of my query. Notions of granting an edge the same capabilities of a vertex, that is an edge can be an edge in one graph traversal, but it can be a vertex in another -- same object -- is what I am talking about. Perhaps there exists no mathematics to support that idea. I simply don't know. Thanks Re: [TinkerPop] Question about arcs jackpark 10/27/13 12:09 PM Could someone point to some document that explains why an arc should not be also a vertex when needed to be so? Inquiring minds... Re: [TinkerPop] Question about arcs jackpark 10/27/13 12:37 PM On reflection, this seems interesting, possibly useful. {person, position, company} with the "position" edge linking to a vertex which, in essence, expresses the meaning "person as at " is really what I am driving at. It seems important that the new vertex ought to link back to the edge for which it stands.  That was the point of facilitating an edge to be its own vertex. That new vertex will entail its own biography. Stan Ulam, once asked what he thought of AI, argued that AI would get there when it could represent "asA", and not just "isA". On Fri, Oct 25, 2013 at 11:41 AM, Pieter Martin wrote: Re: [TinkerPop] Question about arcs Zach Kinstner 10/31/13 9:15 AM Titan allows an edge to have uni-directional, outgoing edges (each pointing to a vertex). From Titan's Type Definition Overview document:Furthermore, many-to-one uni-directed edges can also be created on edges, pointing from an edge to a vertex using `TitanEdge.setProperty(Label,Vertex)`. Such edges are retrieved via `TitanEdge.getProperty(Label)`. Hence, Titan provides limited support for hyper edges which is useful for attaching provenance or authorization information to edges.Jack, would this be helpful for your scenario?Zach Re: [TinkerPop] Question about arcs jackpark 10/31/13 9:41 AM Very interesting. I must spend some time looking at that. Un-known aspect due to lack of experience with the algorithms is whether a specific edge can then be addressed the same way a vertex can. Many thanks