vocabulary structure

[Peter Rockai]

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