Question about arcs

[Jack Park]

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.

[Zach Kinstner]

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

[Jack Park]

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.

[Zach Kinstner]

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

[Pieter Martin]

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

[Jack Park]

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.

[Jack Park]

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.

[Pieter Martin]

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

[Jack Park]

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.

[Zach Kinstner]

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".

[Pieter Martin]

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

[Jack Park]

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

[Jack Park]

Could someone point to some document that explains why an arc should
not be also a vertex when needed to be so?

Inquiring minds...

[Jack Park]

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 <position>
at <company>" 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 <pieter...@gmail.com> wrote:

[Zach Kinstner]

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

[Jack Park]

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