etc/grammar-mail

   1 From mike@seatbooker.net  Tue Oct 29 15:12:09 2002
   2 Envelope-to: mike@miketaylor.org.uk
   3 Date: Tue, 29 Oct 2002 14:11:48 GMT
   4 From: Mike Taylor <mike@seatbooker.net>
   5 To: ZNG@loc.gov
   6 Cc: mike@miketaylor.org.uk
   7 Subject: Again: Grammar Tweaks
   8
   9 Dear Everyone,
  10
  11 I sent this message last Friday, and didn't get a delivery failure
  12 message or anything similar; but there has been absolutely zero
  13 response on-list, which makes me wonder whether it mysteriously didn't
  14 get through.
  15
  16 ... or surely it didn't get caught by people's "this message is too
  17 complicated to pay attention to" filters?  :-~
  18
  19  _/|_    _______________________________________________________________
  20 /o ) \/  Mike Taylor   <mike@miketaylor.org.uk>   www.miketaylor.org.uk
  21 )_v__/\  "Conclusion: is left to the reader (see Table 2).
  22          Acknowledgements: I wrote this paper for money" --
  23          A. A. Chastel, _A critical analysis of the explanation of
  24          red-shifts by a new field_, A&A 53, 67 (1976)
  25
  26
  27 ------------------------------- cut here -------------------------------
  28 Well, it looks like the CQL grammar has settled down more or less to
  29 everyone's satisfaction.  So it must be time to throw it all up the
  30 air again!  :-)
  31
  32 No, I'm joking -- mostly.  I'd like to point one actual mistake (I
  33 think), suggest one substantive change, and request a few cosmetic
  34 changes.
  35
  36 For anyone who's not got it to hand, the URL for the grammar is
  37 http://lcweb.loc.gov/z3950/agency/zing/srwu/cql.html
  38
  39 1.  I think it's a mistake that the grammar says:
  40         prox-qualifiers ::= "/" [ unit ] "/" [ relation ] "/" [ distance ] "/" ordering
  41     (and the similar productions that follow) because that allows
  42         prox/word/exact/3       <--- "exact" is meaningless here
  43     and -- even worse --
  44         prox/word/=/stem        <--- a relation-modifier!
  45     (This is not only silly, but ambiguous too)
  46
  47     So I think all the occurrences of "relation" in the productions
  48     for prox need to be changed to "order-or-equal-relation".
  49
  50 2.  The only thing that I'm suggesting we actually _change_ is the
  51     order of the proximity parameters.  Quick!  Close your eyes and
  52     tell me the correct order of relation, ordering, distance and
  53     unit?  See -- you can't do it: no-one can :-)
  54
  55     So, based somewhat on Adam's rather more difficult suggestion of
  56     a couple of days ago, I propose that we change the order to:
  57         relation/distance/unit/ordering
  58     Rationale: you can read it out loud.  If you want to find two
  59     clauses with the conditions "*more* than *5* *sentences* apart",
  60     you would write ``foo prox/>/5/sentence bar''.
  61
  62 3.  Cosmetic changes.
  63
  64     3a.  The "/" at the beginning of each of the prox-qualfiers
  65          productions can be moved up into the definition of prox, like
  66          this:
  67                 prox::= "prox" [ "/" prox-qualifiers ]
  68          which yields a slightly simpler, neater (but equivalent)
  69          grammar.
  70
  71     3b.  The things that the grammar called "index-name", we have been
  72          calling "qualifiers" (and talking about the "qualifier-sets"
  73          that contain them.)  I think that's a much nicer name than
  74          "index-name", in part because it doesn't carry such a loading
  75          of implementation detail.  Also, remember that we way we've
  76          designed things, a qualifier will typically implemented by
  77          multiple indexes (a word index and a string index) so I don't
  78          want to give misleading impressions.
  79
  80          3b1.  :-)
  81                That would mean that, in the name of simplicity, we'd
  82                need to rename "prox-qualifiers" to something like
  83                "prox-modifiers" or "prox-parameters" (which is what
  84                we've actually been calling them, 4WIW) and rename
  85                "qualifier" to something more suggestive such as
  86                "relation-modifier" (which, again, is what we've been
  87                using in prose.)
  88
  89     3c.  (Nearly done, honest.)  I think that
  90          "order-or-equal-relation" is a horrible name and would much
  91          prefer to call it something like "numeric-relation", which
  92          better explains its role in, for example, proximity
  93          parameters.
  94
  95 So, putting it all together, here's how I think the grammar should
  96 look:
  97
  98 ------------------------------- cut here -------------------------------
  99 cql-query         ::= cql-query boolean search-clause
 100                    |  search-clause
 101 boolean           ::= "and" | "or" | "not" | prox
 102 search-clause     ::= "(" cql-query ")"
 103                    |  [ qualifier relation ] term
 104
 105 relation          ::= base-relation { "/" relation-modifier }
 106 base-relation     ::= numeric-relation | "exact" | "all" | "any"
 107 relation-modifier ::= "relevant" | "fuzzy" | "stem"
 108 numeric-relation  ::= "<" | ">" | "<=" | ">=" | "<>" | "="
 109
 110 prox              ::= "prox" [ "/" prox-parameters ]
 111 prox-parameters   ::= [ numeric-relation ] "/" [ distance ] "/" [ unit ] "/" ordering
 112                    |  [ numeric-relation ] "/" [ distance ] "/" unit
 113                    |  [ numeric-relation ] "/" distance
 114                    |  numeric-relation
 115 unit              ::= "word" | "sentence" | "paragraph" | "element"
 116 ordering          ::= "ordered" | "unordered"
 117 distance          ::= non-negative-integer
 118
 119 qualifier         ::= [ qualifier-prefix "." ] qualifier-name
 120 qualifier-prefix  ::= identifier
 121 qualifier-name    ::= identifier
 122 identifer         ::= string
 123 term              ::= string | ""string""
 124 string            ::= a character string
 125 ------------------------------- cut here -------------------------------
 126
 127 Hope this helps, and that it's none of it's controversial.  I guess it
 128 ought not to be, except maybe the change in the order of proximity
 129 parameters.
 130
 131  _/|_    _______________________________________________________________
 132 /o ) \/  Mike Taylor   <mike@miketaylor.org.uk>   www.miketaylor.org.uk
 133 )_v__/\  The IBM 360 had no stack, and that was stupid, short-sighted
 134          design.  The Cray 2 has no stack either, but that's elegant
 135          minimalism.
 136
 137
 138