The schema validation does not throw an error for a relation configuration that seems to be wrong to me. Correct behavior?

TypeDB
1

Hi all,

I am testing several schema configurations and was interested whether a relation that inherits from another relation and overwrites one of the relates roles could a) still play a role in the parent relation and b) even play the role it itself overwrites. My schema initialization works without an error, so I was wondering whether this is actually intended behavior. I would be happy to hear your thoughts on this.

My schema:

define

credential sub attribute, abstract, value string;
credential-small sub credential, abstract, value string;
credential-smaller sub credential-small, value string;
full-name sub attribute, value string;
id sub attribute, abstract, value string;
email sub id, value string;
long-name sub id, value string;

impact sub relation,
    abstract,
    owns credential, 
    owns full-name,
    relates impactor, 
    relates impacted;

impact-small sub impact,
    owns credential-smaller as credential,
    relates impactor-small as impacted,
    plays impact:impacted;
2

Hi, there is absolutely nothing wrong with this schema. Attribute ownerships and roles in TypeDB function as interfaces. This means that they can be independently implemented by any types, in keeping with interface polymorphism.

In this schema, you have three role interfaces:

  • impact:impactor
  • impact:impacted
  • impact-small:impactor-small, a subtype of impact:impacted*

Once these role interfaces are defined, they can be made to be played by any entity or relation types, even the relations they are the interfaces of, using the plays keyword.
You can read a bit more about the checks that take place during schema validation in the docs.

* Are you sure this is correct? Did you mean to override the other role?

1 Like
3

Amazing, this makes total sense. Thanks for the quick reply! :slight_smile:

4

I hope you do not mind me asking another question. I was just wondering, when a child attribute of an abstract attribute, which is declared as @key in an abstract relation (or entity), overwrites this parent key attribute, will it also be a key? And does the same apply to “unique” attributes?

Here is an example:

define

credential sub attribute, abstract, value string;
credential-small sub credential, abstract, value string;
credential-smaller sub credential-small, value string;
name sub attribute, abstract, value string;
full-name sub name, value string;

impact sub relation,
    abstract,
    owns credential @key,
    owns name @unique, 
    relates impactor, 
    relates impacted;

impact-small sub impact,
    owns credential-smaller as credential,
    owns full-name as name,
    relates impactor-small as impacted,
    plays impact:impacted;

So, will “credential-smaller” also be a key attribute? And full-name unique?

5

Great question! I believe the key and unique constraints should still apply. Perhaps @krishnan can verify?

1 Like
6

Yes. credential-smaller will be a key.
When you override an ownership, the annotations @key and @unique are ‘inherited’.

So if you have

animal owns name @key;
dog sub animal, owns dog-name as name;
cat sub animal, owns cat-name as name;

Then dog will have dog-name as @key, and cat will have cat-name as @key - But it is possible that a dog and a cat can share a name. So animal does not really have name as @key.

1 Like
7

Great, that makes perfect sense!