Re: "Semantic" shell? (for lack of better name)
Hello Bryan,
> > At some point I was considering to actually use RDF-like triplets such
> > as "app1 reads image/gif" "app1 writes image/jpeg" etc. but we ended up
> > to going a tuplet-only approach for complexity reasons.
>
> we? who? Any working code that I could go poke?
The Debtags developers, in particular Enrico and I. But that was at the
earlier planning stage, and to a certain extend the current tags can be
read as triplet (works-with, uitoolkit can be read as "uses ui toolkit"
etc.), but we have a very restricted set of verbs, and the
implementation treats verb+object pretty much as a union.
A triplet-based approach should probably really be based on RDF and use
the existing tools for that instead of reinventing the wheel.
> Another response to my email included a link over to
> 'open-with-install', a program to query the apt repositories to find a
> program to open a certain file with, which is a good step in that
> direction. But yes, there is a vagueness involved in .desktop too.
This apps data might actually be just derived from the .desktop files.
I don't know the details, but that is what comes in mind. In particular
since Gnome would only suggest opening the file with the application
after installation when it has a matching .desktop file IIRC.
> > So it might well be time to do the next step and collect such meta
> > information on a "reads" "writes" "displays" "prints" and whatever
> > basis. However collecting all this data sounds like a huge task to me.
>
> Yikes, there are so many of those verbs though - you'd basically be
> doing Cyc or WordNet all over again. Each program technically
> qualifies as a new verb too, so the usefulness seems to deteriorate.
In fact, using data from WordNet etc. is something that immediately
comes to mind, especially for not reinventing the wheel.
You will need to make a cut somewhere though, the latest when it comes
to UI. Probably already for data input. Selecting a subset of WordNet
might still be a good idea for data exchange.
> "perl -e" accepts a string of text data (I don't think binary data
> works). Whether or not the string is valid in terms of perl syntax
> (etc.) is another issue entirely, isn't it?
Not really. It's just a question of complexity.
Many applications have some "file type" parameter. For "convert" IIRC
you can prefix the file name with a file type, e.g. "gif:-" to force
output in gif format on stdout.
So where is the difference in having "gif:" as a prefix of the output
parameter (which happens to not just be a plain filename!) or having a
full perl program there that does the gif generation?
Except that you can cover one with a regexp I guess, and the other not.
You have to make compromises somewhere.
P.S. autocompletion data files of zsh and bash might be a useful
starting point, too, btw.
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
Friends are those who reach out for //\
your hand but touch your heart. V_/_
Das größte Hindernis beim Erkennen der Wahrheit ist nicht die
Falschheit, sondern die Halbwahrheit. --- L. N. Tolstoi
Reply to: