GithubHelp home page GithubHelp logo

vaticle / typeql Goto Github PK

View Code? Open in Web Editor NEW
211.0 14.0 45.0 2.89 MB

TypeQL: the polymorphic query language of TypeDB

Home Page: https://typedb.com

License: Mozilla Public License 2.0

ANTLR 2.21% Starlark 4.23% Java 56.62% Shell 0.15% Gherkin 0.08% Rust 36.71%
reasoning query-language query inference logic database typedb typeql type-system strongly-typed

typeql's Introduction

TypeQL

Factory GitHub release Discord Discussion Forum Stack Overflow Stack Overflow Hosted By: Cloudsmith

Introducing TypeQL

TypeQL is the query language of TypeDB.

  • Conceptual and intuitive. TypeQL is based directly on the conceptual data model of TypeDB. Its queries comprise sequences of statements that assemble into patterns. This mirrors natural language and makes it easy and intuitive to express even highly complex queries.
  • Fully declarative and composable TypeQL is fully declarative, allowing us to define query patterns without considering execution strategy. The user only composes sets of requirements, and TypeDB finds all matching data to process.
  • A fully variablizable language. Any concept in TypeQL has a type, and so any concept in TypeQL can be variablized in a query – even types! This enables TypeQL to express powerful parametric database operations.
  • Built for consistency. TypeQL patterns are underpinned by a powerful type system that ensure safety and consistency of database applications.

For a quick overview of the range of statements that are available in TypeQL check out our TypeQL in 20 queries guide.

IMPORTANT NOTE: > > TypeDB & TypeQL are in the process of being rewritten in Rust. There will be significant refinement to the language, and minor breaks in backwards compatibility. Learn about the changes on our roadmap issue on GitHub. The biggest change to TypeDB 3.0 will be our storage data structure and architecture that significantly boosts performance. We’re aiming to release 3.0 in the summer this year, along with preliminary benchmarks of TypeDB.

A polymorphic query language

Define types, inheritance, and interfaces

TypeQL features the type system of the Polymorphic Entity-Relation-Attribute (PERA) model: entities are independent concepts, relations depend on role interfaces played by either entities or relations, and attributes are properties with a value that can interface with (namely, be owned by) entities or relations. Entities, relations, and attributes are all considered first-class citizens and can be subtyped, allowing for expressive modeling without the need for normalization or reification.

define

id sub attribute, value string;
email sub id;
path sub id;
name sub id;

user sub entity,
    owns email @unique,
    plays permission:subject,
    plays request:requestee;
file sub entity,
    owns path,
    plays permission:object;
action sub entity,
    owns name,
    plays permission:action;

permission sub relation,
    relates subject,
    relates object,
    relates action,
    plays request:target;
request sub relation,
    relates target,
    relates requestee;

Write polymorphic database queries

Use subtyping to query a common supertype and automatically retrieve matching data. Variablize queries to return types, roles, and data. New types added to the schema are automatically included in the results of pre-existing queries against their supertype, so no refactoring is necessary.

match $user isa user,
    has full-name $name,
    has email $email;
# This returns all users of any type

match $user isa employee,
    has full-name $name,
    has email $email,
    has employee-id $id;
# This returns only users who are employees

match $user-type sub user;
$user isa $user-type,
    has full-name $name,
    has email $email;
# This returns all users and their type

Building queries with ease

Gain clarity through natural and fully declarative syntax

TypeQL's near-natural syntax and fully declarative properties make queries easily understandable, reducing the learning curve and easing maintenance. This allows you to define query patterns without considering execution strategy. TypeDB's query planner always optimizes queries, so you don't have to worry about the logical implementation.

match
$kevin isa user, has email "[email protected]";

insert
$chloe isa full-time-employee,
    has full-name "Chloé Dupond",
    has email "[email protected]",
    has employee-id 185,
    has weekly-hours 35;
$hire (employee: $chloe, ceo: $kevin) isa hiring,
    has date 2023-09-27;

