I did some searching but couldn't find any discussion on the topic yet.
Has anyone considered enabling multiple type labels for a relationship type
where the label name used in the query implies the directionality of the
relationship? What are the caveats/pitfalls/complications of allowing
multiple labels to refer to the same relationship type?
For example, assume we've created a relationship called "CHILD_OF".
(c)->[:CHILD_OF]->(p)
This has the implied inverse relationship of "PARENT_TO"
(p)<-[:PARENT_TO]<-(c)
Currently we'd have to define two separate relationships to be able to use
either form of those queries to get back the same information.
I'm thinking it'd be really great if we could give relationships
multiple type names; I'm thinking 2 to start; one for each direction when
defining the link.
In other words, in addition to having a forward direction name, we could
also define the reverse direction name as part of the relationship type.
I don't have an exact syntax for representing this yet, but I'm thinking of
using an optional '/' on the relationship name when assigning the
relationship to the node.
For instance, similar pairings exist in practically all hierarchical
relationships:
[:OWNER_OF/OWNED_BY {}]
[:CONTAINS/INSIDE_OF {}]
[:COVERED_BY/COVERING {}]
as well as the roles of the parties in a two-way relationship/transaction:
[:FOLLOWING/FOLLOWED_BY {}]
[:EMPLOYS/EMPLOYED_BY {}]
[:ABOVE/BELOW {}]
I'd like to hear people's thoughts on syntax, implementation difficulty,
and just comments in general on how useful or not this kind of naming could
be.
Assuming it's useful, is it better to go for a full featured system that's
actually useful and makes it super easy rather than a half featured system
that's cumbersome and therefore doesn't actually get used by anyone?
I have some ideas for the implementation to get started that avoids any
on-disk format changes (the basic concept is to store the labels exactly as
typed above (complete with the slashes) as the actual, official, on-disk
type name; then when loading the name into memory, add a "direction" bit to
in-memory relationship types structure and parse out the on-disk name to
create two entries that both refer back to the same relationship type
identifier; just that one now implies using reversed terms).
Would people still be able to use the feature if the returned results were
always expressed in terms of the forward relationship?
It's obviously ideal if the results preserve the name and direction used in
the original query; so if we asked for "CHILD_OF" or "PARENT_TO" in the
query, then that's what we'd get back. However if the inverse labels are
implemented as just a syntactic shortcut for reversing the terms on the
forward query like I'm thinking, preserving the original context could get
problematic.
Would it still be useful if someone expressed "PARENT_TO" in the query, but
then got back "CHILD_OF" relationship results?
I don't think it would because whatever was receiving the results would be
expecting what it asked for, but I'd like to hear other people's comments
on that.
(Assuming it's not useful, then I'd welcome ideas for how to keep the
original context from the original query.)
Lastly, a slightly more complex syntax/implementation would be to allow
multiple alternates and embed the direction directly in the alternate
labels.
I was considering using multiple slashes with <- and -> on the front of the
label to define the direction of the alternate links.
For example, these would all become different relationship types:
[:SIBLING//<-BROTHER/->SISTER {}]
[:SIBLING//<-BROTHER/->BROTHER {}]
[:SIBLING//<-SISTER/->SISTER {}]
[:SPOUSE/<-SPOUSE/<-HUSBAND/->WIFE {}]
[:SPOUSE/<-SPOUSE/<-WIFE/->WIFE {}]
[:SPOUSE/<-SPOUSE/<-HUSBAND/->HUSBAND {}]
This says that SIBLING and SPOUSE should treat the from/to nodes as is, as
should all the labels using the "->" prefix.
All labels using the "<-" prefix should reverse the context of the from/to
nodes when being used in a query.
Also, each of the labels is used multiple times.
E.g. when there's a query for a "SIBLING" or "SPOUSE" relationship that
would become an alternation for all three of the respective relationship
types.
Querying for "Brother", "Sister", "Husband", or "Wife" would likewise
become an alternation for all of the appropriate relationship types.
The idea being we can express multiple names and the relationship direction
those relationships imply.
Thanks,
Mike
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
