Wouldn't your desired approach require
Wouldn't your desired approach require declaring the plays for all 1000 attributes?
Or do you just declare it once on a supertype and the plays is inherited?
15 Replies
I'm not sure I understand @krishnan .
Say I have my core attributes (i.e. the common ones before defining any actual objects) defined as follows:
and additional attributes just add onto that list. Assume there are 1,000 attributes and 120 composite objects, which could have the granular marking relation applied.
Assume that the granular marking needs to be an optional component on the Fetch statement for the 120 objects.
How should this work in practice???
Do I have to define the granular marking as possibly having any one of the 1,000 attributes??
So how is the granular marking relation defined then?
I'm likely missing something.
How can i model this, since i cant attach a relation to any attribute, so how do i refer to them??I assume this means you know how to do it if you were allowed to attach attributes to relations? Can you show how you do it in this case? Because Georgii's suggestion made sense to me, and I thought it would be an easy translation of your existing solution.
The issue with this solution is that assuming I have a thousand different attributes across all of the value types, then i need to define the granular marking relation in the schema with all 1,000 attributes, which seems an ugly solution to implementI was wondering how you would have avoided this ugliness, had you been able to attach attributes to relations. I might be best off leaving this to Joshua since he's neck deep in stix. Although I am guilty (as you've often charged) of thinking in terms of toy-datasets, I find it a little hard to believe that the best way to model any real-world system involves an entity owning thousands of attributes. On the other hand, I think your scale is intriguing and would love to see if you can do some meta-programming somehow and let TypeQL do the work that your query generators are currently doing.
Oh, my old v2 model was beautiful and very elegant
The relation and attribute side are done in one or two lines, like
So the relation is defined in two lines, and the roles are attached to the attributes and the objects, and it all just works prefectly.
This idea of making the relation own every attribute seems like a nightmare.
Thoughts ?
and @Joshua ?
GitHub
Stix-ORM/stixorm/module/definitions/stix21/schema/cti-schema-v2.tql...
Contribute to os-threat/Stix-ORM development by creating an account on GitHub.
This is the problem. The v2 was beautiful and concise, and the v3 looks like a nightmare
If you search for "granular-marking" in the above schema, section (there are an additional 3 sections) you will see the term is only used 4 times, and the definitions is so terse, its amazing.
Groan, what a terrible decision not to enable attributes to play roles, imho, that was a giant step back for TypeQL for heaps of cool use cases, such as:
- granular markings
- IAM-based recording of access,
- etc.
So the role I'm interested in is
granular-marking:marked (or rather, data-marking:marked)?
I see what you're doing - You allow any attribute to play marked by just declaring your n base attribute types to play it.
I just need to figure out why you can't do the same for Georgii's solution. Is it because owning a supertype of an attribute doesn't mean ownership of subtypes of the attribute is inherited? (v/s the attribute playing a role does mean subtypes of that attribute inherit the ability to play that role)If you guys can make it that elegant, i am all up for it. I still think its a strategic mistake not enabling attributes to play roles, as the v2 solution worked a treat.
Over to you and @Joshua, @christoph.dorn and crew to work out a solution.
I dont need it tonight, but some time over the next few days would be good, so its better to discuss it amongst the team
Thanks mate
No rush, better to get it right, and elegant imho
Quick question though:
Is there no stronger-typing rule for
marked? i.e. Can any stix-object type be marked by any stix-attribute type?Well, I wasn't as strong on constraints when i first designed the schema, so it is admittedly a bit lax
I juset opened the doors to everythoing, and then i use my Python clsses in the ORM to handle constraints
My nose says getting stronger constraints is the way to elegance, but I can leave that to Joshua since I have 0 stix domain knowledge.
In a way, this is also a challenge to @christoph.dorn , since taking away the ability for attributes to play roles has signifcant limitations in high end applictions
Well you'd need to provide an example which demonstrates this.
My counter-challenge to using the stix schema you've linked as counter-example is that I don't think it's tightened enough. The fact that you require declaring 1000s of ownerships may well be a positive for TypeDB - i.e. it penalises you for keeping things too open.
The applications for an attribute playing roles are in secure environments, where one wants to mark which attributes have been read, edited, updated or deleted, by whom (IAM) and when. TypeDB cant do this application anyomore unfortunately
plus obviously granular markings, on any attribute
markings for language, or other purposes
There is a data warehouse model for this called Arrow modelling
Right, I see what you mean.
Going to the SQL way of seeing things though, can't you just mark the modification on the owner?
I agree it's counter-intuitive since we're the PERA model where attributes are supposed to be first-class citizens. You're spot on with that.
With an atomic data model, one needs to mark atoms for various purposes, including recording CRUD actions
that seems like a fairly obvious statement
its not just what entity was looked at, but which parts
some attributes could be marked SECURE, and thereby dependent on IAM
marking entities and relations is a very coarse measure, and does not enable varying security on pieces of data
this is the function of granular markings, where some attributes may be marked SECURE or PRIVATE
Marking the entire entity or relation is known as an Object Marking, whereas marking at the attribute level is a Granular Marking. Quite distinct and TypwQL no longer supports it