Hi @krishnan
Hi @krishnan
Thank you for the help. I am revisiting your sample schema.
I understand the first part, and I rewrote it to the below working query.
it works pretty well.
So with this, for any attribute XXX, I just need to attach a relation called attributed-XXX and then I can define the attribution. Very neat.
I am also wondering, should
attributed-ipo-date
uses relate
for ipo-date, so that when ipo-date attribute got deleted/changed, this relation attributed-ipo-date
can be deleted as well? I want the attribution go away with the referenced ipo-date attribute and referenced entity instance go away.
============
But I don't understand the second example. I kept getting error with the second approach in your comment.
Can I have a full, working implementation of the second approach? I am not sure if I understand this.15 Replies
A related question is, for the relation
attributed-ipo-date
, I want it to be auto deleted when say, the owned ipo-date got deleted or replaced.
Also, if it is an entity actually owning ipo-date, say it is a company entity owning ipo-date. I observe that, if I delete the company entity instance, the attributed-ipo-date
relation seems to remain.
==================
They are a number of items I want attribution for
- an entity' attribute (e.g. a company's ipo-date comes from a news article)
- a relation between entities (e.g. the contractual relation between company A and company B comes from a news article)
How can I use the construct you suggested to achieve the attribution?Adapted this to commit:
define entity company, plays AttributedOwnership:Owner;
Now deleting the company turns any AttributedOwnerships it plays the owner role in to have 0 role-players and get cleaned up. You could tighten AttributedOwnership:Owner
to be @card(1)
as well.
a relation between entitiesThis will be harder to achieve, but we were meant to introduce an
@cascade
at some point to allow cleaning up relations if any role fell below cardinality requirements.
For now, you may have to garbage collect
Oh hold on, I've fallen out of context here. I don't have the attribution do I?
In that case you'll need to run a GC query even for ownerships.@krishnan
Following up on this, so @cascade is not yet implemented?
https://typedb.com/docs/typeql/annotations/cascade

I don't think it is implemented. It's non-trivial since it does cascade (potentially deleting a huge number of relations) but might not be tooooo hard to implement either
Understood.
btw, what's the current behaviour when a relation relates multiple entities, and one of the entities got deleted?
For relation attribution, I wonder if I can do this
say now I have
if now I delete $companyA, does the has-agreenent relation instance still exist?
Yes, it should still exist.
Oh wait, You'll get a cardinality violation error and the commit will fail
Oh. I see. because the cardinality constrains it to at least 2 instances. OK
what if I delete $source ?
does the relation instance has-agreement still exist?
It should.
How do I achieve this?
Say I make the source role mandatory. When I delete a source instance, I want all relations with the source instance to be deleted
I dont want anything unattributed to any source.
If I deem a source to be bad, I want to get rid of all the data associated with said source
Can you do it manually for now?
Can you give me the manual typeQL?
Oh. that makes sense. Thanks!
that's actually easy to read!
It is nice isn't it?
Thanks for helping me out with designing this attribution-enabled graph.
Spent so many days figuring out stuff.
My takeaway:
- entity-owns-attribute attribution: A relation which relates an entity, relates a source and owns the attribute
- relation-attribution: In existing relation, add a relates source role. then done