Anytype — Interesting app concept for PKM and teamwork

Totally agree with you @Chr1sG on the object-relation dogmatism. Despite the “simple” concept, it is anything but simple to build the data structures and apps you have in mind. And yes, a date is an attribute, not a relation IMHO.

With Fibery, I was able to wrap my brains around the concept in minutes, and it took me another few minutes to build the first functional core app for my needs.

Now I have a fully working project/kanban app in Fibery that was super quick and intuitive to set up.

With Anytype, whenever I start something, I never manage to end up with the app I had in mind.

The only killer feature for me is that data is local-first and encrypted.

For now, I stick with Obsidian for documents and Fibery for planning, project tracking, and daily kanban. A great combination for me.

But I am happy to give them some more time to make the Anytype UI more intuitive to use.

4 Likes

They are still in alpha, which in itself means that this is not the final look of the app.

In any case, they are interesting for their concept and architecture. And they did not abandon the development of the application, despite the “long distance”. So it’s worth watching them.

4 Likes

I spent an hour in AnyType and here are my thoughts:

  1. It’s almost not possible to build process management tool inside. There are no Views (Board, etc) and you have only Objects. I imagine they will add Views later, but so far it’s not possible.

  2. I think they “stretched everything is an object” concept too far. For example, Relation is an object itself. It’s not intuitive. It may be so under the hood, but it confuses me… I might want to create different Type of Relation. Is it possible? Unclear…

so meta…

  1. There are no restrictions yet, and it leads to weird things. You can assign Book to a Task…

  1. There is a concept of Type, but surprisingly there is no concept of Field. It makes Type design a very complex cognitive task. I have deep experience in all no-code concepts, but I struggled to build a new Type to handle Invoices let’s say. You have to think with Templates, but even in a template there are no Fields. It’s very hard to capture Numerical data and Dates are objects? Insane… Templates idea is quite good BTW, the problem is in execution.

  2. Maybe as a personal life-organizer it works better, I didn’t tried to use it this way. There are many ready-to-use objects, like Book, Article, etc, so it might be attractive to keep everything here, but I am not that kind of person…

  3. I do like the idea of a distributive and fully controlled system, but in its current state I don’t like the execution based on items above. They should find the balance between internal complexity and UI. Now you have an access to the guts of the system. Blocks editor is also good though :slight_smile:

5 Likes

I’ve discovered that you can add Fields via Relations!!! Crazy…

4 Likes

Indeed, the whole ‘everything is an object’ gets too crazy for my tiny brain.
So, a relation between two objects is an object, and an object type is an object.
Which means if you want to create a relation between a task and an assignee, you’re linking two objects, each of a specific type (=object), using a relation (=object) of a particular type (=object)
:exploding_head:

5 Likes

Well I know that adding attributes to relations is one of the more popular requests for Fibery, so in that instance I’ll give Anytype thumbs up!

3 Likes

This is not the case Chris, they just hide usual fields under Relation. So it is not a relation attribute in fact.

1 Like

Ah, sorry I see what you meant.
It’s a while since I played with Anytype, so I’ve forgotten the UI.

It is necessary to look at how it is implemented at the database level. The Graph database assumes that “relationships are first class entities”.

It is possible that the current UI implementation is still incomplete. Therefore, it simply does not work correctly.

And it’s better to look not now, but somewhere in six months :laughing:

2 Likes

Yes, this is more an issue of terminology than anything, I think. I have told them that using “Relation” here is not ideal and causes confusion. :man_shrugging:

Yes, this is exactly right. The “database” features (Relations, Sets, Types, etc.) were only added a few months ago, so there is still a lot of work to do to make it intuitive and easy to use. Lots of work is happening internally on this stuff.

I find anytype quite interesting as to me it is the closest any of these types of no/low-code tools have come to a true graph/tripplestore. But I agree that by simplifying the model to everything being objects and relations they have created a lot more complexity. I am hoping that a happy medium would be achieved in fibery, more akin to a property graph (per various request like Relationship properties).