Develop modularly with fully composable query patterns

TypeDB's TypeQL query language uses pattern matching to find data. Patterns in TypeQL are fully composable. Every complex pattern can be broken down into a conjunction of atomic constraints, which can be concatenated in any order. Any pattern composed of valid constraints is guaranteed to be valid itself, no matter how complex.

match 
$user isa user;

match
$user isa user;
$user has email "[email protected]";

match
$user isa user;
$user has email "[email protected]";
(team: $team, member: $user) isa team-membership;

match
$user isa user;
$user has email "[email protected]";
(team: $team, member: $user) isa team-membership;
$team has name "Engineering";

TypeQL grammar

Note: All TypeDB Clients, as well as TypeDB Console, accept TypeQL syntax natively. If you are using TypeDB, you do not need additional libraries/tools to use TypeQL syntax natively. However, if you would like to construct TypeQL queries programmatically, you can do so with "Language Libraries" listed below.

Resources

Developer resources

Useful links

If you want to begin your journey with TypeDB, you can explore the following resources:

Contributions

TypeDB and TypeQL are built using various open-source frameworks and technologies throughout its evolution. Today TypeDB and TypeQL use Speedb, pest, SCIP, Bazel, gRPC, ZeroMQ, and Caffeine.

Thank you!

In the past, TypeDB was enabled by various open-source products and communities that we are hugely thankful to: RocksDB, ANTLR, Apache Cassandra, Apache Hadoop, Apache Spark, Apache TinkerPop, and JanusGraph.

Package hosting

Package repository hosting is graciously provided by Cloudsmith. Cloudsmith is the only fully hosted, cloud-native, universal package management solution, that enables your organization to create, store and share packages in any format, to any place, with total confidence.

Licensing

TypeQL grammar and language libraries are provided under the Mozilla Public License 2.0 (MPL 2.0), and therefore freely usable without restriction when unmodified.

The full license can be founder at: LICENSE.

typeql's People

Contributors

alexjpwalker avatar dependabot[bot] avatar dmikhalin avatar dmitrii-ubskii avatar flyingsilverfin avatar grabl avatar haikalpribadi avatar izmalk avatar jamesreprise avatar jmsfltchr avatar kasper-piskorski avatar krishnangovindraj avatar lolski avatar lriuui0x0 avatar maxbaxt avatar nikolaimerritt avatar shiladitya-mukherjee avatar tomassabat avatar vaticle-bot avatar vmax avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

typeql's Issues

Negation query for "phone_calls" example 2 fails

Description

I'm trying to run the phone_calls example 2 query (with the negation query as per this PR). It fails to run when negation is used; however when the negation term is not used, the query runs without any issues.

Environment

  1. OS (where Grakn server runs):
    • Operating System: Linux Mint 19.1
    • Kernel: Linux 4.15.0-70-generic
    • Architecture: x86-64
  2. Grakn version (and platform): Grakn Core 1.6.0
  3. Grakn client: client-python, workbase and console
  4. Other environment details:

Reproducible Steps

Steps to create the smallest reproducible scenario:

  1. grakn console -k phone_calls -f ./examples/schemas/phone-calls-schema.gql
  2. python3 ./examples/phone_calls/python/migrate_json.py
    • This will generate the graph (no issues up to this point)
  3. Run query on Grakn workbase for example 2 (including the negation line as per line 91 from examples/phone_calls/python/queries.py)
    match
      $suspect isa person, has city "London", has age > 50;
      $company isa company, has name "Telecom";
      (customer: $suspect, provider: $company) isa contract;
      $pattern-callee isa person, has age < 20;
      (caller: $suspect, callee: $pattern-callee) isa call, has started-at $pattern-call-date;
      $target isa person, has phone-number $phone-number;
      not { (customer: $target, provider: $company) isa contract; };
      (caller: $suspect, callee: $target) isa call, has started-at $target-call-date;
      $target-call-date > $pattern-call-date;
    get $phone-number;
    
  4. When using workbase to run the query, the following error message is seen in the logs:
