Re: Call for dictionary
-Original Message- From: A.R. (Tom) Peters [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, June 29, 1999 7:13 AM Subject: Re: Call for dictionary Your proposal - as I understand it - takes care that everybody uses consistent terminology instead of any of the possible synonyms. That leaves 2 problems un-addressed: My imprecisly worded proposal was to have a list of terms (acronyms and words/names/phrases/etc.). Specifically, my proposal was to provide a way to look up a term (acronym or word or ...) and determine if it was "perferred" or. if not, what the preferred term was (as a way to [1] help item writers and item reviewers maintain consistency[=quality] in items on the test and [2] define the list of terms which candidates should understand). I think we are in complete and total agreement about the exam NOT testing for arbitrary terms like MTA; rather, test for Linux knowledge. I agree completely. * The list will not mention terms (acronyms) that don't really have synonyms: for example, you either use "Mail Transfer Agent" or [...] I'm not sure I understand... Are you despairing of any list/dictionary/enumeration? Or what would relate "sendmail, smail, qmail, exim, ..." with MTA? This point I don't understand but I am *completely* open to modification or alternatives. Given the time crunch, as I said, alternative models would be appreciated. * Some terms may have different meaning in different context: I think we should offer some definition or description in cases where it may matter. This is a good point which I had not fully anticipated. In terms of my list proposal, the answer (which assumes grep as an interface) would be to simply have as many lines in the list as contexts. The list like you propose does not do that.[...] Let's agree on a definition/description field. Does that resolve your concern? It seems workable, but it has this implicit: apparently it is OK to use the acronym "DNS" (it is even the preferred term); whereas "NIC" should be spelled out "Network Interface Card". I thought of a list saying "These acronyms are OK to use (this is what they stand for...); other acronyms should be spelled out." Are you arguing for seperate lists for acronyms and for jargon? I don't how many lists this is. I agree with the idea that terms not on the list be spelled out in simple words. that afterwards. My concern is to specify in advance what to use and what to avoid in the objectives and tests. And BTW, I was hoping you were drafting some guidelines for item writers? Item writing is my vocation and my main concern. :) Regardig the guidelines, you're right; they were drafted some time ago and I revised have them slightly. I would be *VERY* open to input from anyone on the list. (As an aside: A non-English-native Linux user has, to date, supplied the best commentary). The URL is still: http://www.soltec.net/~amead/generic.html I found that writing a few sample items helped elicit some of the unspecified issues. And you point is well taken. I need to finish them very soon (send any comments now friends) and I have included the text of your consensus point but I don't know where to "draw the line" as you put it above. I guess the list would operationalize "the line" and I agree, that's probably the best way to do it. STATUS: Unless I hear otherwise, I am going to create a list with fields for: preferred term: definition/description: deprecated synonyms [preferred term: definition/description: deprecated synonyms (context 2)] [preferred term: definition/description: deprecated synonyms (...)] We (I) need it done in, ideally, the next few days. I will have the complete text of the objectives tomorrow so with any luck I will post a list for comments and additions (probably lots of additions!) tomorrow or the next day. Comments will be important. I had originally thought to use a web interface but I doubt there is time so people will just email me. -Alan This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Call for dictionary
On Wed, 30 Jun 1999, Alan Susan Mead wrote: -Original Message- From: A.R. (Tom) Peters [EMAIL PROTECTED] % cut % * The list will not mention terms (acronyms) that don't really have synonyms: for example, you either use "Mail Transfer Agent" or [...] I'm not sure I understand... Are you despairing of any list/dictionary/enumeration? Or what would relate "sendmail, smail, qmail, exim, ..." with MTA? This point I don't understand but I am *completely* open to modification or alternatives. Given the time crunch, as I said, alternative models would be appreciated. My concern was, that things that have no reasonable synonym (like Mail Transfer Agent) would not be included in the list, hence we would need another list for them. On MTA itself: in my vocabulary, sendmail is a Mail Transfer Agent. Mailreaders like pine are Mail User Applications, and procmail is a Mail Delivery Agent. If you understand these things otherwise, we definately need definitions. Even more so, because in the MS-Windows world things like this usually are arranged differently. Please see below. % cut % Item writing is my vocation and my main concern. :) Regardig the guidelines, you're right; they were drafted some time ago and I revised have them slightly. I would be *VERY* open to input from anyone on the list. (As an aside: A non-English-native Linux user has, to date, supplied the best commentary). The URL is still: http://www.soltec.net/~amead/generic.html I found that writing a few sample items helped elicit some of the unspecified issues. I do not recall you announced this; I suggest you issue a specific post on this in both the l-c-program and linux-cert lists. % cut % STATUS: Unless I hear otherwise, I am going to create a list with fields for: preferred term: definition/description: deprecated synonyms [preferred term: definition/description: deprecated synonyms (context 2)] [preferred term: definition/description: deprecated synonyms (...)] This seems workable, with the understanding (I didn't at first) that in some cases the acronym is preferred, and the written-out form deprecated; and in some cases the reverse. It should be understood that acronyms that are not in the list, should not be used but spelled out. This means we must include them in our list even if they are not in use yet, but if we anticipate someone will in the future. All this stuff may not nicely fit on a line, so I suggest to use a format where each field is on a line by its own, maybe beginning with a keyword; e.g.: Preferred: DNS Definition1:uhh ... "Internet Protocol (port 53?) to translate between Definition2:computer names (Fully Qualified Domain Names) and Definition3:numerical IP adresses (Dotted Quad numbers)." Deprecated: domain name server, ip address resolution, name resolution -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Call for dictionary
On Wed, 30 Jun 1999, A.R. (Tom) Peters wrote: On Wed, 30 Jun 1999, Alan Susan Mead wrote: Item writing is my vocation and my main concern. :) Regardig the guidelines, you're right; they were drafted some time ago and I revised have them slightly. I would be *VERY* open to input from anyone on the list. (As an aside: A non-English-native Linux user has, to date, supplied the best commentary). The URL is still: http://www.soltec.net/~amead/generic.html I found that writing a few sample items helped elicit some of the unspecified issues. I do not recall you announced this; I suggest you issue a specific post on this in both the l-c-program and linux-cert lists. I believe Alan has announced this previously on the examdev list, which IMO is the appropriate place to discuss item writing guidelines. But, Alan, Tom's advice is good: Why don't you post something to l-c, l-c-p, and l-c-ed about the guidelines and encourage comments/discussion to be posted only in l-c-ed. (Set the reply-to address to l-c-ed.) -Scott This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Call for dictionary
On Mon, 28 Jun 1999, Alan Susan Mead wrote: I think a dictionary would be nice for the test, it is really more a training tool. Of course, this assumes we all share enough of our peculiar dialect that we can communicate in written form about Linux. I'm not willing to bet against that. AISI, the items we need to include on this hypothetical list are: (1) acronyms which might reasonably be much better known by their full, expanded form (e.g., perhaps PnP but not FTP nor TCP/IP); (2) jargon terms which have equally valid synonyms (e.g., any one of NIC, network interface card, LAN adapter, ...). Would we also want (3) acronyms which are clearer in their full expanded form (e.g., FTP or SLIP but probably not PPP nor IP)? I think this does not solve the issue that was originally raised: what words and acronyms are so common that we may use them and expect them to be known. I still think we need to have a definitive list of them, with or without explanation. Do Linux- and computer-oriented acronyms ever get translated (like FRG and USSR become (?) FDR and CCSP in their native tongue)? If so, we would want to include those sorts of acronyms as well. That will be an issue for the test translators: we cannot anticipate all possible local conventions. And note that many things are known by their acronyms: we need not spell them out, and they are less likely to get translated. As I described in my previous message, I would just list two fields, the preferred term and alternate terms. Would a definition be helpful (helpful enough to justify the trouble)? Yes. Like Michael jang pointed out, the meaning of jargon tends to get confused, especially between MS and Unix. So in some cases we need to have a definition or at least a description of the concepts and words we will be using. Just offering synomyms (which may not exist for things with an acronym) will not be enough. Anyway, I've looked for lists of terms and all of them seemed unsuitable, most because they were waaay to inclusive. They tend to include arcane, basic, or specialized terms that we won't need. I propose an alternative to adapting one of these lists: (1) Someone (maybe me) strips out the jargon and acronyms in the objectives (and perhaps augmenting from the SAG and a couple O'Reiley books like Frisch's). (2) We post this list for comment. (3) We keep the revised list on-line during item-writing and (4) have the item reviewers both enforce the preferred terms and add to the list periodically. This seems like a good idea, so please go ahead. But mind that the stated goal was, to avoid jargon and abbreviations as much as reasonably possible. It is not clear to me if you think we should not bother to follow such a policy. This would provide consistency across exams because any terms that we include on Exam 1 get carried to Exam 2. New stuff for Exam 2 (if any) is added and carried to Exam 3. And so forth. It also seems more workable than writing an exhaustive list right away. Note that the first level has 2 exams, which will be developed shortly after one another. The second exam contains a distribution-specific part, which is still under development. -- #!$!%(@^%#%*((#@#*$^@^$##*#@(%)@**$!(!^(#((#%!)%*@)($($$%(@#)*!^$)^@*^@) Tom "thriving on chaos" Peters NL-1062 KD nr 149 tel.31-204080204 Amsterdam e-mail [EMAIL PROTECTED] This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
Re: Call for dictionary
-Original Message- From: A.R. (Tom) Peters [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Monday, June 28, 1999 8:19 AM Subject: Re: Call for dictionary On Mon, 28 Jun 1999, Alan Susan Mead wrote: I think this does not solve the issue that was originally raised: what words and acronyms are so common that we may use them and expect them to be known. I still think we need to have a definitive list of them, with or without explanation. I think this is not a good idea (at least not for controlling test quality) because a list too long and filed with too many no-brainer terms will not be read. But we can do it your way, more inclusive is easier. As I described in my previous message, I would just list two fields, the preferred term and alternate terms. Would a definition be helpful (helpful enough to justify the trouble)? Yes. Like Michael jang pointed out, the meaning of jargon tends to get confused, especially between MS and Unix. So in some cases we need to have a definition or at least a description of the concepts and words we will be using. Just offering synomyms (which may not exist for things with an acronym) will not be enough. So, here's my example again. What's wrong with, say, the DNS entry? Please be explicit otherwise the finished product won't be what you have in mind. Preferred : Alternatives account: a login, a screen name, a passwd entry CPU unit: [box that holds the] CPU, box, main unit, processing unit DNS: domain name server, ip address resolution, name resolution network interface card : NIC, LAN adapter, ethernet card, ne2000 clone This seems like a good idea, so please go ahead. But mind that the stated goal was, to avoid jargon and abbreviations as much as reasonably possible. It is not clear to me if you think we should not bother to follow such a policy. You mean do I agree with your concensus point? Sure! (Who has disagreed?) Or if you mean, Do I know what to write (besides the exact wording of the point) in the item writing guidelines? No. For example, do item writers have to spell out Transmision Control Protocol/Internet Protocol instead of TCP/IP (no, we already decided not, it would be dumb because TCP/IP is universally known while I had to look up its meaning just now). So do item writers have to spell out Domain Name Service? I'm guessing NO. So do they have to write out Network Interface Card (i.e., vs. NIC)? I'm guessing yes. The "I'm guessing" part is a little disquieting to me. If we leave it up to the item writers, then we have abandoned quality control. But I agree completely that this is a Linux test, not a acronym/jargon test. This would provide consistency across exams because any terms that we include on Exam 1 get carried to Exam 2. New stuff for Exam 2 (if any) is added and carried to Exam 3. And so forth. It also seems more workable than writing an exhaustive list right away. Note that the first level has 2 exams, which will be developed shortly after one another. The second exam contains a distribution-specific part, which is still under development. Yes But I'm not sure I take your point? -Alan This message was sent by the linux-cert-program mailing list. To unsubscribe: echo unsubscribe | mail -s '' [EMAIL PROTECTED]
