Transclusion and reference are two ways to include content into another document, each with advantages and disadvantages.
Transclusion offers greater flexibility as it allows you to modify the included content in any place and reflect those changes in all the locations where it is transcluded. This is because the included content is inserted into the target document rather than just being linked.
Reference, on the other hand, is less flexible but ensures the preservation of the source of truth.
I understand your use case, but it appears to differ from the information-gathering use case we focus on. Transclusion would be addressed as a separate project.
That makes sense. To me, and I think the same for others, having it SHOW the content is much more important than having it inline editable everywhere, though perhaps also out of scope, if that helps clarify.
It is very interesting to hear that you are exploring this. This is actually missing in almost all of the tools within TFT space. I think assigning weighting to references is a very specific case of attaching data/properties to links/edges. So I would argue that reimagining references based on a more flexible/generic property graph approach would provide the most benefit. Even if the details of implementing properties on a references is a big ask, I think building on a model that allows for that in the future is a better approach.
I think having the ability to transclude/embed blocks of content across entities/documents is one of the major shortcomings of fibery at the moment, if you are using it beyond a database/airtable substitute (i.e. if you want to use fibery to its full potential). I find myself copy and pasting content repeatedly just to ensure the new item (e.g. meeting notes, specifications, ideas list, …) has some of the prior context in it and then having to spend time keeping the multiple versions in sync or keeping track of the latest version. Transclusion neatly resolves this.
However, I do think any effort towards transclusion should ensure that it doesn’t require the source content to be formatted in a particular way (a priori) or require modifications to it when transcluding. Both of these would add a lot of friction to the process. I discussed the issue here (responding to how early versions of blocks looked in fibery). I do think Obsidian or Roam’s approach to each bullet, line being a block/node that can be transcluded is the way to go long term.
I think this issue has come up a couple of times. I do find it immensely helpful in some context to be able to edit original content in another context. However, I do understand the concerns that it might be dangerous to do in other context. I think an easy way of dealing with this might be through settings/customization. It could be that transclusion by default just reproduces (or embeds) the content and the user/admin would have to intentionally allow editing of transcluded content (out-of-context).
as chr1sg said, the new pane’s not really an hard thing to get alternative. Currently I’m using Opera One Browser to pinned some panes. the main thing new pane need’s display something can querry like backlinks, outgoinglinks, tags, search files … as in Obsidian using right now
But i think fibery can easily handle this with some feature similar to this expand thing
The weight attribute is an implementation of the Insight Gathering use case.
We are trying to make the solution generic and flexible so that users can add more fields to the Reference database. Btw, this is challenging on the UI side.
But we are committed to nailing the Insight Gathering use case without closing the door to future use cases.
I believe that the problem is different. Access control manages who can edit specific text.
I am more concerned about editing specific text without understanding the original context. This could damage the integrity of the document. Therefore, I think that the Reference should be edited in the original context, even if the user has the right to edit the target document.
@kalman and anyone else of the design team (please share), please check this research paper about Fibery.io I made today with ChatGPT4, comparing it with other second brain apps in the context of the Fibery strategy.
Because redesigning the relations likely has major impact on the whole architecture, it will be interesting to read in that context.
And I like to know, if this implementation of ‘reference entity’ will address the issues that we have with references:
The basic functionality of references, and their current diferrence with relations, in my experience give problems in common use cases.
Short case description
When I create in-text entities (such as tasks) in rich text fields, I expect them to show up as relations in the relations field of that entity. But in-line references don’t show up as relations.
Problem: that makes in-line references useless in most cases since they lack the automatic relation to the entity.
Longer case description
The issue at hand pertains to the creation and management of in-line references within a rich text field and their subsequent representation as relationships within the system. Currently, in-line references created within a rich text field do not appear as relationships to the parent entity, leading to a disconnect between the context of creation and the standalone nature of these references. This can cause confusion and inconsistency in the workflow, as these references are not fully integrated into the system’s relational structure.
Automatic Relationship Creation: The system should be designed to automatically create a relationship between an in-line reference and the parent entity within which it is created. This would ensure that the reference is not just a standalone entity but is tied to the context in which it was created.
Visibility and Management: These in-line references should be visible and manageable within the parent entity’s relations list. This would allow users to see and manage all related entities, regardless of how they were created.
Bi-directional Links: The relationship between the in-line reference and the parent entity should be bi-directional, providing context and facilitating navigation between related entities.
Integration with Other Features: The system should ensure that in-line references are fully integrated with other features, such as search, filter, and notification systems.
This issue and the proposed solutions can be applicable in several scenarios:
Meeting Management: As mentioned earlier, during a meeting, in-line tasks created within an agenda item’s ‘description’ field should automatically become related to the agenda item.
Project Management: When discussing a project within a project entity, any in-line references created to denote tasks, milestones, or risks should automatically be related to the project entity.
Documentation: In a document entity, any in-line references created to denote related documents, sections, or issues should automatically be related to the document entity.
Customer Relationship Management (CRM): In a customer entity, any in-line references created to denote related interactions, issues, or opportunities should automatically be related to the customer entity.
By addressing this issue, developers can create a more consistent, intuitive, and powerful system that fully leverages the potential of in-line references and relationships.
We have Agenda Items that relate to Tasks and Decisions. The notes (minutes) taken are written in the agenda item entity field ‘Description’, which is a rich text field. The note taker (or the people collectively taking meeting notes) want to create in-line (in-text) tasks, which is already possible using the inline references. The entity is created automatically, using as title the selected text that is converted to the task. This is a quick way to create inline tasks which tightly maintains the context and discussion which is most relevant to the task.
Apart from that, users want to create Tasks related to the Agenda Item entity in the standard way (not in-text) in the Tasks relation field. Both actions to create Tasks need to result in the same outcome: tasks that are listed in the Agenda Item entity.
The problem is that the in-text task does not appear as a relationship to the agenda item. It basically is a stand alone tasks that contains the reference to the agenda item, but cannot be handled as a related task. This creates confusion and inconsistency in the workflow.
Hey there. Yes, I’m finding that now. I was hoping some uber-users might have workarounds but I guess it’s copy/paste for the moment. The challenge I’m having is copying and pasting in different spaces and keeping track of the proper URLs for each. I think Fibery has an amazing foundation and a bright future.
You know what I’m missing the most of all after using? A developer plug-in community. I’ve seen some really bright people posting interesting solutions and workarounds (including you!) and there are certain functionalities that I would have my team build (as apps maybe, I still haven’t gone done the path of their API enough, though it appears promising) and share with the community. I’ll check out your transclusions post.
I’ve used a few apps that identified everything as bullets and found Obsidian’s way very flexible (not bullets). However, that may simply be because I didn’t use the bullet method enough. I’m thinking of using in Docs (or whatever emulates docs) and showing things as paragraphs, etc.
I merged it here because I want to keep all related conversations in this topic. I hope you don’t mind.
Thanks for your questions.
The Reference entity has the functionality you mentioned. The feature description lists all of the fields that are needed, including:
Reference source, which is automatically added when the reference is created,
One or more reference targets,
and these will make bidirectional relationships between the source and targets.
The Reference entity will be a separate database and be integrated into the search, filter, report, and notification systems. We still need to solve some riddles before implementing your use case, but the overall goal is similar to what you described.
The visual representation of the Reference entity is not yet clear, but I can clarify a few things in the document based on your question.
I think our competitors have covered this topic well. I like how Dovetail solved it, but there are still some UI challenges we need to think about. These two features will not affect any Reference entity-related questions, but they will improve the current state of Reference creation.