Re: RFC: pools and catagories of packages
esoR ocsirF wrote:
>
> Greetings,
> IANAD, but I would like to suggest an idea that I had. There has been a
> lot of interest in getting packages arranged by different
> catagorizations, something like the menu. Most ideas that I have seen so
> far seem to imply adding new fields to the debs, but his seems like
> overkill to me.
>
I'm working on it. :)
Ideas were not constrained to adding new fields to the debs, which
isn't sufficient on its own.
> Couldn't a new packages be created, something like a Catagories.deb that
> contained a databased of entries for each type? like...
> Graphics
> |_Gimp
> |_Xfig
> etc...
Hmm. Have you read the discussion on this ML? Misclassification... thread
I don't think "another big tree" is good enough.
> and when somebody thought that a package should be added to a catagory
> they just submitted a bug against the catagory package. Extra catagories
> could be added by bug requests also. This would allow package maintaners
> the ability to say where there packages belong but also the users would
> be able to feed back into the catagories as well.
Well, good but not enough. We need a better way for developers and most
probably *users* to work on categorization.
You will be hearing some words about this from me *real soon now*
Let me skip all the boring stuff and come to the exciting part.
I'll develop an ontology tool for editing ontologies of the sort we need.
What we need is an ontology formalism that supports categories and
relations (such as sub-category or part-of). And does these in an intuitive
way, etc.
Right now I'm working on choosing a suitable formalism. So far my
inclination is towards making my own simplified stuff because:
* either they are too general (full KB support [ask,tell..], FOL, inference,
axioms, etc.) like KIF based stuff.
* or they are too specific. like SHOE.
Ultimately, I will proceed in the following order
* first, you will hear a design of this stuff. it will probably be
a graph based formalism. similar to Conceptual Graphs perhaps, but
will have just enough formalism to support our needs. and it *will*
be intuitive
* second, an implementation of this formalism as a pet language will
follow. i'm supposed to finish this in 10 hours, but not likely :)
* third, some kind of a user interface for "single-person" editing
of ontologies
* fourth, a client/server implementation will come.
I'm hopeful that as soon as I get to the second stage, we will be
able to get some part of the ontology right.
If you are interested in this stuff, let me mention a cool feature I'm
thinking of:
generic ontologies: these are meta-ontologies that can be instantiated,
it will be quite useful for us.
I can do some ASCII art now!! Yehaaaw! Death to graphics formatS!!
Now, all this discussion assumes you know a little bit about ontologies.
You might wanna check ontolingua stuff. Check it out at
http://www.ksl.stanford.edu/software/ontolingua/
On this list, I *promise* to post a more comprehensive description
and collection of links which I'm doing as part of a grad. cs course.
It's sort of a small web site done with screem.
A generic ontology (I'm doin' only trees to simplify things)
080808080808080808080808080808080080808080808080808080808080
I remain consistent with my previous diagrams, it should be clear
any way...
/ - - - - - - - - - - - - - - -\
|InfoProcApp: |
Data
| * * * |
/ | \
| / | \ |
Processor Editor Presenter
| |
\- - - - - - - - - - - - - - - /
InfoProcApp: Information Processing Application
The box indicates a "generic ontology package" here named
InfoProcApp. Here is a candidate ontology derived from InfoProcApp
/---------------------------------\
| GfxProcApp: |
| Graphics |
| * * * |
| / | \ |
| / | \ |
| Filter PaintApp Viewer |
\---------------------------------/
Now think of other stuff like this. The important thing is that
we can say that these are all InfoProcApps.
Now imagine this higher level hierarchy
Application
* *
/ \
InfoProcApp ....
* *
/ \
DocProcApp ----------- GfxProcApp
* * * *
/ \ / \
HTMLProcApp TextProcApp JPEGProcApp AnimProcApp
*
/
MPEGProcApp
Just to give a glimpse. Even the very simple generic ontology
I gave can be very useful in devising a useful ontology. Of
course that's not my last trick. :) The bag's full of 'em.. ;)
Caveat Emptor: Some guy or two are sure to show up and make more
bigotry in the lines of "we don't need this stuff. get us some
stupid tree that works, and we'll be set...".. Hell, No! That's
the last thing I will ever do!! And I will not take any such
comment seriously.
To my knowledge I'm the sole person who has made any serious attempt
at software package ontology and I would like to make the most
useful tool possible.
When the tool gets to be a bit standard, I'll deploy it for other
interesting applications. (the most immediate is some kind of a bookmark
/personal-data manager)
Constructive comments most welcome. Criticism without reading any
of the papers I'd linked to before on this list will not be tolerated!!!
Thanks!!
--
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo
Reply to: