Here are some of my thoughts, maybe a bit messy and too compact though.
Types seems to resemble filters or advanced filters for properties/relations, in collection.
- In collection, Turning a filter on/off with a toggle, without deleting the filter, users can toggle the relevant properties/relation and their contents.
- For example, when book type is on, display genre, writing style; when movie type is on, show actors, duration, cinemas.
- Turning properties on/off will benefit the management of increasing number of properties involved if when multi-types are implemented.
Equalising type and collection seems compressing… but yes set/collection is extremely important for users to understand relation because tables, as illustrated by @dzlg in Multi-dimensional Relations , are the most straightforward way to express matrix.
- We can have type for objects and type for properties/relation as well, hence FR Creation of Relations from scratch .
- If we show the advantages of relation data model, type is like grouping attributes (hence why property makes senes) for entity (aka object in Anytype). We can call for a specific group of attributes by contexts (for both data input and display respectively).
- Entity will have its own set/collection for storing all keys/identifiers, which keys are for referencing other sets/collections.
- For example, A book has author attribute, but when movie type is added, introduce actor attribute as well (which these attributes can be a one-to-many relation).
- Book has its own set/collection containing author attribute; Movie also has own set containing its attributes; but more importantly,
‘All objects’ set will store the indicators which sets and attributes each entity has to refer to.
‘Harry Potter’ (an object) can be reused as one of the primary keys to both the book and the movie.
Book set will store a foreign key in AuthorAttribute to J.K. Rowling in Human set (or All object set with Name and HumanType).
Individual book of the series - The philosopher’s stone (another object) can take Harry Potter as first identifier to pull AuthorAttribute from Book set but add a Second Title for a second but more definitive identifier.- All of these objects are related and can be interactively used across sets/collections.
- Hence a single Table/Collection has its constrain for explaining relations across collections, and definitely infinite matrices. FR Node editing workflow could be an alternative to help users understand relation and how relation can refer a certain connection point of another object - The nature of table and graph combined - Best fit.
- Therefore, with relational data model, Context properties should be default because a type is the fundamental context for what is involved and the request for keys. A book is simply the context for the genre.
- For example, these days we also need to define men and women, so there are rarely cases for things to exist without contexts. Not that we need to specify contexts every time, but we need to allow contexts whenever is needed.
- Global or generic attributes are essential but users are less likely to make constant changes since it is universal anyway.
- Entity will have its own set/collection for storing all keys/identifiers, which keys are for referencing other sets/collections.
- See some information about relational data model, specifically about entity, attributes and relationship here, and keys here. (Sorry, is me mumbling about relational data again
but I really highly recommending going into relational data model)
However, type/context can act on/for individual object as well. For canvas, we do have this Multilayer text annotation objects on the forum, which shows a little bit how we can display the relevant information only when context is selected. This FR emphasises on highlight relevant text with background. However, we can have more advance control over all texts as well. For example, with New relation type: Block . we toggle a group of properties/relations on/off and decide only the linked blocks (and included texts/data) should be displayed.
- This method would work well with publishing and its design as well. Since we can compact and section information for users to display based the focus. e.g. Under a main topic/header and explanations, introduce 4 examples which one example is shown by default, but users can decide to click on other examples to understand more. Like on Anytype.io - “Single objects, infinite possibilities” section, where you can see usage examples of table, kanban and gallery.
I am genuinely glad to see how relationships are back to focus, but perhaps these are not easy to implement and for users to onboard.
And yes, Anytype is the Apple of note-taking industry!! As Steve Jobs said, “Our job is to figure out what they’re going to want before they do.”.. as Anytype shows the beautify of Type and Relation, users will then eventually understand why these are essential for note-taking - the interactive dynamic but reusable components of ideas and lives.