From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "S+*n_Pe*rm*n" Newsgroups: gmane.emacs.devel Subject: Re: tags for functions Date: Thu, 22 Jan 2009 13:15:21 -0500 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1232649428 15476 80.91.229.12 (22 Jan 2009 18:37:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2009 18:37:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: tzz@lifelogs.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 22 19:38:21 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LQ4RX-0004ja-9q for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2009 19:38:19 +0100 Original-Received: from localhost ([127.0.0.1]:57024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQ4QF-0008Q1-Uf for ged-emacs-devel@m.gmane.org; Thu, 22 Jan 2009 13:36:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQ45N-0000Oa-FL for emacs-devel@gnu.org; Thu, 22 Jan 2009 13:15:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQ45L-0000Mt-D3 for emacs-devel@gnu.org; Thu, 22 Jan 2009 13:15:23 -0500 Original-Received: from [199.232.76.173] (port=38356 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQ45L-0000Mo-8S for emacs-devel@gnu.org; Thu, 22 Jan 2009 13:15:23 -0500 Original-Received: from rn-out-0910.google.com ([64.233.170.186]:36366) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQ45K-0005lR-Vx for emacs-devel@gnu.org; Thu, 22 Jan 2009 13:15:23 -0500 Original-Received: by rn-out-0910.google.com with SMTP id k50so809774rnd.7 for ; Thu, 22 Jan 2009 10:15:22 -0800 (PST) Original-Received: by 10.64.21.10 with SMTP id 10mr770789qbu.48.1232648122017; Thu, 22 Jan 2009 10:15:22 -0800 (PST) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Thu, 22 Jan 2009 13:36:54 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:108106 Archived-At: 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