2019-11-26 17:05:20,805 [grpc-request-handler-13] ERROR g.c.s.r.SessionService$TransactionListener - Runtime Exception in RPC TransactionListener: 
io.grpc.StatusRuntimeException: CANCELLED: cancelled before receiving half close
	at io.grpc.Status.asRuntimeException(Status.java:517)
	at io.grpc.stub.ServerCalls$StreamingServerCallHandler$StreamingServerCallListener.onCancel(ServerCalls.java:272)
	at io.grpc.internal.ServerCallImpl$ServerStreamListenerImpl.closed(ServerCallImpl.java:293)
	at io.grpc.internal.ServerImpl$JumpToApplicationThreadServerStreamListener$1Closed.runInContext(ServerImpl.java:741)
	at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37)
	at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:123)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
2019-11-26 17:05:20,811 [transaction-listener] ERROR g.c.s.r.SessionService$TransactionListener - Runtime Exception in RPC TransactionListener: 
java.lang.NullPointerException: null
  1. When using the Python client to run the query as per this example, the following traceback is obtained:
ERROR:grpc._common:Exception deserializing message!
Traceback (most recent call last):
  File "/home/pprao/Desktop/GitHub/graphdb-examples/venv/lib/python3.6/site-packages/grpc/_common.py", line 88, in _transform
    return transformer(message)
google.protobuf.message.DecodeError: Error parsing message
Traceback (most recent call last):
  File "/home/pprao/Desktop/GitHub/graphdb-examples/venv/lib/python3.6/site-packages/grakn/service/Session/TransactionService.py", line 156, in send
    response = next(self._response_iterator)
  File "/home/pprao/Desktop/GitHub/graphdb-examples/venv/lib/python3.6/site-packages/grpc/_channel.py", line 364, in __next__
    return self._next()
  File "/home/pprao/Desktop/GitHub/graphdb-examples/venv/lib/python3.6/site-packages/grpc/_channel.py", line 358, in _next
    raise self
grpc._channel._Rendezvous: <_Rendezvous of RPC that terminated with:
        status = StatusCode.INTERNAL
        details = "Exception deserializing response!"
        debug_error_string = "None"

Expected Output

We should expect to see 12 phone numbers as the output:

[ '+30 419 575 7546',  '+86 892 682 0628', '+1 254 875 4647',
  '+351 272 414 6570', '+33 614 339 0298', '+86 922 760 0418',
  '+86 825 153 5518',  '+48 894 777 5173', '+351 515 605 7915',
  '+63 808 497 1769',  '+27 117 258 4149', '+86 202 257 8619' ]

Actual Output

ERROR message with the full stack trace shown in the logs (for the workbase example) or in the Python stack trace (for the Python client example).

Additional Information

When I remove the line with the negation term, the query works and I get a result. Looks like the issue is with the way the negation term is being parsed.

TypeQL parsers in alternative languages

Problem to Solve

Implement TypeQL parsing in languages other than Java. This would for instance allow reading entire files of queries into the python or node client without having to hack some custom delimiters into the files and executing line by line within the user's application code.

Derives from: vaticle/typedb-driver-python#41

Current Workaround

One can either spread custom delimiters in the file that contains definitions or queries and parse these out in the client's application logic, executing them one by one, or write a wrapper around a small client-java and typeql program to do this using parseList()

Proposed Solution

Extend ANTLR to other languages.

Additional Information

Graql: Enable removing roleplayer from relationship in Graql

This issue was originally posted by @haikalpribadi on 2017-08-30 12:26.

How can we remove a specific roleplayer from a relation? In the Java API, it could be as simple as:

relation.removeRolePlayer(instance);

But how do we do that with Graql? We have two options on the table:

Use a new keyword to flag the role player to be deleted:

match $r (actor NEW-KEYWORD $c: $x); $x isa person; delete $c;

Make the deletion part take in patterns:

match $r (actor: $x); $x isa person; delete $r (actor: $x);

