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.
The weight attribute is an implementation of the Insight Gathering use case.
True! No need to edit it everywhere. Showing the content is solving the use case.
Make it edit able everywhere is a nice to have because it will only save you some time/clicks
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 Do you take into account in the architecture of the new references, their (future) role in relation graphs as mentioned here? Knowledge Graph / Graph View / 3D visual report - #5 by Yuri_BC
We are not currently considering these use cases, but I don’t think any design concepts make them impossible in the future.
@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.
While we are considering Reference related core structural questions, we also want to get our hands dirty with related topics to move the Reference initiative forward.
We started to work on two things:
If you have any thoughts or ideas about this topic, please let us know. This is the perfect time to share your insights.
I found the following roadmap item ‘Reference entity’: https://the.fibery.io/@public/Public_Roadmap/Roadmap_Item/Reference-entity-214
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.
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.
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.
A more concrete example:
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.
At first sight, your solutions for ‘Modify Reference selection’ and ‘References can overlap’, sufficiently address the topic. Is there any challenge that you expect for those solutions?
Other than that, since this appears to be a generic topic about the ‘new’ References, maybe its useful to ask a question that I for convenience gave a new topic: Does the new Reference Entity cover these issues?
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.
1 special thing I release when moving to fibery: Reference ⇄ Atomic note concept in PKM
for more details, you can reference about building pkm in this article Building a Second Brain: The Illustrated Notes
With regard to the New References, are you considering how field tokens play a role in that?
See also July 20, 2023 / Experimental new Grid View and 🏛️ Columns Layout in Docs - #31 by Yuri_BC
Please help me with examples. Thanks.
The integration of a token system could further enhance this New Relation/References feature in several ways:
- Field Combination: As discussed earlier, tokens could allow users to combine fields from different entities, including relations/references. This means that you could display information from a relation’s fields alongside the entities it connects, all within a single cell or card.
- Nested Relations: If relations can contain other relations, a token system could help navigate and display this complex, nested data structure. For example, you could use tokens to display information from a relation within a relation.
- Custom Formatting: Tokens could allow users to control how relation data is displayed. For example, you could use tokens to define the format of a date field within a relation, or to control the display order of multiple fields within a relation.
- Dynamic Views: Tokens could be used to create dynamic views that change based on the state of a relation. For example, you could use tokens to display different information based on whether a relation is empty or contains certain data.
- Automation and Logic: If tokens are used in automations, they could also be used to automate tasks or apply logic based on the state of a relation. For example, an automation could be triggered when a relation is added or removed, or when a field within a relation meets certain criteria.
In summary, the integration of a token system could greatly enhance the flexibility, power, and user-friendliness of Fibery’s new relation feature. It would allow users to manipulate and display relation data in a wide variety of ways, making the system more adaptable to their specific needs.
Sorry, I mean real use case examples you would like to solve currently, but you cannot because of Fibery limitations.
About Reference entity topic
when I read this
Some kinds of things pop up in my head. This name field basicly Ontology define in Compass Framework, this define relationship type between 2 entities. In obsidian, Excalibrain plugin does it as page level (meanings entity level), But with current dovetail can do, we can apply this as higher level (block level) in fibery
this link describe exactly ontology meanings https://www.youtube.com/watch?v=7rnsULzez-g&ab_channel=Zsolt'sVisualPersonalKnowledgeManagement
and the way it display right relationship in Obsidian by plugin called Excalibrain https://www.youtube.com/watch?v=8LE_QdYQZVk&ab_channel=Zsolt'sVisualPersonalKnowledgeManagement
Hope this can help in Reference creation or even a basic graph view
Related to References Reloaded: