On Tue, Jun 27, 2006 at 01:53:06PM +0100, Justin B Rye wrote: [snip] > ...Now you're quibbling about the nomenclature (couldn't it equally > easily be the literally accurate "made-from::"?) while ignoring the > example. I'm not installing the bandwidth-monitor app for the > source code.
Well, so can you define the semantics of made-of in that case? I sort of assumed that the semantics of the facet are related to how it is named. But since you want to play the word catching game... oh wait, i don't play that one. Anyway, with your definition (from below), made-of:: is mixing "implementation language" and "formats of data files in the package" which look pretty unrelated to me. So not a good facet. > >>> So the language:: facet would go like "useful for coders in a > >>> given language". > >> > >> A special-interest facet which belongs under "devel::". > > > > No. There is no "facet hierarchy". For goodness sake. How long it takes till > > people grasp the concept? > > Does Stable have a user-friendly tag-editor that doesn't present it > as a hierarchy? When it does, go ahead and start the clock. Chicken-Egg problem. If we twist the vocabulary to work only in hierarchical editors you will never get a non-hierarchical one. Too bad, let's stop vocabulary development. Or no :-). > > Why exactly do you need to show all of the top level all the time? Besides. > > There is no hierarchy. So there are no levels other than "facet" and "tag". > > And if there's no difference, it can't be a change for the better! > But in fact I'm happy to concede the point about the facet > structure; what I care about is not throwing away information. Well, my main problem is that made-of is poorly defined (from looking at its tags, too). Another poorly defined one is devel:: (it gets a lot better when you throw out all the devel::lang: mess -- specifically because it doesn't fit with rest of the facet -- the "where it fits in development" concepts like debugger, compiler, interpreter, runtime, editor, ... are orthogonal with the language set the package is useful with). So we get development-language and implementation-language. Does that sound plausible? Maybe with better facet names? > > understands-format:: and contains-format:: (absence of better names, that'd > > have to be thought of in more detail) > > Ah, right. Yes, that sounds familiar. After a quick archive survey, there are 2 cases of package that have made-of::data:* tag and also contain any executable code. I am quite sure that's not nearly enough to justify separating these two. Basically, the problem with made-of:: is, that semantics seem to be "primary content of package", which means that if it's data it basically cannot be a program package which basically means there is no way it can "work with" anything. On the other hand, if you had a contains:: facet, that would be somewhat different. Question is, if such a facet would be useful at all. If it is, you can have contains::<what>, contains-format::<format> facets. Similar to the above language solution :-). > >> Please don't throw out the made-of::lang/devel::lang distinction. > > > > I won't if someone comes up with a plausible use case. On current archive. > > I thought I'd given one. If normal users aren't expected to be > interested in the difference between made-of::lang:c and > made-of::lang:php, why do so many package descriptions mention it? > Oh well, how about a specifically programmerish one: at present I > can quickly and easily search for a package "for coding in lisp, but > not written in lisp". Plausible? Implausible? Not quite, but not too important anymore. The argument drifted in wrong direction. > > Let's note that made-of::lang: has different semantics that implemented-in:: > > which is again slightly orthogonal. However, if something is > > made-of::lang:<scirpting language> it is usually also > > implemented-in::<scripting language>. However for compiled languages that is > > not true. > > As I understand it, all the tags from implemented-in:: were > automatically migrated to made-of::lang: - so you might say it's > more a matter of etymology than semantics... oh, wait, I'm arguing > semantics again, sorry. Well, the semantics of made-of::lang: are very obscure at best. They are definitely different from what the name of the facet implies. In contrast to that, implemented-in:: corresponds very well with semantics implied by the name and is very clear. So it is a good candidate for a facet. Basically, what we need is a sort of trigger for the user to say "i don't care about this facet" or "i am interested in this facet", in a list of facet descriptions, with sanely chosen defaults depending on the purpose of the application using the data. Given these facilities, we can have as many facets as we like, as long as they are well-defined and so on. In the end, it probably doesn't matter to me if the "implemented in" and "useful for programming in" concepts are kept and separated or the "implemented in" one is thrown away. The idea is that they are separated and aren't mingled into unrelated facets. Sounds like a decent compromise? Yours, Peter. -- Peter Rockai | me()mornfall!net | prockai()redhat!com | +421907533216 http://blog.mornfall.net | http://web.mornfall.net "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton on the subject of C program indentation _______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