Option 2 makes delete behave a lot like undefine which is nice but it may make get look like the odd one out. Insert and Delete take patterns but get only takes in a list of variables. Not sure how bad that is.

Graql: Support for lists of arguments (ids, labels, properties)

This issue was originally posted by @haikalpribadi on 2018-04-22 22:47.

We want to implement a new feature in Graql syntax: the ability to provide a set of arguments to a given graql statement. For example, the ability to provide the following statement in the schema:

define person sub entity, has email [unique, max=3];

Defining multiple ids:

match $x isa person; $x id [V123, V456]; get;

-> useful for KGlib, set-at-a-time reasoning

Defining multiple values:

match $x has name [Bob, Alice, Stefan]; get

Defining multiple labels:

match $x isa $type; $type label [person, animal]; get;

All these would work as if the multiple elements were defined via a disjunction.

Reflect Grammar Match restrictions in TypeQL API

Right now, we restrict grammar to disallow statements such as match $x; get. When building with TypeQL language builders, this is still allowed (TypeQL.match(var("x")).get()) when it should not be.

Further restrictions are currently built into TypeDB's match clause validation at runtime, but not checked elsewhere - such as match $x != $y; get; which does a n^2 scan of the database. We could push this into TypeQL and do the check when the Pattern is built.

Reconsider design of analytics language component

Previously, Compute had its own independent architecture, separate from the rest of the queries. This feels very "accidental" as it was a consequence of implementing Compute without thinking through a cohesive design that integrates well. However, they should ideally be integrated together.

Introduce cardinality restriction

This issue was originally posted by @haikalpribadi on 2016-12-01 16:23.

person sub entity,
    has first-name [1,1],
    has middle-name [0, *],
    has address [1,*];

shopping-transaction sub relationship,
    relates buyer [1,1],
    relates seller [1,1],
    relates product [1,*],
    has date [1,1];

...and so on. This might be a demanding extension on some levels, but:

  • we're already dealing with a few implicit cardinality restrictions in the system, anyway, so making them explicit would increase transparency,
  • making these explicit would also clarify a number of intriguing issues on the KR side (first in the row inheritance between relations),
  • it's a common modelling feature in conceptual modelling frameworks (ER) and some ontology languages (OWL).
    The immediate costs:
  • yet another feature in our not-so-trivial schema language,
  • more complexity for the consistency validation mechanism.

Graql: Optionally fetch attributes

This issue was originally posted by Harry Blakiston Huoston on 2018-08-26 09:06.

This is a question at first but may turn into a feature request.
Does grakn support any non-strict attribute requests i.e lets say I am fetching personal information belonging to a person that can either be a phone or an address (both separate child entities of a common entity "property") the two will share a field detail (either +447773078736) or (Flat 70) respectively, then the address may have additional attributes (street, province, city, postalCode and country). A query that allowed me to fetch just the detail if the entity is a "phone" and then the detail, street, province, city, postalCode and country if the entity is an "address".

TypeQL: query for variables by multiple IDs

Currently, it is not possible to use multiple IDs within the same query (the workaround is to use multiple variables). Ideally, I would like it to be supported similar to other attributes like that:

match $x id $id; {$id V168040;} OR {$id V118888;}; get;

No syntactic error reported

Description

This has been reported by a user, when trying to run 2 insert queries as one
(i.e. one query containing 2 inserts insert $x ...; insert $y....;)
the user only gets back an empty stack trace

Reproducible Steps

I havent reproduced it, but I see that in Parser there a few comments about detecting errors, so
maybe it's expected behaviour?

User's query was:

"insert $m1 isa maintainer, has identifier ${m1}, has name 'M1';
insert $m2 isa maintainer, has identifier ${m2}, has name 'M2';"

Expected Output

Meaningful error message

Actual Output

image

Additional information

Here errorListener.toString() seems to return empty.

Unintuitive error when trying to insert an attribute without a value

This issue was originally posted by @jmsfltchr on 2018-08-31 12:51.

