@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.
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.
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. 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.
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.
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:
can be specifically enumerated, described, and understood, and
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. 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.
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.
But… can’t you just have a Date/Day Type, with a Date (and/or date range) field within it and a Rich Text, and thus accomplish basically all of this and more?
It does for a certain way of thinking about/using it, sure. But in the Roam sense, simply mentioning the date accomplishes the same thing, doesn’t it? In the date entity you end up with a list of references/backlinks, basically. I guess it depends on what you want it for, but since you used Roam (which has a decidedly low-tech approach to dates, actually), it seemed to me a fairly simple approach could do.
Has anyone here used Anytype recently? I’m quite curious about it. Can objects have arbitrary relations to any other object? Are the relations Typed, e.g. (n:Object)-[IS_A]->(m:Object) or simply named? Can they have properties now?
You should probably ask @Oshyan but I think it works like this:
Everything is an object of a type
So the generic relationship (‘is parent of’) is an object of the type ‘relation’ (which is an object of the type ‘type’ )
You can certainly create a relation to the ‘is parent of’ object (of type relation) from within another object, but it doesn’t seem to show up in the same way as creating a relation to another object.
To be honest, some of our users find the Fibery concepts hard, and I can’t imagine what they would make of Anytype’s level of abstraction.
Yeah, I think Chris more or less articulates it. True “typed” relationships do not exist, in fact relationships are generally weaker at present in Anytpe than in Fibery (although you can have “polymorphic” relationships in the sense that by default a relationship can exist between any two objects). But the relationships are generic in the sense that they will be a generic “backlink” on the “destination” side of an otherwise specified “relationship field” from the source object… if that makes sense. I.e. when you create Relations in Fibery, you create a Field to hold that relationship on both entities, whereas the Anytype current functionality is more as if you’d create a 1-way relationship and on the destination object (entity) it would just show up in the References section.
There are also no “rollups” (calculated fields/values/relations) or “lookups” (values looked up from related objects).
Presumably all this is going to be expanded and improved over time. But their focus has definitely been elsewhere for a while. I think the biggest database-oriented change recently was to add filtering of objects in a relation, i.e. to make it so not all relations have to be polymorphic. Kind of ironic they were going the opposite direction as Fibery needs to go. But Fibery tries to do a lot more with relationships, so it’s not really surprising that it was easier for Anytype to be more flexible at first.
After having actually tried anytype I can confirm the following:
fibery is 1000x easier to use and make much more sense.
But being local-first/E2E is a gigantic advantage of anytype, one that for some/a lot (I can’t really quantify) of users might be decisive.
I think AnyType is a good case study to keep tracking, because it reflects as new initiative probably the most insteresting developments in the field of decentralized peer to peer collaboration. The challenge for Fibery is to reassess its business model, whether and how to jump this boat or not, it depends of the vision and experience of the founders.
This aligns with my suggestion about semi-decentralized connectivity of Fibery spaces:
So if you then add fields to the History type for language, location, etc. I guess it solves it?
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. 
)
But Fibery tries to do a lot more with relationships, so it’s not really surprising that it was easier for Anytype to be more flexible at first.