Re: Org and Hyperbole

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 4707 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5879 bytes --]