As @Chr1sG said, I think entities should have attributes which are basic primitive types (as fibery does currently). However, I think having an ability to actually define/contextualize the nature of relations between objects is something that is sorely missing. For example, being able to relate people/contacts in a CRM app to each other and defining their relationships (e.g. coworkers, introduced by, …) without having to create many relation fields or defining these a priori is quite important. The ability to also add one-off relations without having those become permanent parts of the schema is also something that should be adopted from anytype as it would simplify the UI quite a bit (i.e. reduce number of fields, tabs, windows, etc).

I also think that at some point, it may be necessary to “spin off” entity attributes into standalone entities/types when some nuances or complexity needs to be captured (e.g. what seems like an inherent property might be more fluid than originally thought). I don’t think any existing tools provide this ability (you always seem to have to create a new field and copy things) but I think it really helps with reducing complexity when designing systems up front as you do not have to consider every possible case and accommodate them. One of the areas where this comes up for me frequently is actually the name/appellation of things. Names can change or the same thing could be called by many different names. Being able to capture and retain this in any knowledge system is absolutely critical in order to prevent duplications and having records that are out of sync. You can achieve this by making notes in text areas and using search but you end up losing context, consistency and an ability to actually do some analysis in the future.

One final note with respect to dates: I actually do think that having a relation between entities/objects and dates can be quite useful when you would like to understand historic context. Imagine being able to see all the occurrences/events that coincided with each other. I think as you add more content to the system, this will become more and more interesting.

2 Likes

Yes, although Fibery’s existing “Select” Properties/Attributes (both single and multi) are essentially their own Entities. So there seems to be some of that capability already, which is interesting. A generalized “promote to Type/Entity” option would be interesting…

This sounds more like an “alias” feature would be useful to you. I’d find it handy as well, although I haven’t seen much/any other mention of it here. It’s certainly extremely important in general PKM.

Yes, absolutely! Although most tools that take advantage of this simply use a page with the date as the name to handle it. It’s less abstract than a “date relation”, as Anytype has. This in combination with the “backlinks” feature lets you visit any date page and see everything that happened on that date. Of course if you don’t have a true date “concept”/functionality associated with that “date page” and it’s just like any other page, then indeed you can’t do more sophisticated things like e.g. a timeline, or date calculations that involve that “date page”, etc. So there are benefits to the “date as relation” concept. I do think there is probably a better, more intuitive way to handle it than Anytype does currently, though.

@Oshyan as always very insightful. It is interesting “running into you” in various places on internet.

That is the perfect way of describing it. Maybe it should be feature request!