Encountered an unintuitive error message when loading a gql file.

 define name sub attribute datatype string; 

Given the above, when making the below (incorrect) query, the user should be told more explicitly that they didn't provide a value for attribute name.

 >>> insert $n isa name; INVALID_ARGUMENT: GraqlQueryException-missing expected property `` in `$n isa name`. Please check server logs for the stack trace. >>> 

Server log:

 2018-08-31 12:04:07,885 [grpc-default-executor-46] ERROR a.g.e.r.SessionService$TransactionListener - Runtime Exception in RPC TransactionListener: ai.grakn.exception.GraqlQueryException: missing expected property `` in `$n isa name` at ai.grakn.exception.GraqlQueryException.create(GraqlQueryException.java:89) at ai.grakn.exception.GraqlQueryException.insertNoExpectedProperty(GraqlQueryException.java:211) at ai.grakn.graql.internal.query.executor.ConceptBuilder.useOrDefault(ConceptBuilder.java:339) at ai.grakn.graql.internal.query.executor.ConceptBuilder.use(ConceptBuilder.java:355) at ai.grakn.graql.internal.query.executor.ConceptBuilder.putInstance(ConceptBuilder.java:415) at ai.grakn.graql.internal.query.executor.ConceptBuilder.tryPutConcept(ConceptBuilder.java:247) at ai.grakn.graql.internal.query.executor.ConceptBuilder.build(ConceptBuilder.java:184) at ai.grakn.graql.internal.query.executor.QueryOperationExecutor.buildConcept(QueryOperationExecutor.java:270) at java.util.HashMap.forEach(HashMap.java:1289) at ai.grakn.graql.internal.query.executor.QueryOperationExecutor.insertAll(QueryOperationExecutor.java:256) at ai.grakn.graql.internal.query.executor.QueryOperationExecutor.insertAll(QueryOperationExecutor.java:102) at ai.grakn.graql.internal.query.executor.QueryExecutorImpl.run(QueryExecutorImpl.java:84) at ai.grakn.graql.internal.query.InsertQueryImpl.stream(InsertQueryImpl.java:81) at ai.grakn.engine.rpc.SessionService$TransactionListener.query(SessionService.java:235) at ai.grakn.engine.rpc.SessionService$TransactionListener.handleRequest(SessionService.java:142) at ai.grakn.engine.rpc.SessionService$TransactionListener.lambda$onNext$0(SessionService.java:117) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 

Analytics starting with a match query

This issue was originally posted by @haikalpribadi on 2018-04-12 13:47.

Improve analytics syntax, pass a match query as subgraph.
e.g. degree:

match 
$x isa person; 
$y isa movie; 
($x, $y) isa has-cast; 
compute degree; persist true;
graql.match(
var(“x”).isa(“person”), 
var(“y”).isa(“movie”), 
var().rel(“y”).rel(“x”).isa(“has-cast”)
).compute().degree().execute();

This can NOT be done with the current version with TinkerPop.

Make Variables be independent Statements

At the moment, whenever we want to provide a variable into a Statement builder, we must construct a full Statement object that only contains that one Variable. For example:

type("marriage").relates(var("x"))

In the case above, Graql.var("x") returns a Statement object, in which StatementTypeBuilder.relates() accepts.

This is problematic for various reasons:

  • Wherever a query builder expects a variable, the user can pass a Statement with more information leaked into the query, which may not be semantically correct
  • We cannot differentiate different scenarios of query building, for example:
    • A concept type has a type followed by a default value: type("person").has("age", 0)
    • A concept type has a var cannot be followed by anything: type("person").has(var("x"))

Unhelpful syntax error when accidentally using TypeQL keywords

This issue was originally posted by @haikalpribadi on 2016-10-13 16:22.

define 
rel sub relation, relates has;
                          ^
mismatched input 'has' expecting {'get', 'thing', 'entity', 'attribute', 'relation', 'role', 'rule', 'offset', 'limit', 'sort', 'value', 'contains', 'group', 'count', 'max', 'min', 'mean', 'median', 'std', 'sum', VAR_, LABEL_}

