Extract Navigator in its own repo? about levelgraph HOT 10 OPEN

i think it should as well.

from levelgraph.

👍

from levelgraph.

It's very perfect if more project can use the navigator.

from levelgraph.

@snowyu do you want to give it a spin and extract it?

from levelgraph.

Let me try to explain it, but maybe I am not correct. It's just an immature idea. And I've mixed up the other stuff in there. For reference purposes only.

• Navigator could be a query generator (like 'sql' generator?).
• Navigator could be a query optimizer. it should try to use indexes on database.

The next question is howto define and use the index and query on graph database.

Unfortunately, there are not a standard like sql. It is a bit difficult to understand SPARQL.
Obviously, Gremlin is much easier to understand than SPARQL. But it's just the programming
API rather than a query language. I found the OrientDB uses an OrientDB SQL dialect.
It could be a better way.

Ok, maybe we need a query engine layer and a navigator layer on it.

• The Query Engine: execute the query, and get the result.
• The Navigator Engine: translate and optimze to query.

But It maybe extract the index definition way to suite difference database to use.
Many things have to be thought about.

Recently, I was writing knowledge-driven database engine, based on level-subkey.
In some ways It is similar to the the graph database, but it is still quite different.

1. The "path" indicates inheritance relationship(ISA).
2. The key with "attributes" represents meronymy relationship(HASA).
   • The "value" is a special "attribute".
3. The key with "actions" means executable functions or the key issued.

So, the SPO are already exists for the key "path" relation. Eg, "/stuff/creature/animal/pig":

• {subject: stuff, predicate: hyponymy, object: creature}
• {subject: creature, predicate: hyponymy, object: animal}
• {subject: animal, predicate: hyponymy, object: pig}

The rest of the sop,ops,osp and pso only need to be indexed.

And the same with the "attribute". eg, "pig/.leg/.count = 4"

• {subject: pig, predicate: hasa, object: leg}
• {subject: pig, predicate: leg, object: {count:4}}
• {subject: leg, predicate: hasa, object: count}
• {subject: leg, predicate: count, object: 4}

Sorry, it seems I digress a galaxy. I have a lot of confusion to decide.

• Attributes should be in level-subkey or not?
  • level-subkey is becoming more and more complex.
• Asynchronous operation makes readability of the code is getting worse and more complex.
  • a little synchronous operation to reduce the code complexity.
  • ES7 async/await is still too far.
• Bootstrap itself to database
• Add Inference Engine to database
• Index: bytewise encoding is not very efficient.
• level-graph should be a low-level graph database? or a knowledge database?
• and so on...

Back to the topic. Just For U References:

• SPARQL
  • SPARQL.js
  • rdfstore-js
  • Yet Another Sparql GUI
• Gremlin
  • Pixy
  • Gremlin JavaScript: it's not pure javascript.
  • Object-to-graph mapper for Node.js using Gremlin in Mongoose style
  • Sql2Gremlin
  • helios.js pure js to Gremlin in it.
• OrientDB SQL dialect
• MQL- Metaweb query language
• Horton - Querying Large Distributed Graphs
• GraphSON Reader and Writer Library

from levelgraph.

Just a couple of things:

Navigator could be a query generator (like 'sql' generator?).

Yes.

Navigator could be a query optimizer. it should try to use indexes on database.

As things are now, no. That job is done by the query planner in LG.

The Query Engine: execute the query, and get the result.

That is search

The Navigator Engine: translate and optimze to query.

That is the query planner.

The core idea is that the Navigator exposes the same API of Search in a fluent lingo. I am not sure it is the right path.

from levelgraph.

Pardon, lingo just means easy to use language, or a special name?

from levelgraph.

Yes, Navigator is the search API with a Fluent API.
Il giorno gio 25 dic 2014 alle 13:07 Riceball LEE [email protected]
ha scritto:

Pardon, lingo just means easy to use language, or a special name?

—
Reply to this email directly or view it on GitHub
#68 (comment).

from levelgraph.

Ah, that I said before the Gremlin Programming API in here. this should be ok. After all, we must have the search API first, in order to have a sql query language. then the roadmap may be :

• AbstractQuery
  • AbstractFluentQuery
    • GremlinQuery
  • AbstractSqlQuery
• QueryPlanner

from levelgraph.

I want the search and QueryPlanner to live inside LevelGraph, and the
various simplified interfaces to be plugins.
Il giorno ven 26 dic 2014 alle 04:36 Riceball LEE [email protected]
ha scritto:

Ah, that I said before the Gremlin Programming API in here. this should be
ok. After all, we must have the search API first, in order to have a sql
query language. then the roadmap may be :

• AbstractQuery
  • AbstractFluentQuery
    • GremlinQuery
      • AbstractSqlQuery
      • QueryPlanner

—
Reply to this email directly or view it on GitHub
#68 (comment).

from levelgraph.