The ability to highlight any texts is probably an exaggeration to this use case, especially when users can already do so by @mention or links, or if we have Unlinked Mentions & Aliases for Objects.
This is more of a block based reference situation, which Transclusion could indeed be helpful, especially for referencing blocks on-demand. The use case focuses on referencing the same block multiple times, and there are regular systems/structure to what data should be displayed for the specific purpose.
Query might be the more relevant function. I believe with relational data model, which should be in place in Anytype already, this is not too difficult to implement in terms of data structure (but indeed would probably cause heavy impacts on UI).
This is how we can query or ask Anytype for different data. Every verse/note in this space contains candidate key (aka identifier) or a foreign key (to identify which verse it is linked to), then we can query objects that matches the candidate key (and other required filters) and display the relevant contents/relations in a FormatRelation (just like the live template relation concept).
- However, as extended function to live template relation, with retrieval system, we can display multiple objects or multiple rows of data at the same time.
As an illustration, the following table shows what data field is required for what purpose.
| Note-taking purpose | Book and/or Chapter (as identifier) | VerseNumber (as Identifier) | Version Identifer or Version Object | Note |
|---|---|---|---|---|
| Marking down the verse(s) | Must have | Must have for verse object use case (or semi-optional when storing each verse in a block within a chapter object) | Only when users plan to have multiple versions of the same verse (thus can be added later) | Not required but can be displayed if queried using the identifier from its note |
| Note on single verse | Must have | Must have | Only when needed | By definition (could be distinguished from object type or any assigned relation). This is a note |
| Note on a group of verses | Must have | Required multiple entries (to improve: allow inputting format like 1-10 and 1,2,5,6) | When needed | Same as above |
| Note on chapter/book | Must have | Not needed | Only when needed | Same as above |
| Note on location/people | Not required but would contain other information as identifier (e.g. John - the baptist vs John - the apostle) | Not required | Not required | Same as above |
| Interlinear comparison (from query) | Must have | Must have | Must have | When required. Note might be a co-relation between versions. e.g. Exist in KJV, but not in NIV |
| Side by side reading | Must have | Not required (unless change of purpose) | Require 2 or more | Same as above |
The reason I did not emphasise on transclusion is that transclusion is mainly about aesthetic or the display of information. This use case
- first requires key/identifier assignment, the function of Advanced Filters / Queries.
- Then probably a batch query e.g. to read all verses in a chapter, query all objects with (ChapterIdentifier and not NoteObject), then sort by VerseNumber.
- And then the aesthetic (e.g. display in set or display in an object).
- However in an actual workflow, we probably want to pre-determine the aesthetic / FormatRelation (which gives Anytype information on what data to be displayed), then give Anytype instructions on what data to be queried.
P.S. I have no idea how the many Bible websites and applications work, but those should be useful reference. If we can do that in web2.0, we can definitely do that in web3.0.
P.S.2. @UnwokeNetizen Thanks for your insights. I can now better name the components of this use case (although might still be difficult for people to understanding… sorry ![]()
Side note: the functions mention here are useful for research as well. For example
- Ask people to fill data in questionnaire (or form format) ← This must always be kept intact for data integrity.
- Then ask Anytype to query participants (but don’t display ParticipantID for privacy reason)
- Then redisplay quantitive data in set/collection, and calculate max/min to find out if there are extreme cases.
- Then request and compare the qualitative texts side-by-side, to find out the special characteristics.