A directed graph and undirected graph both excel at modeling different
problems and are used by an overlapping (though neither is a subset of the
other) set of algorithms. AGE, Neo4J and cypher are all directed models
that have some undirected features, which are inherently designed to be
ambiguous (such as MATCH with no direction given). The AGE edge datatype is
not designed to handle true undirected edges, and can only emulate them
using two directed edges. Which mathematically speaking and from an
algorithm design point of view have some subtle differences.
On Mon, Jan 24, 2022 at 6:07 PM Jasper Blues <jas...@liberation-data.com>
wrote:
> Sounds reasonable đ
>
> Officially the docs say undefined, so please donât rely upon it.
> But the defacto standard is consistent.
>
> The model is a directed graph, but when direction does not matter, CYPHER
> allows to ignore it.
>
> Are there some cases where adding support for true undirected edges adds
> value over the above approach?
>
> > On Jan 25, 2022, at 10:01 AM, Josh Innis <joshin...@gmail.com> wrote:
> >
> > I have spent some time on the Neo4J console. I was running this set of
> > commands:
> >
> > 1. MERGE ({side: 'left'})-[:edge]-({side:'right'})
> > 2. MATCH (l{side: 'left'})-[:edge]->(r{side:'right'}) RETURN l, r
> > 3. MATCH (l{side: 'left'})<-[:edge]-(r{side:'right'}) RETURN l, r
> > 4. MATCH (n) DETACH DELETE n
> >
> > No matter how many times I deleted the nodes and ran the merge command:
> > Line 2 returns 1 row and line 3 returns 0 rows. Even though the
> > documentation says it is ambiguous, for the version freely
> > available for what is the defacto standard: this ambiguous query will
> > always create relationships going left to right.
> >
> > On Mon, Jan 24, 2022 at 5:37 PM Josh Innis <josh.in...@bitnine.net>
> wrote:
> >
> >> Support in what way, have two edges, one for each direction or what
> Jasper
> >> and Nick are suggesting?
> >>
> >> On Mon, Jan 24, 2022 at 5:35 PM John Gemignani <
> john.gemign...@bitnine.net
> >>>
> >> wrote:
> >>
> >>> I don't think having a default direction applied for a non-directed
> edge
> >> is
> >>> a good idea; there wouldn't be a way to tell these edges apart later
> on.
> >>>
> >>> I think it might be a better idea to just support non-directed edges.
> >>>
> >>> John
> >>>
> >>> On Mon, Jan 24, 2022 at 3:35 PM Jasper Blues <
> jas...@liberation-data.com
> >>>
> >>> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> The quirk behind that CYPHER comes from Neo4jâs property graph model:
> >>>>
> >>>> All edges have a direction
> >>>> When direction is not relevant it can be ignored.
> >>>>
> >>>> This works will for read queries, for merge it is slightly quirky,
> >>> however
> >>>> I believe the specification is reasonable:
> >>>>
> >>>> If we MERGE with an edge that does not specify a direction, it is
> >> because
> >>>> direction is irrelevant, just as in the read scenario
> >>>> Given this, the result is to intentionally assign a random direction
> >>>>
> >>>> I think the above behavior is OK. It would also be reasonable to pick
> a
> >>>> consistent direction, however this leads to potential compatibility
> >>> issues:
> >>>>
> >>>> Users might start depending on an âimpliedâ direction
> >>>> When porting to/from Neo4j (interoperability is a strength - being
> able
> >>> to
> >>>> attract users to the platform and have the users be confident they can
> >>>> migrate if ever they want aids adoption).
> >>>>
> >>>> So my 2c: Do what Neo4j does, and make it random, because the
> intention
> >>> is
> >>>> âdirection doesnât matterâ. However choosing a direction would also be
> >>> ok.
> >>>> I donât think rejecting the MERGE is great, because it differs from
> how
> >>>> other CYPHER graph DBs behave.
> >>>>
> >>>>
> >>>>
> >>>>> On Jan 25, 2022, at 7:06 AM, Josh Innis <josh.in...@bitnine.net>
> >>> wrote:
> >>>>>
> >>>>> Hi All,
> >>>>>
> >>>>> The openCypher specification for MERGE has an ambiguous specification
> >>> on
> >>>>> the subject of undirected relationships.
> >>>>>
> >>>>> Per the document on page 119 in the section titled "Merge on an
> >>>> undirected
> >>>>> relationship":
> >>>>>
> >>>>> MERGE can also be used with an undirected relationship. When it needs
> >>> to
> >>>>> create a new one, it will pick a direction.
> >>>>>
> >>>>> Query:
> >>>>> MATCH (charlie:Person {name: 'Charlie Sheen'}), (oliver:Person {name:
> >>>>> 'Oliver Stone'})
> >>>>> MERGE (charlie)-[r:KNOWS]-(oliver)
> >>>>> RETURN r
> >>>>>
> >>>>> As 'Charlie Sheen' and 'Oliver Stone' do not know each other, this
> >>> MERGE
> >>>>> query will create a KNOWS relationship between them. The direction of
> >>> the
> >>>>> created relationship is arbitrary.
> >>>>>
> >>>>> We should probably clarify that. Having MERGE use undirected edges to
> >>>> find
> >>>>> paths is a potentially useful feature, but "The direction of the
> >>> created
> >>>>> relationship is arbitrary" is unclear and should be clarified.
> >>>>>
> >>>>> I believe there are two potential ways to solve this issue:
> >>>>> Option 1: Do not let MERGE use undirected edges.
> >>>>> Option 2: Have a default direction that AGE will use every time MERGE
> >>>>> creates an edge where direction is not specified.
> >>>>>
> >>>>> Personally, I lean towards proposal 2 with the default direction
> >> being
> >>> a
> >>>>> right directed edge. The other way limits functionality, and as long
> >> as
> >>>> the
> >>>>> decision we make is expressed well in the documentation, I don't
> >>> believe
> >>>> it
> >>>>> is too confusing.
> >>>>>
> >>>>> Please let us know what you think.
> >>>>
> >>>>
> >>>
> >>
>
>
