This might be a big ask, but would it be possible to add properties to relationships as well as entities (like is possible with a graph database)?
I realise that the more sophisticated you make the underlying platform, the greater the risk of users being scared away by the complexity, but for me, it would put you into a whole different league.
It could be a feature that can be enabled but is disabled by default so as to not scare non-techies…
4 Likes
Chris, intriguing. As a non-techie, could you provide some hard example of how this would work? I am all for being able to slice and dice data as much as possible in Fibery, which is already packed with opportunity to do so at this early stage!
Thanks!
Hi B_Sp,
Well, I’m not sure if you’re asking for examples of how I would use it, or my suggestion for how it could be implemented in Fibery, so I’ll tell you both 
Example: If I want to have a bill of materials, one way of doing it might be to define an entity type (‘Part’) and create a one-to-many relationship to itself (with the names ‘Consists of’/‘Used in’) and where this relationship has a property ‘quantity’.
So…
Part A - Consists of (Qty:2) - Part B
Part A - Consists of (Qty:1) - Part C
Part B - Consists of (Qty:100) - Part D
Part B - Consists of (Qty:2) - Part E
Of course, with this information, there’s loads of things you can achieve, like working out cost of goods. If each Part has it’s own direct cost, then the cost of any sub-assembly can be calculated using a (recursive) formula like 'TotalCost = Part.Cost + sum(ConsistsOf.Quantity x ConsistsOf.TotalCost)
[Note: this is not supposed to be correct Fibery formula syntax!]
The only way I have found of currently achieving this (and other similar examples) is to create an intermediate entity type that acts as a bridging entity, with the properties I need to include.
In terms of how it could actually be done in Fibery, I was thinking that it would just be a series of properties that are defined when the relationship is created (and ideally be reconfigurable later, although I realise that may add complexity - I note that the relationship type can’t currently be changed after creation).
Hope that makes sense, and any thoughts/comments welcome.
1 Like
Hey Chris, that’s a great write-up, thanks! I am in Fibery due primarily to the powerful relations, so I could easily see Michael & co working on this down the road. Good to have this request up here!
I’ve actually come across this need again.
This time, it relates to using Fibery to track production processes. I want to be able to define a process step type (corresponding to a single step in the overall production process). Most process steps consume raw materials and produce output. Since I have a type representing materials/components/parts/sub-assemblies etc. I can link a process step to the materials/components consumed and the part/sub-assembly being produced. but it would be ideal if the relationship had an amount property, so for example, the process step ‘plastic moulding’ is related to:
- the raw material ‘ABS plastic’ with the value -20, representing consumption (in grams or whatever is the base unit defined for ABS)
- the plastic part ‘widget’ with the value +1, representing production (of a single unit of widget)
The nice thing is that from this setup, I can further define a type which is ‘process step occurrence’ representing a record of that process step being carried out (with a date field, and maybe an operator field, or a company field) and I can use formulas/charts to maintain/calculate a historical record of consumption/production + net stock levels
1 Like
…and while browsing these forums, I came across this:
I think there is a genuine need here, but maybe a lot of use cases can be solved with a few basic properties (text, number, single-/multi-select, date, checkbox) without needing all the more sophisticated fields types that an entity supports (relations, formulas, extensions, etc.)
That would definitely keep me happy!
I know michael said,
so I’m keeping my fingers crossed 
1 Like
When I read this, I recall configuring this on UML Class diagrams, while using ArchGenXML to generate content types on Plone. Specifically, here’s the bit on reference classes. This was 10+ years ago.
UML diagrams already have some resemblance to Fibery App diagrams 
I’m so glad this thread was resurrected because I was just about to post the exact same request
I think the ability to add properties to the relationships is very useful and important as well. One of the easiest examples I can think of are contacts/people entities. It is currently possible to define a many-to-many relationship between a contact entity and itself to define “related people”. However, it is not possible to say how two contacts are related to each other. That is to say, are they co-workers, family, friends, etc.
This will also be a good solution to another issue I raised earlier regarding denoting if an entity of one type is the same as another entity of a different type (semantic same as relation).
The example of parts is also very instructive as I can see it extended to area of physical asset management to define parts and assemblies to allow managing of maintenance records, etc.
An implementation of this should allow for one and two way edges that can ideally allow you to define a relationship between a brother and a sister very precisely (i.e. instead of a generic sibling relationship, allow to you same John is Mary’s brother and Mary is John’s sister). It would be also fantastic to be able to define these relationship types in a systematic way using a thesaurus/defined vocabulary that supports import/export. Finally, ability to query/search/filter based on this would be needed to make this useful at scale.
I am not sure if the underlying datastore for Fibery is graph-enabled, but I think having graph functionality is going to be critical long term.
2 Likes
This is something that came to my mind awhile back when trying to work on our data model. Currently, as @Chr1sG pointed out, you need some intermediate type to describe the role or any other special attributes associated specifically between two types, which isn’t easy to manage in Fibery because you can’t easily edit multiple fields on a related entity from the entity view. You would create each entity to map between the types, then you have to open that bridging entity and set the values on it.
If you consider something like JIRA and how it can have Issues associated with other Issues with Depends On, Blocks, Blocked By, etc. This tells you more than just having them all equally related. To represent the same information in Fibery, you’d need to have that separate joining table, or you’d have to create a relationship between Issue and Issue for each relationship type you want to represent.
This is somewhat related to More Flexible Board Columns/Rows because in general Fibery seems to heavily penalize you for using many to many relationships, since they can’t be utilized in multiple visualization types for grouping, nesting, etc. I think if something like this was supported, then the views might need some thought on how to show the information effectively.
4 Likes
Actually, I have a completely different use case but similar approach as @Chr1sG is asking for.
If you’re taking a value engineering type approach to product development, you may want to refer to certain measures/scales from a feature request (benefit hypothesis). For example:
Due to <insert insight fact here - e.g. reported customer issues>
We believe that <this bet / feature / improvement etc.>
Will result in < this outcome >We will know we’re on the right track when…. <refer to MEASURE_1 (e.g. number of call center calls on a certain problem) > and and so on
Current Value of <MEASURE_1> = _______ Goal Value of <MEASURE_1> = __________
Are you seeing where this is going? Suddenly you can make product prioritizations much more objective and base it on REAL values (governed in some Fibery table or app). However, we would like to define attributes ON a relationship between Feature —> Measure.
2 Likes
That’s an interesting example, thank you!
Have you settled on this approach in your company? I’ve seen folks describing models like this one, but I haven’t seen one in use yet. Would love to hear about your first-hand experience.
1 Like
Hi @antoniokov - not settled, but we’re defining our target framework at the moment.
I mean, one way one could get around it would be by defining these MEASURES fields per app or per entity. But even so, you would be missing the ability to define GOAL and RESULT (after, say a product/feature experiment) separately.
Just wanted to bump this one.
There are just so many use cases where a relationship property would allow very rich information without overcomplicating the model.
e.g. How much is a Product/Solution Capability dependent on Component A?
e.g. Teams Skill mapping: To what degreed does a require (and/or have) which skills/knowledge ? (Think Team Topologies)
and so on.
Would this be a real fundamental change to your data model or is the interface more of a challenge? Would love to hear whether you also see this as a great differentiator in line with Fibery’s proposition… 
6 Likes
As a social systems developer, I am a huge fan of relationship properties, since they reveal the meaning in relationships, and much more information is available to work with in analytics.
I have tried to workaround this in Fibery using an entity type with endpoints A and B and automation buttons, but it is cumbersome and does not really work well in practice.
I think that the idea of relationship properties is very well aligned with the character and value of Fibery and will bring Fibery to the next level of interconnectivity and analysis of data.
1 Like
Related, although that development focuses on in-text references, some architecture may be useful for potential Relations as entities (Relations Reloaded ;-)):