Hey Mike I think that this is interesting and it reminds me of using the
OWL *inverseOf *property relationship and other features of the inferencing
engine (overview <http://www.w3.org/TR/2004/REC-owl-features-20040210/>,
spec <http://www.w3.org/TR/owl-ref/#inverseOf-def>). Or stepping further
back (in my learning) defining rules in Prolog.
I guess that my question as a developer is why I would want the inverse
relationship label defined? If I can write a CYPHER query I can represent
the nodes and relationships in the query as I like, is it just the
representation in the console that you find unintuitive, or is that when
opening the console up to users it can be confusing to say if you want to
find the parents of child X then you need to follow the HAS_CHILD
relationship 'backwards'? I confess I would hide most of this behind an
abstraction layer of some sort.
With the triple stores I have used there is usually an inference engine
which then expose to queries the union of both the asserted triples (the
data that you explicitly added) and the inferred triples (the ones that
rules were used to create). The important thing about the inferred triples
is that they are ephemeral meaning that they do not impact the underlying
datastore (although you could choose the materialize them) which stops
unnecessary bloat (at the cost of processing).
As these new relationships are sugar which is ultimately bloat would you
ever want to persist them? I also suspect that the directional trick you
suggest could have serious implications to the performance of the query
engine (but that's just a hunch).
The Sibling/Spouse example has limited mileage for me without some clever
chaining (e.g. how would I represent cousins? Harden SIBLING and
PARENT/SPOUSE relationships and then chain SIBLING->PARENT->SIBLING->CHILD
nodes, hardening along the way?) and again I think I would see more value
in adding this a level above the underlying store.
Sporadic rambling done, as Neo is super fast at graph traversals (really??)
I personally do not see much value add unless abstracted away from Core
Neo, and until such time I would be happy to use Cypher to create the new
relationships when required.
M
On Wednesday, 3 September 2014 03:57:37 UTC+1, Michael Fair wrote:
>
> 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.
