We had object-based, multi-media files with Engelbart's NLS/Augment system.  We had relational databases way before the web.

But here we are in 2022 with enormous personal computing power and for interactive editing, everyone is using and transferring stream-based files of characters that are then interpreted at the delivery site.  There are many reasons for this including limits in many organizations of the file types that may be transferred through common protocols and the difficulty of maintaining relational database or structured file type schemas across time.

Simple tends to win out over more powerful because few people want to bear the cost of continual training to raise all of the newcomers to a level of performance that they cannot teach themselves.

I like your model, Jean, and am a fan of such things but I am also pragmatic and thus focus on building things that I think people will consume within a given environment.  In Hyperbole's case, it is base Emacs and nothing more.  If you are familiar with what it takes to standup a scalable web application today (what everyone wants), you understand why that is not a great model for systems where the users have to manage and customize the infrastructure themselves.

-- rsw

On Fri, Oct 7, 2022 at 3:52 PM Jean Louis <bugs@gnu.support> wrote:
On October 4, 2022 6:05:58 PM UTC, David Masterson
>One major use-case for Org is capturing a task quickly.  This can be
>done with Org or Mobile-Org (BeOrg, Orgzly).  One feature not easily
>available is attaching images to the task to better explain the task.
>
>Thoughts on this?

There are many ways of capturing elementary objects. Org Capture is one way as it's connection between Emacs and outside programs or Emacs and Emacs.

With or without Org or Emacs computer users should be able to capture any pieces of information and it's references in any type of a system.

For me personally I use PostgreSQL database and have finely grained types of objects, so I can relate anything to anything, then export to Org or package with any kind of connected objects, not only Org.

The way to go for Org users is to make a function that first takes specific files and then captures the rest. Then files are to be used as properties or links in subheading.

That is what I don't like as too many properties and markup is really disturbing. I keep it invisible.

Design of such system shall be that each elementary object has our get it's really unique reference, possibly across networks and world, then that it gets it's type of relation, and it's value such as file. The file is object too, must have it's references.

Relation could be just RELATED, but it could be, CONTRACT or DISREGARD, as one shall know why are some other objects attached.

Relating objects is most important in information management.

https://en.m.wikipedia.org/wiki/Relational_database

What you and many others really want is relational database. I see no problem to connect Org to such. You can have just one property like ID or embedded not presentable link and all other properties related through one, by principles of the relational database.

I often use preprocessing markup tags that interpolate to anything, like Org markup or any other. That way I can add just anything to Org or any other text. Like bunch of files or links, without using specific mode.

Feature I use mostly to inject single objects into bunch of files, even thousands of files. When I edit such single object, other files automatically interpolate the contents of such object.

Imagine company address appearing on thousands of related pages and over different domains, editing phone number changes it anywhere.

Imagine that link name changes each in na while like those links showing specific but dynamic market price, when price is changed all documents get the new link name without files being edited or modified.

When you have single object ID then adding files to it can be handled outside the single Org file. Imagine an Org ID as universal hyperlink to other objects. Let us say, properties in other file like "attachment" and list of files in that other file.

It is up to Org designers to better adopt the idea of decentralization of properties, tags, etc. One can't put all the messy looking stuff in text file, it's not text any more, it looks like garbage on the screen.

Moving more to the extreme then anything can be separated from Org and written in plethora of other modes, markups and then presented in the Org simple way for clarity and better understanding to final user.



Jean