Re: tags for functions

["S+*n_Pe*rm*n" <stan@derbycityprints.com>]

Ted, I offer up the following with the caveat that I wouldn't be
taking the time to expound on this matter without the recognition your
ability to best implement the system. I apologize if my tone comes
across as overly pedantic - it is certainly not my intention.

>Well, at 180 pages of dense information this is a serious standard.

Its a serious subject matter.

>it defines "taxonomy" as a structural hierarchical classification,

I disagree - the standard doesn't make such an overt distinction -
this is your characterization/reduction.

>whereas I've used it loosely to mean a tag space.

'Tag Space/cloud' is a catch phrase for lazy cataloging - when
implemented on the scale you are proposing my intuition is that it
will fall over - do you know of such an implementation that doesn't?.

Tagging in the sense that you seem to be using the term is best left
to domains which lack a characteristic structure and/or which can't be
pre-limited/defined.

You have the opportunity *now* to reduce the number of potential core
`tags'. You appear to be suggesting that this is your intention. Such
an effort is best characterized as the production of a controlled
vocabulary.  Apropos of this, I am proposing you formalize the
production according to the best practices outlined by the standard.
Doing so will afford you the

>Since we're not classifying general knowledge but a very specific domain
>(Emacs Lisp functions).

This was my earlier point about programmers missing a very subtle distinction.
The domain of Emacs Elisp functions has specificity - to the extent
that there is a syntax and grammar for invoking those functions.

*What* the Emacs lisp code *does*, and *how* it is/may be *applied*,
and under what circumstances it may be best applied `generally' is an
entirely different matter. This is precisely why Elisp functions have
doc strings, why Emacs is self describing, and why promotes writing
code in a literate style.

>It makes some good points, but things like a full hierarchy are
>overkill

I suggest that a closer examination will reveal just the opposite.

> and others like proper name conventions just don't apply.
What about Internationalization?

>I'll try to be consistent with its naming recommendations, at least.

Good. This gist of the entire standard is relatively straightforward
and could can be reasonably reduced to a system of Suffix keywords
(terms) attached to the following `typed' Headwords:

- BT Broader Term
  BTG Broader Term (generic)  **
  BTI Broader Term (instance) **
  BTP Broader Term (partitive) **
- NT Narrower Term
  NTI Narrower Term (instance) **
  NTG Narrower Term (generic) **
  NTP Narrower Term (partitive) **
- RT Related Term
- TT Top Term
- U USE
- UF USED FOR
- HN History Note
- SN Scope Note

**These can be omitted and the system will retain its core functionality.

> It brings up "synonym rings" which may be necessary:

It brings up 4 possible domains of description - these aren't mutually
exclusive:

-Lists of controlled terms;
-Synonym rings;
-Taxonomies;
-Thesauri

>I propose 50% of the effort is to come from each package's predeclared >Keywords header.

I am suggesting that ceding this amount of effort to the author poses
an otherwise avoidable burden and is not DTRT esp. as Emacs Elisp
should provide this facility directly.

While the author of is the entity most aware of how his/her
functions/package inter-operate and she should be able to freely
assign keywords which she deems most appropriate as descriptors of
their potential domain of operation. However, what the author may not
be aware of is how his/her functions/packages inter-operate with a)
Emacs List and b) Other Packages/functions.

Placing the burden of awareness on the author is not an acceptable
solution. Emacs/Elisp should provide a controlled (extensible)
thesauri from which an package author can choose without concern for
how the entire system (extended or otherwise) operates.

> With synonym rings, we can associate synonymous keywords together.

Exaclty! This is in fact what the standard attempts to achieve and why
it was suggested as a guideline to best practices :)

So the issue then becomes how best to provide a thesauri which can
reasonably accommodate a diverse user base with diverse needs and
perspectives.

This is the domain of cataloging, *not* coding.

Your proposed implementation should also take into consideration that
the keyword structure need be robust enough to accommodate
internationalization. Again the standard addresses this in a coherent
fashion - `Tag Space' cannot accommodate internationalization issues.

Finally, I believe that in lieu of an increasing focus on FDL (Free
Documentation License) - Creative Commons - it is very important to
consider that much of what you are proposing is concerned with the
documentation side of Elisp code.  Future generations may well elect
to catalog and access this `content' as "prose" rather than as "code".

By accommodating a robust standard of thesauri construction such as
Z39.19 future GPL/FDL'd Elisp code would present an immediate
standardized mechanism by which code-librarians/catalogers might
readily access the information utilizing other standardized systems
such as Z39.50/ISO 23950 (Information Retrieval (Z39.50): Application
Service Definition and Protocol Specification).   In essence, not only
would such packages be 'self-describing/self-documenting' they would
also become 'self-cataloging' and potentially accessible via CQL
(Common Query Language) or whatever else comes along.

Stan