[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours
[
https://issues.apache.org/jira/browse/TINKERPOP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852023#comment-16852023
]
Fabio Lorenzi commented on TINKERPOP-2230:
--
Is there some easy to explain reason?
> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
> Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a),
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually
> contains a solvable form of patterns. It's really confusing; if you want,
> create a Jira ticket for that issue, perhaps someone dares to analyze that
> crazy code"
> please see
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
> for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-881) [Proposal] A Process-Based Graph Reasoner
[
https://issues.apache.org/jira/browse/TINKERPOP-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16850712#comment-16850712
]
Fabio Lorenzi commented on TINKERPOP-881:
-
Has this issue been closed because already integrated or has it been abandoned?
> [Proposal] A Process-Based Graph Reasoner
> -
>
> Key: TINKERPOP-881
> URL: https://issues.apache.org/jira/browse/TINKERPOP-881
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> This would be a big initiative, so its more than "just a ticket," but it
> would be a neat idea.
> A reasoner allows someone to express implicit edges/properties in the graph.
> For instance, it is possible to say that {{ancestor}} is transitive. If there
> was an explicit graph structure like:
> {code}
> marko--ancestor-->jose--ancestor-->fernando--ancestor-->someSpanishDude
> {code}
> Then when you did the following query:
> {code}
> gremlin> g.V.has('name','marko').out('ancestor').name
> ==>jose
> ==>fernando
> ==>someSpanishDude
> {code}
> That is, because it is declared the {{ancestor}} is transitive, the implicit
> {{marko--ancestor-->someSpanishDude}} is generated. Now, there are two types
> of reasoners: structure and process.
> A *structure reasoner* will infer all the entailments of the schema when the
> graph is modified (added to or deleted from). Thus, what is implicit is made
> explicit and put into the graph. With this model, your data set has more data
> than what was explicitly put into it.
> A *process reasoner* will infer all the entailments of the schema as it
> pertains to the current query being executed. Thus, what is implicit is made
> explicit at query runtime. With this model, you data set contains only what
> was explicitly inserted.
> These two models either make a sacrifice of space or time.
> If we wanted just a *process reasoner*, then this could be a
> {{ReasoningStrategy extends DecorationStrategy}}. Where the above
> {{ancestor}} query would be rewritten as:
> {code}
> g.V.has('name','marko').repeat(out('ancestor')).emit().name
> {code}
> In essence, "transitive" means {{repeat(...).until(false).emit()}} (loop
> until you can loop no more).
> I prefer the *process reasoner* model as its less cumbersome and potentially
> damaging to the integrity of the underlying data set. Moreover, it can be
> "easily" implemented as a {{TraversalStrategy}}.
> The next question is, how is the reasoning schema (ontology) specified?
> Perhaps via a builder?
> {code}
> ReasoningStrategy.build().
> .transitive("ancestor")
> .subEdge("hasPet","likes") // if I have a pet dog, I like dogs.
> .symmetric("friend") // a.friend.b implies b.friend.c
> .functional("marriedTo") // a.marriedTo.b, c.marriedTo.b ==> a=c
> ...other stuff
> .create();
> {code}
> Here are some links to study:
> * https://jena.apache.org/documentation/inference/#the-owl-reasoner
> * http://owl.man.ac.uk/2003/why/latest/
> In my experience, you can do a lot with support for the basics: transitive,
> symmetric, etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2230) match() step unexpected behaviours
Fabio Lorenzi created TINKERPOP-2230:
Summary: match() step unexpected behaviours
Key: TINKERPOP-2230
URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.4.1
Reporter: Fabio Lorenzi
On the well known software graph:
{code:java}
gremlin> g.V().match(
..1> __.as('a').out('knows').as('b'),
..2> __.as('b').out('created').as('c'))
==>[a:v[1],b:v[4],c:v[5]]
==>[a:v[1],b:v[4],c:v[3]]
gremlin> g.V().match(
..1> __.as('b').out('created').as('c'),
..2> __.as('a').out('knows').as('b'))
The provided match pattern is unsolvable: [[MatchStartStep(a),
VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b),
VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
{code}
with the second one being solvable as well (I think). (?)
Quoting [~dkuppitz]:
"I just noticed that the error message of my failing traversal actually
contains a solvable form of patterns. It's really confusing; if you want,
create a Jira ticket for that issue, perhaps someone dares to analyze that
crazy code"
please see
[this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
for more information.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2227) DetachedVertex public constructor ClassCast Exception
[
https://issues.apache.org/jira/browse/TINKERPOP-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabio Lorenzi updated TINKERPOP-2227:
-
Environment:
java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> DetachedVertex public constructor ClassCast Exception
> -
>
> Key: TINKERPOP-2227
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2227
> Project: TinkerPop
> Issue Type: Bug
>Affects Versions: 3.4.1
> Environment: java -version
> java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
>Reporter: Fabio Lorenzi
>Priority: Major
>
> {code:java}
> HashMap props = new HashMap<>();
> props.put("name", "D");
> DetachedVertex v = new DetachedVertex("fake", "entity", props);
> {code}
> returns
> {code:java}
> Exception in thread "main" java.lang.ClassCastException: java.lang.String
> cannot be cast to java.util.List
> at
> org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex.lambda$new$2(DetachedVertex.java:82)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex.(DetachedVertex.java:81)
> {code}
> which is directly related to the public constructor.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2227) DetachedVertex public constructor ClassCast Exception
Fabio Lorenzi created TINKERPOP-2227:
Summary: DetachedVertex public constructor ClassCast Exception
Key: TINKERPOP-2227
URL: https://issues.apache.org/jira/browse/TINKERPOP-2227
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.4.1
Reporter: Fabio Lorenzi
{code:java}
HashMap props = new HashMap<>();
props.put("name", "D");
DetachedVertex v = new DetachedVertex("fake", "entity", props);
{code}
returns
{code:java}
Exception in thread "main" java.lang.ClassCastException: java.lang.String
cannot be cast to java.util.List
at
org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex.lambda$new$2(DetachedVertex.java:82)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
org.apache.tinkerpop.gremlin.structure.util.detached.DetachedVertex.(DetachedVertex.java:81)
{code}
which is directly related to the public constructor.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