Unify neq predicates with negation

The following table depicts the possible predicates together with their neq and negated versions.

Predicates in brackets are currently not supported.

--- Predicate neq Predicate NOT Predicate
IdPredicate $x id '...'; $x != $y; $y id '...'; NOT $x id '...';
IdPredicate ($x = $y;) $x != $y; (NOT $x = $y;)
ValuePredicate $x == '...'; $x !== '...'; NOT $x == '...';
ValuePredicate $x == $y; $x !== $y; NOT $x == $y;

The idea is to unify the neq and negated versions where possible (especially for ValuePredicates where we can simply rewrite them).

Caveats:

  • to unify the behaviour of neq IdPredicates with negation we need to introduce an equality IdPredicate

Related issue: vaticle/typedb#4528

Graql: distinguish between type clash in file vs schema

This issue was originally posted by @jmsfltchr on 2018-07-09 20:47.

If you make the mistake of already having a concept defined in your keyspace, but try to load a file that declares that concept to have a different type, you get a slightly cryptic error message, like:

 The concept [Base Type [ENTITY_TYPE] - Id [V28736] - Label [led-observation] - Abstract [false] ] is not of type [interface ai.grakn.concept.RelationshipType] 

Allegedly, we should be able to distinguish between a duplicate definition in a file and a pre-existing concept in the current schema.

Finalise definition of unbound variable in predicates

A runtime match clause check is being executed on the server which ensures that a query with comparisons that may be n^2 is not allowed without further information, such as match $x != $y or match $x !== $y, x and y could be considered unbounded outside of comparison here.

Further questions that stem from this:

  1. Should we allow match $x == "john" - arguably yes, $x has a precise value, though no type information. Is it bounded though?
  2. Consider match $x != "John" - is this unbounded and allowed (along with other non-equality checks such as > and < ?)

Misleading syntax errors generically using "expecting {'match', 'define', 'undefine', 'insert', 'compute'}"

Description

In many cases, TypeQL returns syntax errors that correctly identify the location of the syntax error, but make a generic and incorrect suggestion for how to fix it.

Environment

TypeDB version (and platform): Core 1.4 upwards

Reproducible Examples

  1. Correct query: insert $e isa d-entity, has d-key 1;, missing a comma
insert $e isa d-entity has d-key 1;
Error: syntax error at line 1: 
insert $e isa d-entity has d-key 1;
                       ^
mismatched input 'has' expecting {'match', 'define', 'undefine', 'insert', 'compute'}
All uncommitted data is cleared
  1. Correct query: define my-bool sub attribute, datatype boolean;
define my-bool sub attribute, datatype bool;
Error: syntax error at line 1: 
define my-bool sub attribute, datatype bool;
                                       ^
mismatched input 'bool' expecting {'match', 'define', 'undefine', 'insert', 'compute'}
All uncommitted data is cleared
  1. Correct query: insert $m isa my-bool; $m false;
insert $m isa my-bool false; 
Error: syntax error at line 1: 
insert $m isa my-bool false; 
                      ^
mismatched input 'false' expecting {'match', 'define', 'undefine', 'insert', 'compute'}
All uncommitted data is cleared
  1. This example even gives an even stranger message. Correct query: define $m isa my-entity, has name; name sub attribute, datatype string;
define my-entity, has name; name sub attribute, datatype string;
Error: syntax error at line 1: 
define my-entity, has name; name sub attribute, datatype string;
                ^
no viable alternative at input ','
syntax error at line 1: 
define my-entity, has name; name sub attribute, datatype string;
                ^
mismatched input ',' expecting {'match', 'define', 'undefine', 'insert', 'compute'}
All uncommitted data is cleared
  1. Query : define rel sub relation, relates has; (uses a keyword as role)
define
  rel sub relation, relates has;
                                                                          
