vocabulary structure

[Justin B Rye]

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)