vocabulary structure

[Justin B Rye]

Peter Rockai wrote:
> Justin B Rye wrote:
>> Peter Rockai wrote:
>>> There are some things bothering me about current vocabulary. One
>>> of them is the devel::lang: and made-of:: stuff. The
>>> made-of::<language> should probably go away for all
>>> turing-complete programming languages and be replaced with
>>> made-of::source-code.  devel::lang: should be just ripped out.
>> 
>> At present, the made-of::lang and devel::lang facets give two
>> different kinds of information.  It's possible (and informative) for
>> a package to be tagged "made-of::lang:c, devel::lang:python" or
>> vice-versa.
> 
> Yes, an information hardly worth 20+ extra tags.

Well, you have two votes against throwing the information away.

[snipping]

> The user interface is not supposed to show tag names. Those are internal. The
> short descriptions are what is relevant for the user. And that says
> Programming Language, as i say above. No way to confuse that with culture.

Yes, fair enough; let's forget about the names.  Except that...
 
>>> The cases where a package contains source code in language A but
>>> is primarily useful with language B can be handled by tagging with
>>> both language::A and language::B. The idea is that if it's written
>>> in A, it can be useful for A coders anyway -- studying code,
>>> reusing, etc... 
>> 
>> As an administrator, I would prefer to apt-get a bandwidth-monitor
>> made-of: C to one made-of: PHP.  But meanwhile I avoid everything
>> under devel: because I'm not a programmer.  To me, this looks like a
>> very bad idea.
> 
> Apart from the slight problem that C-implemented packages are not made-of C.
> If they are, the facet is completely nonsensical (there is no C code in the
> package).

...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.

>>> 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.

>>> As for rest of made-of, there's only data:*, so made-of::data and
>>> format:: (File Format) facet would be probably a good idea again.
>> 
>> Why exactly is it better to have a cluttered top level?
> 
> 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. 
 
>>> The other option is to double the format facet, but it doesn't
>>> make too much sense IMO. We can always fix it if it turns out to
>>> be a problem, so i vote on keeping it simple. 
>> 
>> "Double" in what sense?
> 
> 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.
 
>> 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?

> 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.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)