[TQL03] TypeQL Error: There is a syntax error at line 2:
rel sub relation, relates has;
                          ^
mismatched input 'has' expecting {'get', 'thing', 'entity', 'attribute', 'relation', 'role', 'rule', 'offset', 'limit', 'sort', 'value', 'contains', 'group', 'count', 'max', 'min', 'mean', 'median', 'std', 'sum', VAR_, LABEL_}

Expected Output

In each case, the suggestion expecting {'match', 'define', 'undefine', 'insert', 'compute'} is misleading. In all of these cases using these options is not valid. Ideally, the user should be prompted with all of the possible options that they could use instead at the point where their syntax is incorrect. At the least, they should be simply told the location of their syntax error, and not misguided.

Introduce plays! and relates! and owns! to query direct connections

Description

We would like to be able to query directly played/related/owned types, without inheritance.

match $p isa person; $r($t: $p) isa employment; $t plays! employee; get $t;

The exclamation mark raises an error.

Additional information

It would be nice if this were possible and returned only the directly owned/related/played connections and excluded the inherited ones.

Semantics of rule subtyping if allowed

Currently, rules look like any other schema type (eg. Entity, Attribute, Relation). This leads to confusion because they are defined the same way as these types, eg define newrule sub rule..., which implies that they may be written in hierarchies themselves. However, we do not have any meaning ascribed to subtyping existing rules.

Core questions:

  1. What does subtyping of rules mean semantically? Currently, it is allowed syntactically
  2. Should we even allow subtyping rules?
  3. A rule is not a concept type (we have no rule type instances, only exist on the schema level for now). So really should a rule even exist in the same hierarchy of Thing that it sits in now?

utf-8 support in Graql

Problem to Solve

At the moment Graql does not support utf-8 labels like
define Kläger sub entity; or define übermorgen sub relation;
but it'd be great if it would. This would allow non english "non-techies" a easier interaction when they trying to model with GraKn.

Current Workaround

I'd would need to create an extra Layer in my NLP-Lib to change German Words that describe certain entities or relations to replace äöüÄÖÜ and ß with another representation. But it would highly decrease readbility and acceptance with my target audience.

Proposed Solution

Support utf-8 as type labels (or in Graql in general)

Graql: Move SUB behaviour from SchemaConcept to Type

This issue was originally posted by @haikalpribadi on 2018-01-05 17:22.

Roles will subclass each other using the new as syntax, and rules will not be subclassable to begin with.
The problem that we need to sort out before implementing this is: how do we query for roles and rules in match queries? Thus, we need to design the new syntax for it.
After this, we should consider removing the meta role and rule.

Make query language more English-like

Problem to Solve

Graql is still a bit terse for some instances, especially when the rule definitions start becoming more involved. SQL is quite English-like but can become verbose, Graql expresses a lot of the same definitions in shorted constructs but maybe some improvements can be done to meet half-way.

Current Workaround

Learn the constructs and get acquainted with the language.

Proposed Solution

Constructs can be arranged in more like a sentence format: subject-verb-object, subject-verb, a number of improvements can be achieved by just rearranging the constructs or maybe renaming them.

From a technical perspective, it could mean extending or enhancing the parser to understand different formats or maybe extending the vocabulary so it knows more words or similar words. End-users could use the existing format or the new proposed format when writing Graql.

Additional Information

I'm happy to suggest literal improvements if you can point me to a resource which lists the lexicon/constructs of the Graql language and some examples of usages.

By making Graql more English-like we could definitely help this idea: vaticle/typedb-studio#153 (I have raised this to help the current idea from the other perspective).

attribute with datatype of string doesn't accept a string containing a slash

Grakn version: 1.5 SNAPSHOT

define

title sub attribute,
  datatype string;

insert $x isa title; $x "/";

Expected outcome:

the new instance of attribute title to be created with value "/".

Actual outcome

Error: syntax error at line 1:
insert $x isa title; $x "/";
                        ^
token recognition error at: '"/'
syntax error at line 1:
insert $x isa title; $x "/";
                          ^