I totally agree that “alias” feature is quite important (I always think of it as the “owl:sameAs” relation. However, I think with appellations, sometimes it is necessary to extend alias to go beyond this entity may also be called “x” or “y”. There are sometimes other critical information that need to be captured, such as the period where the name was in use, the language, the region where it was used, etc. I know that these don’t really seem to matter in a context of a project management tool, but as you said it is quite useful in knowledge management systems. My area of work is in management of municipal park systems and I actually find it indispensable to know what different parks/places were called in the past (and when) whenever I am going through archives of reports and drawings.

3 Likes

This is a very interesting point, and I think it starts to demonstrate where the “everything is an object” approach might have more utility. In that model, like Anytype, the name itself should be an object (“relation” in Anytype), and you should then be able to have history for it (like full document history, but for each object). This seems the simplest way to solve the specific “when was this name?” case, but it doesn’t handle the “region, language”, etc. So then going a step further, I guess you must create a “Name” Type of Object, that has a Date Range property (field, or “relation” in Anytype), a Language property, etc. Then you connect your Names to your parent object, e.g. the park you want to track the names of. Then you need a way to specify which is the current name. I guess you could do this with a Field of the Park object that is a Relation to the Names. With another field for “past names”, that has the rest. Hmm. Is that the beginning of an approach to handle this? Is it too complicated? Could it be made simpler or more automatic? If so, how?

The simpler solution is just to have History Type with Name and Date Range fields and have a 1-* relation to Park. Now you can create new History Entities for any Park entity with Name and Dates when this name was valid.

2 Likes

Indeed! But this only solves part of the overall described need. There is a tension between creating dedicated functionality for things vs. overall flexibility, I think. However “history” seems like a fundamental capability, so I agree it should exist and would be an important part of the solution.

If you could then add fields to a history object/concept, you could potentially take care of some of the other needs described, e.g. location a name is used, etc. Then you need a concept of date ranges being referenceable as a “thing”, in a sense. Perhaps this is where “named versions” come into play, or something similar. Thus you can create “This name was used from this date to this date in this location and language” type of “named versions”. Maybe that is not the best way to solve it, I’m unsure. Just thinking out loud, really.

Edit: @mdubakov I replied before you finished editing your response. :grinning_face_with_smiling_eyes: So if you then add fields to the History type for language, location, etc. I guess it solves it?

BTW so far I don’t buy Date as a separate Object concept. Time is quite universal thing that everybody understands (but physicists of course). So in general it is more a problem of aggregation/representation than a problem of structuring. If you have many entities with various Date fields, it is relatively easy to implement an interface to group/list all entities in a specific date range, etc. What benefits Date as an Object gives to you? I imagine some automatic generalizations like Month, Quarter, Year. It is quite useful, but is it worth it? Not sure… But there is something in it of course. We wanted to think about time deeper in Fibery, it was in the initial spec, but then we decided to not dig into this direction and now we have good cases where first-class time citizen would be helpful.

1 Like

Appellation/Name Discussion

This is exactly what I ended up doing with guidance from @Chr1sG (see Siblings as children of parents filter). However, it seems rather hacky to me, partly due to some limitations of formulas and need for a few intermediary fields. How this looks in the fibery UI also leaves a lot to be desired (I know the new layout will greatly improve this):

But I also feel I need to be able to this more universally/consistently for more entities such as places, people, etc. rather one by one for each type. As @Oshyan said, this is both a data structure and UI challenge.

Date/Time Discussion

I think that time/date requires more in-depth attention particularly if we are talking about knowledge management but agree that a separate object might not be the answer. I think almost all systems out there try to define dates in very specific and rigid terms which makes representing fuzzy dates like “August 1962”, “Autumn 1720”, “1955 - 1957”, “1920’s”, “17th century”, etc. impossible. You end up either having to use text/string fields where you lose all sense (and control) of the fact this is actually temporal data or have adopt a set of standards/conventions to work within the constraints of how the system represents dates/time. For examples, you can adopt a convention that all month-type dates like “August 1962” would be represented as the first day of the month “1962-08-01” or a range between first and last day of that month. But I feel that takes away from what we intuitively know is a less precise definition than the actual range between first and last day of that particular month. I think that becomes more acute as the time horizon becomes longer. This may be an academic point but I think it is worthwhile to think about it at some point particularly when you are talking about managing “knowledge”.

Arches (a GIS based data system for historic sites management) uses EDTF to address this which seems like an interesting solution. It accompanies this with a time wheel UI component that makes navigating the date easier and more intuitive (see this short demonstration).

Fuzzy Data & Uncertainty

I think we will eventually have to deal with representing uncertainty in many areas of our data (particularly structured data). For example, when we record numerical values as integer/double fields, in many cases we are masking/losing the inherent uncertainty of these values/measurements, even if the uncertainty is well understood or measured prior to the data entering into the system. As far as I’ve seen, there is currently no means of representing this uncertainty/probabilistic nature of the data in mainstream databases and apps and unless there are descriptive/free-text fields associated with the record to describe the uncertainty, other users are going to totally miss this. Even if a description or explanation exists, it doesn’t really help with tracking of uncertainties and cumulative error as the data is aggregated/used in future calculations.

By the way, this is not just reserved to numerical values but also is a big issue in geospatial data, among others.

Possible Solution

I am not bright and experienced enough to come up with concrete solutions. However, I wonder if having the ability to build more complex or compound data types is the answer. I know this can be accomplished more or less in fibery by building new types and establishing relations, but to me defining a fuzzy numeric value as a totally separate entity/object seems really bizarre and clunky particularly because you need to create the new entity, open it, fill a bunch of fields and then return to the original record. I think being able to construct compound types from a series of fundamental/basic data types which can then be used across the system with a consistent data entry UI would be very helpful in this regard.

I am hopeful that the extensions fields (workflow, avatar, etc.) will eventually allow this functionality.

Apologies for another long, rambling and probably unhelpful post. I am hoping that by writing these things down, the bright folks here can come up with some interesting ways of addressing these for the masses.

2 Likes

This is a very interesting and useful point and set of examples. The question that comes to my mind, which I think is critical, is something like this:

Is “time” part of a reasonably small subset of “qualities”, “fundamental concepts”, or some other such definition, that:

  1. can be specifically enumerated, described, and understood, and
  2. can be (if necessary) treated specially, with specific functionality particular to the needs of each concept (geospatial concepts are another great example, as you noted).

OR

Is “time” just one of innumerable concepts both large and small, some of which may be entirely unique to one or another person, business, etc.?

In the first case, creating specialized functionality for each “concept” makes sense and is possible to complete, even if difficult. But in the second case, it seems that while special consideration for each domain is useful to some degree, it is ultimately futile to try to cover all needs in this way, and so a fully flexible system is truly needed.

I question whether such a “fully flexible” system can be both powerful enough and intuitive enough to construct e.g. useful definitions and capabilities of a “time” concept and e.g. a “geospatial” concept. But even if it seems impossible, it would be good to understand if it seems like this is truly necessary. Or… if we can (I hope) have a high (but reasonable) degree of flexibility in general, and give only certain, key concepts or qualities some extra, custom functionality relevant only to their particular characteristics.

More broadly, regarding “fuzziness”, I really wonder if this is an optional quality/component/function of all field types (or at least numeric ones?) that could be created sensibly to cover all or a majority of needs, including the date example demonstrated. I could imagine it working in two parts, with a general “fuzzy data” field “property” (so to speak), which tries to represent fuzzy data in a reasonably universal or generalized way and can apply in the same way to any (numeric?) field, and then perhaps with specific functionality in any field that requires more customized fuzzy data handling (e.g. time), which modifies or extends the generic fuzzy data property with UI or other elements specific to its needs. But perhaps instead fuzziness is really very particular to specific types and concepts of data, in which case it could perhaps be handled totally uniquely for each need. I agree that geospatial data seems like a good additional example to consider, but I’m also curious about how many other such examples we can come up with.

Also, please stop apologizing for writing interesting things. :grin: I don’t think anyone yet has the answers to these kinds of questions (if they did, we’d know about it, right?). And while there are undoubtedly people with greater expertise to speak from than you or I, until/unless those people are weighing-in here in similar depth, I think it is certainly useful for us to put forth some opinions, ideas, and questions. And when such domain experts do weigh-in, it is also quite valuable for us to question and challenge them, if we see something that doesn’t make sense or could seemingly be handled better. That’s my perspective anyway. :slightly_smiling_face:

I would have agreed with you before using Roam research, but that opened my eyes a bit. I do suspect though that it is easier when thinking about a tool that is built more for personal use, rather than one built for collaboration.

There is something very natural of having dates be actual objects because they are an actual thing you experience. If you think about a character or a number, treating those as objects wouldn’t be quite the same. I wouldn’t want to just jot down some notes about the number 5, but it intuitively makes sense to jot down some notes about a date or period of dates (week, month, etc).

Now, in Fibery you could build something similar in utility, but it can’t really be done without having to actually think about Types. Without dates being actual objects, you are forced to maintain some kind of view that shows all things associated with a date. However, you would need to keep that view up to date for each new Type you add and you can’t just add some notes to a date without having a notes Type.

To speak to Fibery’s flexibility, I have been able to create my own Dates app in Fibery though. I can just add dates, months, quarters, etc with auto-linking between them to have objects for what I care about. I can also auto-link them to other Types based on the date fields applied to them. I think if we ever have polymorphic relations with auto-linking, then it could clean it up a bit.