Re: Bug#361418: Debian menu and the Apps/Science section
On Sun, May 14, 2006 at 06:20:25PM +0200, Thomas Walter wrote: > Hello, > > >From my point of view this 2 section names are arbitrary and too global. > It also opens a long discussion about the hirarchy. I think Mathematics > is also part of Science. At least for application like axiom, octave, > mathematica, ... > So having a Math section in parallel to Science could be for more > "calulator" oriented SW. Well most mathematical software I know are oriented toward doing computation. > In general, my understanding of "Science" is in the sense of research > and not education. > Thus an example breakdown within Sience could be like > Mathematics > Physics > Bio > Chemistry > Astronomics > Geology Could you provide packages list to flesh these sections ? > where some applications or tools can be part of several sub-sections. > Perhaps applications which could be used in nearly all sub-sections > could go into a "General" or "Common" Section. We absolutly try to avoid catch-all subsections because they tend to be used as dumping ground for anything that do not fit in the structure instead of leading people to improve the structure. > In parallel to section "Science" have a section "Education". "Education" is listed in the draft: Education Educational and training software. gtypist, gcompris, quiz Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
On Sun, May 14, 2006 at 05:45:44PM +0200, Francesco Pietra wrote: > etc., what about chemistry? Chemistry is at the basis of "natural sciences" > mentioned below, and a basic science in its own. Think about chemistry (there > are great debian packages for chemistry, first on the line - in my view - > mpqc. At any event, there are chemists under the "Science section" umbrella. If you meant the wording "Software for natural and social sciences, humanities, etc." somehow imply that chemistry does not belong here, by all means please provide a better description that cover Chemistry and Physics as well! Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Am Sonntag, den 14.05.2006, 18:20 +0200 schrieb Thomas Walter: > On Sun, 2006-05-14 at 17:01, Bill Allombert wrote: > > Hello Debian Science people, > > > > There is a discussion (in bug #361418) on the future of the Debian > > menu structure. In case you missed it, we would like to have your > > opinions on the entries for scientific applications. > > > > The relevant sections are: > > > > Mathematics [was:Math] > > Mathematics-related software. > > gcalctool, snapea, xeukleides > > > > Science > > Software for natural and social sciences, humanities, etc. > > ncbi-epcr, earth3d, therion > > > > Please send comment to bug #361418. > > > > >From my point of view this 2 section names are arbitrary and too global. > It also opens a long discussion about the hirarchy. There is IMHO no need. Why not use the freedesktop.org's menu specification as reference? This would help to allow a user an easier orientation. > I think Mathematics > is also part of Science. ACK. > At least for application like axiom, octave, > mathematica, ... > So having a Math section in parallel to Science could be for more > "calulator" oriented SW. I don't think so. I know, OOo Math isn't a real scientific software. But there are people who think, that Ex**l is a tool for graphical analysis of measurement values. I believe, nobody has the _real_ definition for what is really scientific software. So IMHO it doesn't make sense to have a Mathematics section inside and outside Science/Education. Or do you know a definition to know the difference? > In general, my understanding of "Science" is in the sense of research > and not education. I do not agree. Education also means science. It doesn't just mean "teaching". For me, there is no difference between Science and Education. Where is the difference IYO? > Thus an example breakdown within Sience could be like > Mathematics > Physics > Bio > Chemistry > Astronomics > Geology > ... > where some applications or tools can be part of several sub-sections. > Perhaps applications which could be used in nearly all sub-sections > could go into a "General" or "Common" Section. > > In parallel to section "Science" have a section "Education". And there also: Mathematics Physics Bio Chemistry Astronomics Geology ... ? Doesn't sound like a good idea to me. just my 2 cents Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
On Sun, 2006-05-14 at 20:52, Daniel Leidert wrote: > Am Sonntag, den 14.05.2006, 18:20 +0200 schrieb Thomas Walter: > > On Sun, 2006-05-14 at 17:01, Bill Allombert wrote: > > > Hello Debian Science people, > > > > > > There is a discussion (in bug #361418) on the future of the Debian > > > menu structure. In case you missed it, we would like to have your > > > opinions on the entries for scientific applications. > > > > > > The relevant sections are: > > > > > > Mathematics [was:Math] > > > Mathematics-related software. > > > gcalctool, snapea, xeukleides > > > > > > Science > > > Software for natural and social sciences, humanities, etc. > > > ncbi-epcr, earth3d, therion > > > > > > Please send comment to bug #361418. > > > > > > > >From my point of view this 2 section names are arbitrary and too global. > > It also opens a long discussion about the hirarchy. > > There is IMHO no need. Why not use the freedesktop.org's menu > specification as reference? This would help to allow a user an easier > orientation. > If I remember correct, I had a look at this definitions near the beginning of the year. There was also a thread talking about this categorisation suggested. Pros and cons. I assume this is based on 2 big groups where one put people in 50%: education <=> teaching 50$: education <=> anything See below. > > I think Mathematics > > is also part of Science. > > ACK. > > > At least for application like axiom, octave, > > mathematica, ... > > So having a Math section in parallel to Science could be for more > > "calulator" oriented SW. > > I don't think so. I know, OOo Math isn't a real scientific software. But > there are people who think, that Ex**l is a tool for graphical analysis > of measurement values. I believe, nobody has the _real_ definition for > what is really scientific software. So IMHO it doesn't make sense to > have a Mathematics section inside and outside Science/Education. Or do > you know a definition to know the difference? No I have no definition. Excel is as you said a OO front-end. It is a simple spreadsheet tool crafted by functions from lots of categories: math, graphics, ... to do final calculations and report preparation in this front-end. One can also program a chess program in TeX. It is slow, but works. > > > In general, my understanding of "Science" is in the sense of research > > and not education. > > I do not agree. Education also means science. It doesn't just mean > "teaching". For me, there is no difference between Science and > Education. Where is the difference IYO? > Exactly this is the key: Education: teaching you are teached/trained to be able to do something or to teach others improve individual wisdom/skills. Science:research you apply the above to find something new. improve the global pool of wisdom. > > Thus an example breakdown within Sience could be like > > Mathematics > > Physics > > Bio > > Chemistry > > Astronomics > > Geology > > ... > > where some applications or tools can be part of several sub-sections. > > Perhaps applications which could be used in nearly all sub-sections > > could go into a "General" or "Common" Section. > > > > In parallel to section "Science" have a section "Education". > > And there also: > Mathematics > Physics > Bio > Chemistry > Astronomics > Geology > ... > ? > > Doesn't sound like a good idea to me. > Yes, this looks strange, you are correct. But think about these Section, Sub-section, ... names like tag attributes. You are free to order the tree in any way you want. Science Math Physics Bio ... Education Math Physics Bio is equal to Science Math Education Research Physics Education Research Bio Education Research ... Kind Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Am Sonntag, den 14.05.2006, 21:55 +0200 schrieb Thomas Walter: > On Sun, 2006-05-14 at 20:52, Daniel Leidert wrote: [..] > > > In general, my understanding of "Science" is in the sense of research > > > and not education. > > > > I do not agree. Education also means science. It doesn't just mean > > "teaching". For me, there is no difference between Science and > > Education. Where is the difference IYO? > > > > Exactly this is the key: > > Education: teaching >you are teached/trained to be able to do something >or to teach others >improve individual wisdom/skills. > > Science:research >you apply the above to find something new. >improve the global pool of wisdom. I know that opinion of course. But "education" with the meaning of "higher education" isn't that far away from "science". I know, people have different opinions here. Just a few questions: Where do you make the difference between a scientific and an educational software product? Let's say: What is a chemical structures editor? What is a (software realized) calculator with scientific functions (like those who are mostly used in education)? Just think about, that you _must_ define the answer for at least the first question if you make a difference in Debian's menu between education and science. I'm really not happy with dividing between them, because IMHO there is no clear difference. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
On Sun, May 14, 2006 at 05:57:31PM +0200, Francesco Pietra wrote: > I received this message after I answered Bill Allombert. > > The list below is a reasonable one, when "Bio" is written in full "Biology" > and "medicine" is added; medicine is largely biology but with special needs. > > I disagree with the distinction science/education. Scientific education is > science, or ideally it should be. Most discoveries spring from students doing > a thesis work, which is education. Arrhenius set the a large section of the > basis of chemistry (and thereby of biology chemistry agronomy etc etc) while > a student under education (although - being too much ahead of the times - he > was blamed for his ideas). In the context of menu, we should consider the categorisation from a functionnal perspective: " How the user interact with the tool ? " Software that assert knowledge and/or capability of users (arithmetic quizzing, typing tutor) or whose purpose is to teach a determined set of knowledge to the user are in Education. Software that let the user to observe, process or compute freely with scientific data are in Science. Of course scientific softwares will be used for educational purpose, and some softwares will have both purpose. Consider the Games section: Instead of classifying games by topic (Sci-Fi, Heroic Fantaisy, animals, cartoon,etc.) which would lead to an almost infinite list with a lot of intersection) we classify them by the way the user interact with the software (Action, Board, Card, etc.). Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
On Sun, May 14, 2006 at 07:20:55PM +0200, Bill Allombert wrote: > On Sun, May 14, 2006 at 06:20:25PM +0200, Thomas Walter wrote: > > Hello, > > > > >From my point of view this 2 section names are arbitrary and too global. > > It also opens a long discussion about the hirarchy. I think Mathematics > > is also part of Science. At least for application like axiom, octave, > > mathematica, ... > > So having a Math section in parallel to Science could be for more > > "calulator" oriented SW. > > Well most mathematical software I know are oriented toward doing > computation. And most mathematics is oriented towards stating and proving theorems. I think there is software that supports theorem proving. Tex provides special support for stating theorems in the international language of mathematics. To me, scientific software is software that supports scientists in their work as scientists. This is not a very restrictive definition. It does, for me, carry some connotation that the user expects to understand what the software is doing. But I am aware of many instances where this is not true. This is in contrast to Accounting Software where the user hopes that he can keep himself and his business out of trouble without understanding and the software developers try to satisfy that hope. > > > In general, my understanding of "Science" is in the sense of research > > and not education. > > Thus an example breakdown within Sience could be like > > Mathematics > > Physics > > Bio > > Chemistry > > Astronomics > > Geology > > Could you provide packages list to flesh these sections ? > > > where some applications or tools can be part of several sub-sections. > > Perhaps applications which could be used in nearly all sub-sections > > could go into a "General" or "Common" Section. > > We absolutly try to avoid catch-all subsections because they tend to be > used as dumping ground for anything that do not fit in the structure > instead of leading people to improve the structure. > > > In parallel to section "Science" have a section "Education". > > "Education" is listed in the draft: > > Education > Educational and training software. > gtypist, gcompris, quiz > There is also the science of educational technique. How children learn and what works and doesn't work for various levels of child development. And what styles of training software are appropriate for various kinds of users. Cheers, -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Hello, On Sun, 2006-05-14 at 22:26, Daniel Leidert wrote: > Am Sonntag, den 14.05.2006, 21:55 +0200 schrieb Thomas Walter: > > On Sun, 2006-05-14 at 20:52, Daniel Leidert wrote: > > [..] > > > > In general, my understanding of "Science" is in the sense of research > > > > and not education. > > > > > > I do not agree. Education also means science. It doesn't just mean > > > "teaching". For me, there is no difference between Science and > > > Education. Where is the difference IYO? > > > > > > > Exactly this is the key: > > > > Education: teaching > > you are teached/trained to be able to do something > > or to teach others > > improve individual wisdom/skills. > > > > Science:research > > you apply the above to find something new. > > improve the global pool of wisdom. > > I know that opinion of course. But "education" with the meaning of > "higher education" isn't that far away from "science". I know, people > have different opinions here. Just a few questions: > > Where do you make the difference between a scientific and an educational > software product? Let's say: What is a chemical structures editor? What > is a (software realized) calculator with scientific functions (like > those who are mostly used in education)? > As far as I understood the basic rules to tag applications, the answer is not a "one ot the other" decision. The chemical structureditor can be used for both purposes. Thus add the application in 2 entries of the tree. A "calculator" is a common tool used in nearly all categories. Such a global tool covers a few percent from lots of categories. Thus, this a candidate to go into a section like Science Common or Global or Misc or Science Math Calculator and Education Math Calculator compared with a tool like axiom, which would go in "Science -> Math" only. Due to my opinion, that when doing Science Research you know the basics where in Teaching/Education you have more applications which tell you about the basics. The latter is like: how to do integration or differentiation, waht are Newton's rules in gravity the first is like: when I apply several of the basic rules to these measurements under given constraints then one can proof the existance of a sub-particle for a few nano seconds in nuclear physics. > Just think about, that you _must_ define the answer for at least the > first question if you make a difference in Debian's menu between > education and science. I'm really not happy with dividing between them, > because IMHO there is no clear difference. > I know that may be tricky and you are right. That's why I try to separate by learning/teaching already known basics :== Education and applying that find (new) rules or to improve exising rules :== Science/Research by top-down classification going from most global/abstract to more specific/specialised. For example. lots of math aplications one can use in physics, chemistry, bio, astronomy, ... too as compuatation is very common. The tricky point may be to find an abstraction. An application knowing all the keppler rules where you can focus on high level astronomical things would be category Astronomy. But you can use a programmable common language and add lots of functions as addional modules. Without the modules is would be Math. Kind Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
On Sun, May 14, 2006 at 11:42:24PM +0200, Thomas Walter wrote: > Hello, > > On Sun, 2006-05-14 at 22:26, Daniel Leidert wrote: > > Am Sonntag, den 14.05.2006, 21:55 +0200 schrieb Thomas Walter: > > > On Sun, 2006-05-14 at 20:52, Daniel Leidert wrote: > > > > [..] > > > > > In general, my understanding of "Science" is in the sense of research > > > > > and not education. > > > > > > > > I do not agree. Education also means science. It doesn't just mean > > > > "teaching". For me, there is no difference between Science and > > > > Education. Where is the difference IYO? > > > > > > > > > > Exactly this is the key: > > > > > > Education: teaching > > >you are teached/trained to be able to do something > > >or to teach others > > >improve individual wisdom/skills. > > > > > > Science:research > > >you apply the above to find something new. > > >improve the global pool of wisdom. > > > > I know that opinion of course. But "education" with the meaning of > > "higher education" isn't that far away from "science". I know, people > > have different opinions here. Just a few questions: > > > > Where do you make the difference between a scientific and an educational > > software product? Let's say: What is a chemical structures editor? What > > is a (software realized) calculator with scientific functions (like > > those who are mostly used in education)? > > > > As far as I understood the basic rules to tag applications, > the answer is not a "one ot the other" decision. > The chemical structureditor can be used for both purposes. > Thus add the application in 2 entries of the tree. > > A "calculator" is a common tool used in nearly all categories. > Such a global tool covers a few percent from lots of categories. > Thus, this a candidate to go into a section like > Science > Common or Global or Misc > or > Science > Math > Calculator > and > Education > Math > Calculator > > > compared with a tool like axiom, which would go in "Science -> Math" > only. > > Due to my opinion, that when doing Science Research you know the basics > where in Teaching/Education you have more applications which tell you > about the basics. > The latter is like: > how to do integration or differentiation, waht are Newton's rules in > gravity > the first is like: > when I apply several of the basic rules to these measurements under > given constraints > then one can proof the existance of a sub-particle for a few nano > seconds in nuclear physics. > > > Just think about, that you _must_ define the answer for at least the > > first question if you make a difference in Debian's menu between > > education and science. I'm really not happy with dividing between them, > > because IMHO there is no clear difference. > > > > I know that may be tricky and you are right. > That's why I try to separate by learning/teaching already known basics > :== Education and applying that find (new) rules or to improve exising > rules :== Science/Research by top-down classification going from most > global/abstract to more specific/specialised. > > For example. lots of math aplications one can use in physics, chemistry, > bio, astronomy, ... too as compuatation is very common. The tricky > point may be to find an abstraction. > An application knowing all the keppler rules where you can focus on high > level astronomical things would be category Astronomy. But you can use > a programmable common language and add lots of functions as addional > modules. Without the modules is would be Math. > My suggestion, made elsewhere on this thread, to pattern the categories after the departments of several, or many, major universities, really handles this issue: there departments of education in enough major universities to make the cut for inclusion as a category. A quick look at the web sites of these departments will give a good idea of what 'belongs' in the education category. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Am Sonntag, den 14.05.2006, 23:42 +0200 schrieb Thomas Walter: > On Sun, 2006-05-14 at 22:26, Daniel Leidert wrote: [..] > > Where do you make the difference between a scientific and an educational > > software product? Let's say: What is a chemical structures editor? What > > is a (software realized) calculator with scientific functions (like > > those who are mostly used in education)? > > > > As far as I understood the basic rules to tag applications, > the answer is not a "one ot the other" decision. > The chemical structureditor can be used for both purposes. > Thus add the application in 2 entries of the tree. Uhh. Probably not a good idea. I guess, then you end up with 90% of the application in both entries of the tree and just 10% in one or the other entry. > Due to my opinion, that when doing Science Research you know the basics > where in Teaching/Education you have more applications which tell you > about the basics. Yes. But these are the extremas. I don't think, that you can take bunch of applications and say, what the user itself knows about the basics or for what the user uses the software. > The latter is like: > how to do integration or differentiation, waht are Newton's rules in > gravity > the first is like: > when I apply several of the basic rules to these measurements under > given constraints > then one can proof the existance of a sub-particle for a few nano > seconds in nuclear physics. Yes. But these are clear examples. I have a repository full of chemistry related packages. One e.g. supports a bunch of quantum chemistry packages. But it is designed to help users of these packages. The application itself doesn't teach anything, but it helps teaching quantum chemistry packages. So I just need a clear definition, when to put an application into Education and when to put an application into Science. > > Just think about, that you _must_ define the answer for at least the > > first question if you make a difference in Debian's menu between > > education and science. I'm really not happy with dividing between them, > > because IMHO there is no clear difference. > > > > I know that may be tricky and you are right. > That's why I try to separate by learning/teaching already known basics > :== Education and applying that find (new) rules or to improve exising > rules :== Science/Research by top-down classification going from most > global/abstract to more specific/specialised. Ok. But staying at the example of a simple structures editor (I know more then 6 in the OS scene): It is not designed to teach the user nor is it designed to find new rules or improve anything. It's just a tool used in educational and scientific institutions. > For example. lots of math aplications one can use in physics, chemistry, > bio, astronomy, ... too as compuatation is very common. The tricky > point may be to find an abstraction. Ok. But in this case it's IMHO easier. > An application knowing all the keppler rules where you can focus on high > level astronomical things would be category Astronomy. If that's the main function/feature/job, ACK. > But you can use > a programmable common language and add lots of functions as addional > modules. Without the modules is would be Math. Ok. Let's say, the main function/job/role makes the difference, so only applications which are real teaching programs (like e.g. tools to teach langauges or the PSE like kalzium or gperiodic) have to go into Education. All other applications go into Science, independent if they are used in school or university science education or for research. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
* Daniel Leidert <[EMAIL PROTECTED]> [2006-05-15 01:25:57]: > > The latter is like: > > how to do integration or differentiation, waht are Newton's rules in > > gravity > > the first is like: > > when I apply several of the basic rules to these measurements under > > given constraints > > then one can proof the existance of a sub-particle for a few nano > > seconds in nuclear physics. > > Yes. But these are clear examples. I have a repository full of chemistry > related packages. One e.g. supports a bunch of quantum chemistry > packages. But it is designed to help users of these packages. The > application itself doesn't teach anything, but it helps teaching quantum > chemistry packages. So I just need a clear definition, when to put an > application into Education and when to put an application into Science. I'd like to jump in a little bit here. I think this question (should an app go in Education or Science? or really any category for that matter) really might be best answered by the software authors themselves. I think they have a pretty good idea of what the primary purpose of their app is and what users use it for. This is why I'd like to see a push to provide .desktop (freedesktop.org compliant [1] and [2]) files to upstreams who can tweak the Categories if need be. On the Ubuntu side we made a big push to get .desktop files put in science apps for Dapper (to be released June 1) since we don't use the Debian menu system. We added about 45 .desktop files out of the ~450 packages we (MOTU Science team [3]) track. The next task is to get them upstream at least to Debian (via bug reports) and hopefully to the software authors. One reason I've pushed for this is that I'd like to see a Science menu in Gnome. Right now, science apps go in either Education, Other, or Graphics (for plotting apps) in the Gnome menu and more often than not they don't show up at all because they have no .desktop file. -Jordan Mantha [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ [2] http://standards.freedesktop.org/menu-spec/latest/ [3] https://wiki.ubuntu.com/MOTU/Teams/Science -- "That's all very well in practice, but will it ever work in theory?" -- G. Hill "A tidy laboratory means a lazy chemist." -- Jöns Jacob Berzelius -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
> >FWIW, I would argue that mathematics is not a science -- it does not use > >the scientific method, there is no hypothesis and experimentation -- it > >is a more self-contained discipline that, while it seeks to be useful, > >is not bound to modelling the physical world. > > I think of new ways to try and simulate things faster or in a simpler > way. Then i'll write the simulation and try the ideas and measure its > performance and accuracy. This applied mathematics is very much like > a real-world engineering problem with hypothesis and experimentation. Hmm, perhaps I didn't express myself properly. Of course, any discipline can use hypothesis and experimentation, from the arts to astrology. What I mean is: in the physical sciences, hypothesis and experimentation are fundamental to building "scientific truth". This is because the basis of science is trying to understand the physical world, formulating theories that explain what is seen, and then testing and refining these theories. This is what the "scientific method" is for. On the other hand, "mathematical truth" is based on pure logic and proof. It need not have any link to the physical world (though it often does). Experimentation can be a useful guide, but it is certainly not essential, and indeed experimental results are generally not accepted as a method of establishing mathematical facts. The result of all of this is that mathematicians can be more sure of their truths than scientists, but on the other hand their work is often somewhat less useful from a practical point of view. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
To answer here, taking into account other suggestions, i believe that the less we cut science into pieces the better the result. Specialisation has resulted to be a negative trend in university education (all over the world). When industry seeks for a fresh graduate biologist, industry seeks for a strong general background, not specialisation. That said, I would not go much farther in cutting sciences into pieces than Mathematics Physics Biology Medicine Maybe I am overlooking one or two important "cuts". Suggest. These sections allow interdisciplinary contacts. Today, more perhaps than ever, it is hard to do good science that is not interdisciplinary. The more you cut into pieces, the more you isolate scientists because, for economy reasons, one tends to scan only his specialized section. These are my ideas of an university organic chemist with parallel education in biological sciences. In particular, i am against "tasks" with respect to "disciplines". Tasks change with small changes in the society. Disciplines are for a long time a reference point. regards francesco pietra On Monday 15 May 2006 04:57, Ben Burton wrote: > > >FWIW, I would argue that mathematics is not a science -- it does not use > > >the scientific method, there is no hypothesis and experimentation -- it > > >is a more self-contained discipline that, while it seeks to be useful, > > >is not bound to modelling the physical world. > > > > I think of new ways to try and simulate things faster or in a simpler > > way. Then i'll write the simulation and try the ideas and measure its > > performance and accuracy. This applied mathematics is very much like > > a real-world engineering problem with hypothesis and experimentation. > > Hmm, perhaps I didn't express myself properly. Of course, any > discipline can use hypothesis and experimentation, from the arts to > astrology. > > What I mean is: in the physical sciences, hypothesis and experimentation > are fundamental to building "scientific truth". This is because the > basis of science is trying to understand the physical world, formulating > theories that explain what is seen, and then testing and refining these > theories. This is what the "scientific method" is for. > > On the other hand, "mathematical truth" is based on pure logic and > proof. It need not have any link to the physical world (though it often > does). Experimentation can be a useful guide, but it is certainly not > essential, and indeed experimental results are generally not accepted as > a method of establishing mathematical facts. The result of all of this > is that mathematicians can be more sure of their truths than scientists, > but on the other hand their work is often somewhat less useful from a > practical point of view. > > Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
[not replying to the bug to avoid surcharging it.] Le Mon, May 15, 2006 at 06:42:06AM +0200, Francesco Pietra a écrit : > Mathematics > Physics > Biology > Medicine > > Maybe I am overlooking one or two important "cuts". Suggest. These sections > allow interdisciplinary contacts. Today, more perhaps than ever, it is hard > to do good science that is not interdisciplinary. The more you cut into > pieces, the more you isolate scientists because, for economy reasons, one > tends to scan only his specialized section. > > These are my ideas of an university organic chemist with parallel education > in biological sciences. In particular, i am against "tasks" with respect > to "disciplines". Tasks change with small changes in the society. Disciplines > are for a long time a reference point. Dear Francesco, I am just reading a paper in which researcher designed a microfluidic chip to analyse the gene expression in isolited cells. Typically, they may have used programs from : - Engeneering/Electronics, to design the chip. - Science/Biology, to deal with the sequence-specifig gene expression analysis. - Mathematics, to plot the results. Would not it be better with - Science/Vectorial design (for sure, there must be a better name) - Science/Sequence analysis - Science/Data plotting I agree that the concept of task is somehow volatile, but if the name of the task has an obvious meaning in the present, is the volatility really a problem ? I think that having tasks avoids the "economic scanning" you described in your mail: people will have an unbiased toolbox instead of havin the tools scattered in boxes with "not for you" subliminal stickers. PS: I could not figure out whether it is allowed for a program to appear more than once in the menu. Best regards, -- Charles Plessy Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Hello, On Mon, 2006-05-15 at 01:25, Daniel Leidert wrote: [snip] > > Ok. Let's say, the main function/job/role makes the difference, so only > applications which are real teaching programs (like e.g. tools to teach > langauges or the PSE like kalzium or gperiodic) have to go into > Education. All other applications go into Science, independent if they > are used in school or university science education or for research. > Yes, that seems to be a good approach and has also a clear and simple definition how to do the classification between education related and science related. Kind Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Hello, On Sun, 2006-05-14 at 19:20, Bill Allombert wrote: > On Sun, May 14, 2006 at 06:20:25PM +0200, Thomas Walter wrote: [snip] > > > In general, my understanding of "Science" is in the sense of research > > and not education. > > Thus an example breakdown within Sience could be like > > Mathematics > > Physics > > Bio > > Chemistry > > Astronomics > > Geology > > Could you provide packages list to flesh these sections ? > Yes, either see at https://wiki.ubuntu.com/UbuntuScientists or perhaps at a very old page about SAL http://sal.jyu.fi/sal1.shtml [snip] Kind Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
I actually find splitting "Science" a good idea. I did a little research and came up with this list of possible subsections, along with example fields they cover: Astronomy * Astrodynamics * Astronomy * Astrophysics * Cosmology * Radio astronomy Biology * Anatomy * Bioinformatics * Botany * Ecology * Genetics Chemistry * Analytical chemistry * Biochemistry * Inorganic chemistry * Materials science * Organic chemistry Geoscience * Geodesy * Geography * Geology * Hydrology * Meteorology Medicine * Anatomy * Dermatology * Gynecology * Immunology * Neurology Physics * Acoustics * Cryogenics * Dynamics * Mechanics * Nuclear physics Social * Anthropology * Demography * Economics * Geography * Law We also have "Electronics", "Engineering", and "Mathematics" that are somewhat subject to discussion, but could also go into "Science", depending on how broad your definition of "Science" is. I did not include "Education", because I do not consider this section appropriate for "Science". It is more likely to contain quizzes, student-tracking software etc., rather than something an expert is likely to use. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
On Tue, May 16, 2006 at 02:25:37AM +0300, Linas ??virblis wrote: > I actually find splitting "Science" a good idea. > > I did a little research and came up with this list of possible > subsections, along with example fields they cover: > > Astronomy > * Astrodynamics > * Astronomy > * Astrophysics > * Cosmology > * Radio astronomy > > Biology > * Anatomy > * Bioinformatics > * Botany > * Ecology > * Genetics > > Chemistry > * Analytical chemistry > * Biochemistry > * Inorganic chemistry > * Materials science > * Organic chemistry > > Geoscience > * Geodesy > * Geography > * Geology > * Hydrology > * Meteorology > > Medicine > * Anatomy > * Dermatology > * Gynecology > * Immunology > * Neurology > > Physics > * Acoustics > * Cryogenics > * Dynamics > * Mechanics > * Nuclear physics > > Social > * Anthropology > * Demography > * Economics > * Geography > * Law > > We also have "Electronics", "Engineering", and "Mathematics" that are > somewhat subject to discussion, but could also go into "Science", > depending on how broad your definition of "Science" is. > > I did not include "Education", because I do not consider this section > appropriate for "Science". It is more likely to contain quizzes, > student-tracking software etc., rather than something an expert is > likely to use. > This suggestion contains examples of the problem in categorizing scientific fields of study: Science is, in essence, elitist, e.g. "... I do not consider ..." No 'real' scientist pays attention to Creation Science, except in the context of his general concern about the quality of public education. This is not my opinion about Creation Science, but a observation about the nature of science as a social activity, and the people who engage in it. But it is also true that most scientists tend to place their own chosen field close to the pinacle of the elitist heirarchy. On a more detailed level, I think that Thermodynamics, and Electricity and Magnetism belong to Physics. But it seems that they have been given over to the care of engineers. Or is engineering a branch of science? Are there some engineers who are scientists and others who are not? I suggest that we, the Debian community, look to what is being taught to the next generation of elitists at the major research universities of the world for a pattern for organizing the menus. Also, it is my impression that all first world countries have some sort of umbrella organization of elite scientists. In the US it is the National Academy of Science. Can these organizations be contacted for help on the menu issue? It may be difficult because each might insist on Debian accepting their solution to the exclusion of that from other countries. This has been a problem in the naming of units of measure. -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
One thing about scientists is sure, we all love to argu^H^H^H^H discuss. That is definitely a positive thing and allows careful consideration of the various points of view of a topic that may not be obvious to everyone, so rock on! As far as this menu issue goes, there have been some good points made about organization and classification schemes. However I think the real point of this discussion is how should a menu be organized to facilitate easy and logical navigation to an app. That said, I think we should not overly subdivide. If the menu depth gets too large, we will be spending more time clicking menu levels than scanning a menu list for the app name. For example in my experience, I may have a couple of astronomy apps, but rarely 50 installed on any one system. I doubt many users will want to click Apps -> Science -> Astronomy -> Cosmology to get a list containing 1 cosmology program that is installed. Same for other fields of science. How many of us actually have more than 5-10 apps installed for a given field? Also, to avoid some of the confusion about Education vs Science, would it make sense to replace "Education" with "Teaching" and use that category for quiz tools, etc? Cheers, JDR
Re: Bug#361418: Debian menu and the Apps/Science section
I agree with the following two points and would like to expand on them, answer the third and make another suggestion as to how we should be thinking about the problem.I think the real point of this discussion is how should a menu be organized to facilitate easy and logical navigation to an app.I think we should not overly subdivide. How many of us actually have more than 5-10 apps installed for a given field? The first point is true, but should be stressed as to WHO uses this menu for easy and logical navigation. The people who regularly use a particular application rarely use the menu system to access it, and instead simply type in the appropriate command. This means that logical navigation is a bit more important that easy navigation. We are designing this menu for NEW users, who have no idea what programs are available to them and do not know any other way of finding them. Naturally, they will want to browse what is available in their particular speciality, but when they begin to get to work, they may also want to browse by the functionality of the program, not which discipline tends to use it. The second point is very important, but only to a limit. Browse the Apps>>Tools on the debian menu, and you will find WAY too many programs, thus making the entire menu system useless. I suggest that each end category contain a maximum of ten programs. If more are written we can further subdivide that particular branch (science or tools) Using this rule of thumb, I suggest the following menu changes: 1) XShells goes to Shells>>XShells, and the contents of Apps>>Shells (thus reducing the number of selections in Apps) 2) Apps>>Tools>> Add a list of tasks in the tools menu and subdivide by which program performs that particular task making sure that only 10 or less programs appear in each item on the list. Scientists are free to use the tools menu item too. Unfortunately, this list is not up for discussion on this forum, but I will add in my suggestion: Plotting Simulation Conversion Organization and a few others. 3) Apps>>Science>> This is where we can provide ONE list of GENERAL science topics. I suggest using names of departments in a large university. I used life sciences and social sciences to minimize on the number of menu items, while maintaining clarity. I suggest: Engineering Chemistry Physics Medicine Geography Computer Science Statistics Life Sciences Social Sciences As an engineer, who is also a scientist (and many are not), I will defend the need for a separate menu item. In the future, when more academics learn how to program, we will have many more science programs to use, and at that point we can add subdivisions to these categories. Any comments?
Re: Bug#361418: Debian menu and the Apps/Science section
Le mardi 16 mai 2006 à 12:14 -0700, JD Rogers a écrit : > That said, I think we should not overly subdivide. If the menu depth > gets too large, we will be spending more time clicking menu levels > than scanning a menu list for the app name. For example in my > experience, I may have a couple of astronomy apps, but rarely 50 > installed on any one system. I doubt many users will want to click > Apps -> Science -> Astronomy -> Cosmology to get a list containing 1 > cosmology program that is installed. Same for other fields of science. I would very much agree with this. Actually, I thought it was possible to give "hints" in the .menu files, so that update-menu automatically creates relevant submenus only when the number of installed packages gets large. If my understanding is correct, one could put for program A "Astronomy, Sky Charts" and for prog. B "Astronomy, Data Visualisation" so that if I have a lot of astronomy programs installed, I'll get the submenus "Sky charts" and "Data Visualisations", but if I've got programs from all fields, I'll get "Astronomy" and, say, "Genetics" (and if I've got only a couple of softs, I won't end up with any 1 item submenus, which is good). In that case, why not rather prepare a list of standardised hints rather than a fixed subdivision? Quite honestly, in how many circumstances will someone have programs relevant for more than one field installed? The "Games" case is different: I'd bet most people who install games install a lot of them. Regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
[snip] The first point is true, but should be stressed as to WHO uses this menu for easy and logical navigation. The people who regularly use a particular application rarely use the menu system to access it, and instead simply type in the appropriate command. This means that logical navigation is a bit more important that easy navigation. We are designing this menu for NEW users, who have no idea what programs are available to them and do not know any other way of finding them. Naturally, they will want to browse what is available in their particular speciality, but when they begin to get to work, they may also want to browse by the functionality of the program, not which discipline tends to use it. That is a very good point. I never use the menu at all, primarily because navigating the menu IS so convoluted. I was thinking I might actually use it more if there was better organization, but I like your point.. the menu system should really be thought of as a tool to organize apps for one who doesn't know what app they want to use, but knows what they want to accomplish. The second point is very important, but only to a limit. Browse the Apps>>Tools on the debian menu, and you will find WAY too many programs, thus making the entire menu system useless. Heh, I was thinking of making the exact opposite statement. On my system, "apps->tools" contains 21 items (though I don't have all of kde and gnome on this system). I find that perfectly easy to scan down and see potential programs. However, if a menu is too deep (i.e. greater than 4 levels), it becomes virtually impossible to 'browse' since one has to constantly backtrack without falling off the menu with the mouse. I was therefor thinking of proposing an upper limit on menu depth rather than width. You make a great point though, so maybe the issue comes down to finding an aspect ratio that is a good balance between the two. I suggest that each end category contain a maximum of ten programs. If more are written we can further subdivide that particular branch (science or tools) My preference would be for an upper limit of more like 15-20 items per list, but I like the idea. [snip] 3) Apps>>Science>> This is where we can provide ONE list of GENERAL science topics. I suggest using names of departments in a large university. I used life sciences and social sciences to minimize on the number of menu items, while maintaining clarity. I suggest: Engineering Chemistry Physics Medicine Geography Computer Science Statistics Life Sciences Social Sciences I like this list. I think the length is good and leaves few gaps. Logically, I tend to think of Medicine as a category under Life Sciences, but perhaps the disproportionate number of potential entries under Med warrant it's separation. Also, Statistics seems out of place under science. I would suggest putting it in the tools section you mentioned before or under a broader section such as "math tools" under science. Several suggestion have been to look at classifications used in Universities, but maybe going the other direction is better. The broader groupings used in High Schools or the equivalent might keep things simpler. As an engineer, who is also a scientist (and many are not), I will defend the need for a separate menu item. In the future, when more academics learn how to program, we will have many more science programs to use, and at that point we can add subdivisions to these categories. I'll agree that a separate menu item is warranted (especially for things like CADand design programs), but does it belong under science? Cheers, JDR
Re: Bug#361418: Debian menu and the Apps/Science section
> The second point is very important, but only to a limit. Browse the > Apps>>Tools on the debian menu, and you will find WAY too many programs, > thus making the entire menu system useless. [snip] You make a great point though, so maybe the issue comes down to finding an aspect ratio that is a good balance between the two. [snip] > As an engineer, who is also a scientist (and many are not), I will defend > the need for a separate menu item. In the future, when more academics > learn how to program, we will have many more science programs to use, and > at that point we can add subdivisions to these categories. I was thinking about this more, and its clear that one solution will not be ideal for all systems, or for the future as more apps are added. So would it add unreasonable complexity to the menu system to have the menu semi-dynamic? The idea is that it would split categories as more apps are installed, or combine lists and move them up a level if apps are removed. Imagine a situation where under all of science, I only have 2 apps. Then in the menu system, you would only have "apps -> science -> list of apps". Then later you install 15 apps and the menu system sees that you exceeded a threshold of 10 and then divides the science menu into a sub menu "apps -> science -> physics and life science". Then if physics might later hit a limit and split into astronomy and mechanics, etc. If some apps are removed and the threshold is no longer exceeded, the sublists could get bumped back up a level. The cool thing about this is that nothing would ever get moved to a different branch of the menus, so as the menu changed, it would still be easy to find the app one is searching for. The length/depth of the branch would just change to keep the aspect ratio reasonable. Maybe this is just crazy, but what does everyone think?
Re: Bug#361418: Debian menu and the Apps/Science section
added. So would it add unreasonable complexity to the menu system to have the menu semi-dynamic? The idea is that it would split categories Bah, I should have read Thibaut Paumard's post first.. sounds like my idea of dynamic menus is already in place to some extent with menu-hints.
Re: Bug#361418: Debian menu and the Apps/Science section
My preference would be for an upper limit of more like 15-20 items perlist, but I like the idea. 15-20 would be ok if the names of the programs are more informative (not that it matters once you know what they do). Logically, I tend to think of Medicine as a category under LifeSciences, but perhaps the disproportionate number of potential entries under Med warrant it's separation. Medicine is applied life science much like Engineering is applied science in general (including many medical topics). It might be better to place various disciplines under life science such as: Biology Zoology Medicine Pharmacy ect (which could be triggered using the above suggestion if the amount of applications exceed a threshold value between 15 and 20 lets say) Also, Statistics seems out of place under science. I would suggestputting it in the tools section you mentioned before or under a broader section such as "math tools" under science. Yes, I agree as they tend to use other peoples data, but they do create their own data and make many models which they test against to find better ways of dealing with uncertainty. Besides, they create a prodigious amount of interesting computer programs specific to their discipline, and not all of them are tools. Some of these programs belong in tools as well, but is there any harm in some poly functional program being in two (or more) different menus? > As an engineer, who is also a scientist (and many are not), I will defend > the need for a separate menu item. In the future, when more academics learn> how to program, we will have many more science programs to use, and at that> point we can add subdivisions to these categories. I'll agree that a separate menu item is warranted (especially forthings like CADand design programs), but does it belong under science? I do see the point, but the solution lies in cleaning up our definition of the tools menu. We could put engineering design tools into Apps>>Tools>>Design and Apps>>Tools>>Simulation or Apps>>Engineering>>Design and Apps>>Engineering>>Simulation. There are far too few open source design tools currently, but I expect the number to grow very rapidly so a separate menu item may be needed for engineering apart from science. We could even call it applied science. In general I agree with your points. Cheers, David
Re: Bug#361418: Debian menu and the Apps/Science section
I went on and made a list of applications that are currently found in "Science" [science] and another one with these applications roughly sorted into sections [science_sorted]. The short version: Analysis [10] Astronomy [12] Biology [16] Chemistry [11] Geoscience [5] Medicine [1] Physics [5] Social [0] Undetermined [4] Total: 64 Note that this is a number of different _packages_ that contain entries in "Science". Many packages contain more than one entry, some are built from single source, etc. Take with a grain of salt. Now more on my findings. I was surprised not to find a single application suitable for "Social" section. There certainly are some, but they seem to be scattered all over the menu. "gnomesword" is in "Education", for example. There may be intersection between "Text", found in current menu draft, and what "Social" should be. Currently "Text" mostly contains dictionaries, but if "Social" is to be created, it is likely to contain dictionaries only. Therefore "Text" needs to be revisited. I have only located a single medicine-related application, but there are more in other sections. The whole bunch of gnumed-* packages is a good example. I added another section named "Analysis", that contains general data analysis/plotting/calculation applications. I find them very similar to what is found in "Math", so I consider moving "Mathematics" to "Science" a good idea. "Undetermined" is by no means a section name. This is where I listed applications that I think might belong to some other section, or could not determine an appropriate one. klogic- electronics megahal - ??? pybliographer - data management praat - ??? In my previous post I suggested moving "Electronics" and "Engineering" to "Science". My words are still valid. I would prefer to continue this discussion on debian-policy, as it is getting hard to follow. arb - [Biology] Integrated package for data handling and analysis avida-qt-viewer - qt viewer for avida blast2 - Basic Local Alignment Search Tool boxshade- [Biology] Pretty-printing of multiple sequence alignments cassbeam- A program for Cassegrain antenna modelling celestia- A real-time visual space simulation (KDE frontend) celestia-glut - A real-time visual space simulation (GLUT frontend) celestia-gnome - A real-time visual space simulation (Gnome frontend) chemtool- Chemical structures drawing program clustalw- [Biology] Global multiple nucleotide or peptide sequence alignment clustalx- [Biology] GUI for clustalw dx - OpenDX (IBM Visualization Data Explorer) - main package earth3d - Map client displaying a 3D model of the world fityk - general-purpose nonlinear curve fitting and data analysis g3data - extract data from scanned graphs garlic - A visualization program for biomolecules gdis- molecular display gdpc- visualiser of molecular dynamic simulations ghemical- A GNOME molecular modelling environment gperiodic - periodic table application ifrit - a powerful tool for visualizing 3-dimensional data sets imview - Image viewing and analysis application ygraph - Visualize one-dimensional scientific data kalzium - chemistry teaching tool for KDE kboincspy - monitoring utility for the BOINC client klogic - digital circuit editor and simulator for KDE kstars - desktop planetarium for KDE kst-bin - A KDE application used for displaying scientific data kxterm - Cernlib's KUIP terminal emulator leksbot - An explanatory dictionary of botanic and biological terms libncbi6-dev- NCBI libraries for biology applications (development files) lynkeos.app - Tool to process planetary astronomical images for GNUstep loki- [Biology] MCMC linkage analysis on general pedigrees megahal - conversation simulator that can learn as you talk to it mn-fit - interactive analysis package for fitting data and histograms mssstest- Normalisation of disease scores for patients with Multiple Sclerosis ncbi-tools-bin - NCBI libraries for biology applications (text-based utilities) ncbi-tools-x11 - NCBI libraries for biology applications (X-based utilities) njplot - [Biology] A tree drawing program paje.app- generic visualization tool (Gantt chart and more) paw - Physics Analysis Workstation - a graphical analysis program paw++ - Physics Analysis Workstation (Lesstif-enhanced version) perlprimer
Re: Bug#361418: Debian menu and the Apps/Science section
Hello, Le mardi 16 mai 2006 à 12:14 -0700, JD Rogers a écrit : > > That said, I think we should not overly subdivide. If the menu depth > > gets too large, we will be spending more time clicking menu levels > > than scanning a menu list for the app name. For example in my > > experience, I may have a couple of astronomy apps, but rarely 50 > > installed on any one system. I doubt many users will want to click > > Apps -> Science -> Astronomy -> Cosmology to get a list containing 1 > > cosmology program that is installed. Same for other fields of science. > > I would very much agree with this. Actually, I thought it was possible > to give "hints" in the .menu files, so that update-menu automatically > creates relevant submenus only when the number of installed packages > gets large. > > If my understanding is correct, one could put for program A "Astronomy, > Sky Charts" and for prog. B "Astronomy, Data Visualisation" so that if I > have a lot of astronomy programs installed, I'll get the submenus "Sky > charts" and "Data Visualisations", but if I've got programs from all > fields, I'll get "Astronomy" and, say, "Genetics" (and if I've got only > a couple of softs, I won't end up with any 1 item submenus, which is > good). > > In that case, why not rather prepare a list of standardised hints rather > than a fixed subdivision? Quite honestly, in how many circumstances will > someone have programs relevant for more than one field installed? > That is an appoach I suggested somewhere in theis thread. Use some tags attached to each application or program similar o debtags. You secend question, you have a box, which may be used by several users. Then any users sees all programs, but preferences in using a specific program may differ. In addition, the programs are not equal. One has more strength in that direction, the other is better for that specific goal. And sometime you know what you want to do, and you are happy to see 2 or 3 choices, and you can choose just by your own decision, because you prefer the way of doing. [snip] Kind Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
> I added another section named "Analysis", that contains general data > analysis/plotting/calculation applications. I find them very similar to > what is found in "Math", so I consider moving "Mathematics" to "Science" > a good idea. Again: we see that scientists make heavy use of mathematics, so all mathematics packages should be classified under "Science"? We might as well file all mathematics packages under "Economics" for the same reason. I think it's wonderful that scientists get so much value out of mathematical software, but they are not the only ones -- why does this mean that every piece of mathematical software needs to be filed in the science drawer? Currently mathematics and science have their own sections in all the places I frequent (debian archive sections, the KDE menu, the debian menu system); this seems quite sane to me, and it's not clear to me why this needs to be changed. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
The cool thing about this is that nothing would ever get moved to adifferent branch of the menus, so as the menu changed, it would still be easy to find the app one is searching for. The length/depth of thebranch would just change to keep the aspect ratio reasonable.Maybe this is just crazy, but what does everyone think? If it is well thought out and not buggy, then it would be a very cool menu indeed. One problem that might arise is if a program, for instance, is classified as physics by the menu, but the user has classified the program in their head as chemistry before the menu subdivides and thus has trouble finding it. Of course, if they use the program frequently they would not be using the menu at all, so this is a small point.
Re: Bug#361418: Debian menu and the Apps/Science section
On Tue, 16 May 2006, JD Rogers wrote: That said, I think we should not overly subdivide. If the menu depth gets too large, we will be spending more time clicking menu levels than scanning a menu list for the app name. For example in my experience, I may have a couple of astronomy apps, but rarely 50 installed on any one system. I doubt many users will want to click Apps -> Science -> Astronomy -> Cosmology to get a list containing 1 cosmology program that is installed. Same for other fields of science. How many of us actually have more than 5-10 apps installed for a given field? I second this idea. I like to have all the applications I use frequently in the same section (Science). I routinely use physics and chemistry programs and I only see myself wasting time in clicking down a huge menu tree. Cheers, Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
Ben Burton <[EMAIL PROTECTED]> wrote: > > > >FWIW, I would argue that mathematics is not a science -- it does not use > > >the scientific method, there is no hypothesis and experimentation -- it > > >is a more self-contained discipline that, while it seeks to be useful, > > >is not bound to modelling the physical world. > > > > I think of new ways to try and simulate things faster or in a simpler > > way. Then i'll write the simulation and try the ideas and measure its > > performance and accuracy. This applied mathematics is very much like > > a real-world engineering problem with hypothesis and experimentation. > > Hmm, perhaps I didn't express myself properly. Of course, any > discipline can use hypothesis and experimentation, from the arts to > astrology. > > What I mean is: in the physical sciences, hypothesis and experimentation > are fundamental to building "scientific truth". This is because the > basis of science is trying to understand the physical world, formulating > theories that explain what is seen, and then testing and refining these > theories. This is what the "scientific method" is for. My 8 year-old daughter was learning about "the scientific method" in school and asked me about it. I replied that I'd tell her, but that it's not used by all disciplines. In my experience, it's mostly biologists who start with an hypothesis to test. I certainly don't publish the testing of an hypothesis in my work. -- Peter Galbraith, Ph.D., research scientist <[EMAIL PROTECTED]> Ocean and Environmental Science Branch Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