token recognition error at: '";'
syntax error at line 1:
insert $x isa title; $x "/";
                            ^
no viable alternative at input '$x '
syntax error at line 1:
insert $x isa title; $x "/";
                     ^
extraneous input '$x' expecting {<EOF>, 'match', 'define', 'undefine', 'insert', 'compute'}
All uncommitted data is cleared

Sample issue

Will be closed immediately to test the webhook

Nested patterns

This issue was originally posted by @haikalpribadi on 2016-10-12 11:03.

Problem to Solve

An example of a simple query involving a single relation:

match
(director: $jc, $m);
$jc has name "James Cameron";
$m has title $t;
select $t;

While queries such as the above are clear in their meaning, they take time to type and for users to parse. Experienced users may find it frustrating to repeatedly type these queries out.
This could be resolved by allowing nesting or "inlining" roleplayers, turning this into a one-liner:

match (director: has name "James Cameron", has title $t);

So the above would find titles of movies directed by something with name "James Cameron".
Unfortunately, if we were to allow this nesting of roleplayers then the above becomes ambiguous to parse. It's not clear whether another roleplayer has title $t, or if James Cameron has title $t.
This ambiguity is because commas are used to separate roleplayers, but can also optionally be used to separate properties.

Proposed Solution

Remove optional commas

This can be resolved by not allowing separating properties with commas.
This can lead to ugly one-line statements:

movie ako production plays-role production-with-cast has-resource title;

However, in practice, people are not using the commas anyway. They are instead writing the above like this:

movie ako production
  plays-role production-with-cast
  has-resource title;

See moogi and pokemon for examples.

Separate roleplayers with a semicolon

Another choice is to use semicolons to separate roleplayers:

match (director: has name "James Cameron"; has title $t);

Semicolons are already being used to separate variable patterns, so it makes total sense here. The only issue is that semicolons inside brackets might look strange.

Strictly speaking, there should be a semicolon after the last roleplayer too, but it looks really, really bad so let's not:

match (director: has name "James Cameron"; has title $t;);

Braces

Another option is to require braces (or similar) around nested properties:

match (director: {has name "James Cameron"}, {$x isa movie});

This is not particularly pretty, but fairly consistent with our use of curly braces to nest queries already. It also allows us to nest variables anywhere. For example, instead of:

match
$x isa $y;
$y plays-role actor;

we can say:

match $x isa {plays-role actor};

Mandatory variable names

Another is to always require a variable name for a roleplayer:

match (director: $y has name "James Cameron", $x isa movie);
select $x;

This eliminates one of the major benefits of the syntax: not requiring a variable name can allow for much shorter queries, by avoiding unused variable names and pointless select statements, such as select $x above.

Comparison example

"titles of movies directed by James Cameron":

Old syntax:

match
(director: $jc, $m);
$jc has name "James Cameron";
$m has title $t;
select $t;

Disallow commas:

match (director: has name "James Cameron", has title $t);

Separate roleplayers with semicolons:

match (director: has name "James Cameron"; has title $t);

Braces:

match (director: {has name "James Cameron"}, {has title $t});

Mandatory variable names:

match
(director: $jc has name "James Cameron", $m has title $t);
select $t;

Ontologically invalid queries should not be allowed. See example.

This issue was originally posted by @haikalpribadi on 2017-04-24 13:31.

 match $a isa cancer; ($a, $b); $b isa mirna; ($b, $c); ($c, $d); $d isa gene; ($d, $e); $d isa drug; offset 0; limit 3; 

In the query above, I defined $d to have two types (that are not an abstraction of one another). This query should not be allowed: a) it should return an error that explains why. b) it should not try to execute the traversal.

Rename `asUserDefined`

The naming for asUserDefined variables is very confusing - it actually means whether or not to retrieve the variable as part of the answer.

Propose renaming var.asUserDefined() and var.isUserDefinedName() to var.asRetrievedVar() and var.isRetrieved().

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.