Comments (8)
There's a big difference. If I say that I want something to play group-membership:member
then I don't want it to be able to play membership:member
or member
in other subtypes of membership
.
from typeql.
The final behaviour here was discussed and implemented.
- Role types are now concrete separately from their relations' abstractness, therefore inheritable and reusable (vaticle/typedb#6885)
- Inherited role types are no longer allowed to be accessed via alias in the sub-relation type (vaticle/typedb#6916)
Given
define
employment sub relation, relates employee;
part-time-employment sub employment;
We now disallow
define
person plays part-time-employment:employee;
Since part-time-employment:employee
is an alias for employment:employee
Previously, allowing this plays would actually implicitly allow playing other types of relations that inherited emplyoment:employee
as well, such as for example non-profit-employment sub employment
, even though a person maybe only should be restricted to part-time-employments
in a model.
- We disallow creating a sub-role type with the same name to avoid confusion and ambiguity in the following use case (pre-existing behaviour)
define
multi-employment sub employment,
relates employee-1 as employee,
relates employee-2 as employee,
...
relates employee as employee;
Here, querying match (employee: $x) isa multi-employment
is ambiguous we either want to query for specifically the new 'employee' in multi-employment
or all employee-*
in multi-employment
(via subtyping).
Another way to see this from a set semantics is that we can see multi-employment
as sharing (ie being a subset) of employment
- therefore we can ignore the scoping of role types when considering role names. In this model, calling a subtype employee
while the parent is employee
is as confusing as naming an attribute supertype name
and its subtype name
as well. If they have the same name, they should occupy the same 'space'.
The solution to this is create a new role type when you want to carve out a subset specific to the relation subtype.
define
multi-employment sub employment,
relates employee-1 as employee,
relates employee-2 as employee,
...
relates multi-employee as employee;
from typeql.
Related issue: #203
from typeql.
This issue might also be related: vaticle/typedb#6534
from typeql.
i agree this is an important logic problem. Roles are not always a logical sub-set of a larger role, and in fact sometimes the roles are the same. This is really due to the construction of language, and TypeQL should allow this since the role is always fully qualified (ie. it is called with the relation name as well)
from typeql.
define
# not abstract
membership sub relation,
relates parent,
relates member;
group-membership sub membership,
relates group as parent,
relates member as member;
This one - i agree it might be nice but how important is it to actually have group-membership:member
and membership:member
being different role types? This is much harder to implement than allowing abstract relations to have concrete role types inside them :)
from typeql.
Humm okay, interesting. Not sure that one will be coming yet, have to think about it more
from typeql.
Note: for abstract relations/roles, we will want to be able to do something like this:
request sub relation @abstract,
relates subject @abstract,
relates requester,
relates respondent;
from typeql.
Related Issues (20)
- Allow nested negation and universal quantification in rules HOT 3
- Allow binding of ownerships to anonymous variables in query patterns
- Ignoring repeated constraints
- Support modifiers (at least the limit) in all type of queries HOT 3
- Using standard form for numeric literals throws an error when parsed HOT 5
- [Feature Request] More operators and basic functions HOT 1
- Make annotated constraints to apply to subtypes HOT 4
- Allow negations and disjunctions without an exterior binding
- Unary negation
- Factor out typedb-common and typedb-proc-macro crates
- Sanitize rust macros to avoid forcing user's environment
- Give relation and value constraints explicit keywords
- Add deployment tests for Cargo and Pip snapshots
- Introduce a syntax element to explicitly end a query string
- Plays-as overrides break schema export
- Fetch: add a way to project an item into a list of attributes by label HOT 1
- Introduce syntax for interface covariance HOT 2
- Composition of interface implementations as high-level abstractions (traits)
- Allow casting of type variables to value variables HOT 3
- Ability to define metadata for types without replicating the information across all type instances
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typeql.