Peter Rockai wrote: >> ...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...
Well, what I wanted to do was bring the conversation back to the example, but I was too wordy about it. > 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. I was understanding it as meaning something like "what kinds of file the package is built from" - fonts, icons, Perl modules, C code... (Looks it up) Ah, the long description says "the languages or data formats used to make the package"; sounds about right. It's true that the "made-from::code:c" and "made-from::code:c++" packages mostly end up on my system in a precompiled form; but that needn't stop us labelling them in terms of what they're constructed out of. >>> 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). Actually, rotten tagging would make it a lot easier to face the idea of just throwing tags out. But what problems are there? Is it just inconsistent decisions about whether trivial shell-scripts are worth adding a "made-of::lang:shell"? [...] > So we get development-language and > implementation-language. Does that sound plausible? Maybe with better facet > names? Sounds okay to me. I'm beginning to wonder whether this list is quorate, though. >>> 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 see half a dozen, but some of them look like mistakes. > I am quite sure > that's not nearly enough to justify separating these two. Er... okay, you've disproved something or other... but what has this got to do with the format:: facet? > 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. A lot of foo-data/foo-doc/foo-common packages are tagged in parallel with foo(-main) - so apache2-doc's tags claim that it "works-with" HTML, and so on. > On the other hand, if you had a contains:: facet, that would be somewhat > different. So it would be okay for apache2-doc to be both "contains::html" and "works-with::html"? > 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 :-). No, you've lost me. [...] >> 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. Okay. >> 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. To me it it seems only very slightly forced; but if there are independent theoretical arguments against nested subfacets I'd have no problem with them being shifted back. -- JBR Ankh kak! (Ancient Egyptian blessing) _______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
