User:David Nemeskey/CG XML brainstorming - Revision history

David Nemeskey at 08:44, 4 July 2013

2013-07-04T08:44:19Z

David Nemeskey at 08:39, 4 July 2013

2013-07-04T08:39:11Z

David Nemeskey at 08:12, 4 July 2013

2013-07-04T08:12:06Z

David Nemeskey at 11:58, 2 July 2013

2013-07-02T11:58:59Z

David Nemeskey at 09:47, 2 July 2013

2013-07-02T09:47:32Z

Krvoje: /* Sets (the original idea) */

2013-07-01T19:23:06Z

Sets (the original idea)

David Nemeskey at 12:40, 1 July 2013

2013-07-01T12:40:30Z

David Nemeskey at 12:38, 1 July 2013

2013-07-01T12:38:49Z

David Nemeskey at 09:59, 1 July 2013

2013-07-01T09:59:29Z

David Nemeskey at 08:46, 1 July 2013

2013-07-01T08:46:28Z

@@ Line 37: / Line 37: @@
 |''>>>'' and ''<<<''
 |'''<code>&lt;sbegin/&gt;</code>''' and '''<code>&lt;send/&gt;</code>'''
+|-
+|colspan="2"|'''Votes:'''
+|
+|
 |}
@@ Line 71: / Line 75: @@
 |'''<code>&lt;set&gt;</code>'''&lt;or&gt;&lt;tag n="''n''"/&gt;&lt;tag n="''adj''"/&gt;&lt;/or&gt;'''<code>&lt;/set&gt;</code>'''
 |'''<code>&lt;set&gt;</code>'''&lt;or&gt;&lt;tag n="''n''"/&gt;&lt;tag n="''adj''"/&gt;&lt;/or&gt;'''<code>&lt;/set&gt;</code>'''
+|-
+|colspan="2"|'''Votes:'''
+|
+|
 |}
@@ Line 164: / Line 172: @@
 {| class="wikitable"
-! Interposed
+!colspan="2"| Interposed
 ! Separate tag
 |-
-|<code>
+|colspan="2"|<code>
   &lt;select&gt;
     &lt;target&gt;&lt;tag n="D"/&gt;&lt;/target&gt;
@@ Line 194: / Line 202: @@
 </code>
 |-
+|'''Votes:'''
+|
+|
 |}

@@ Line 195: / Line 195: @@
 |-
 |}
+== CG-3 features ==
+Since not all features of CG-3 are used by the grammars in Apertium (or so I've heard), first I'd like to cover those that are.
+=== [http://beta.visl.sdu.dk/cg3/chunked/subreadings.html#sub-grammar-subn Sub-readings] ===
+{| class="wikitable"
+! Sub-reading in
+! CG syntax
+! XML syntax
+|-
+|target
+|<code>SELECT SUB:1</code>
+|<code>
+ &lt;select '''sub="1"'''&gt;
+</code>
+|-
+|condition
+|<code>IF (0/1 ...)</code>
+|<code>
+ &lt;condition&gt;
+   &lt;cond '''sub="1"'''&gt;
+ &lt;/condition&gt;
+</code>
+|}
 == <s>Sets (the original idea)</s> ==

@@ Line 140: / Line 140: @@
 # Word-form conditions, which were traditionally written before the constraint name, are now on the same level as the other conditions. We could enforce that one rule can only have on word-form condition, or not.
-The question of '''<code>link</code>''' tags is a tricky one. I don't think it makes sense to create <code>&lt;link&gt;&lt;link&gt;&lt;link&gt;&lt;cond ... /&gt;&lt;/link&gt;&lt;/link&gt;&lt;/link&gt;</code>-type monstrosities. If we stick to SAX parsing, we could simply write them after the <code>&lt;cond&gt;</code> tag, i.e. <code>&lt;cond ... /&gt;&lt;link ... /&gt;&lt;link ... /&gt;</code>. Since this wouldn't look very nice if there are more than one conditions, I would enclose each such block into a '''<code>&lt;constraint&gt;</code>''' tag, e.g.
+The question of '''<code>link</code>''' tags is a tricky one. I don't think it makes sense to create <code>&lt;link&gt;&lt;link&gt;&lt;link&gt;&lt;cond ... /&gt;&lt;/link&gt;&lt;/link&gt;&lt;/link&gt;</code>-type monstrosities. If we stick to SAX parsing, we could simply write them after the <code>&lt;cond&gt;</code> tag, i.e. <code>&lt;cond ... /&gt;&lt;link ... /&gt;&lt;link ... /&gt;</code>. Since this wouldn't look very nice if there are more than one conditions, I would enclose each such block into a '''<code>&lt;condition&gt;</code>''' tag, e.g.
 <code>
   &lt;remove&gt;
     &lt;target&gt;&lt;tag n="V"/&gt;&lt;/target&gt;
-    &lt;constraint&gt;
+    &lt;condition&gt;
       &lt;cond&gt;&lt;word n="fly"/&gt;&lt;/cond&gt;
-    &lt;/constraint&gt;
+    &lt;/condition&gt;
-    &lt;constraint&gt;
+    &lt;condition&gt;
       &lt;cond pos="-1" type="safe"&gt;&lt;tag n="DET"/&gt;&lt;/cond&gt;
       &lt;link pos="-1" type="safe"&gt;&lt;tag n="PREDET"/&gt;&lt;/link&gt;
-    &lt;/constraint&gt;
+    &lt;/condition&gt;
   &lt;/remove&gt;
 </code>
-Having a '''<code>constraint</code>''' also makes it easier to include negation:  the '''<code>cond</code>''' and '''<code>link</code>''' tags can have an attribute '''<code>not=true</code>''', while '''<code>constraint</code>''' can have a '''<code>negate=true</code>'''.
+Having a '''<code>condition</code>''' also makes it easier to include negation:  the '''<code>cond</code>''' and '''<code>link</code>''' tags can have an attribute '''<code>not=true</code>''', while '''<code>condition</code>''' can have a '''<code>negate=true</code>'''.
+''BARRIER''s somehow belong to the '''<code>cond</code>''' and '''<code>link</code>''' tags. This relation could perhaps be best represented as an attribute, but that wouldn't allow the user to specify a temporary set as the barrier. So we need a '''<code>barrier</code>''' tag, which can be placed in two ways: under the '''<code>condition</code>''' tag, interposed between the '''<code>cond</code>''' and '''<code>link</code>''' tags, or under the latters. If we go with the first option, there's still the question of whether to place the '''<code>barrier</code>''' tag before ("semantic" ordering) or after (same as in the original format) the conditions/links. If we opt for the second, we have to introduce new tags for the condition part in '''<code>cond</code>''' and '''<code>link</code>'''.
-'''TODO:''' BARRIER
+An example from Pasi Tapanainen<ref>Tapanainen, P. 1996. The Constraint Grammar Parser CG-2. Publications 27, Department of General Linguistics. University of Helsinki.</ref>, with the two alternative formats described above, semantic ordering in the first case:
+<code>(*1 A BARRIER C LINK *1 B BARRIER C)</code>
+{| class="wikitable"
+! Interposed
+! Separate tag
+|-
+|<code>
+  &lt;select&gt;
+    &lt;target&gt;&lt;tag n="D"/&gt;&lt;/target&gt;
+    &lt;condition&gt;
+      '''&lt;barrier&gt;&lt;set n="C"/&gt;&lt;/barrier&gt;'''
+      '''&lt;cond pos="1*"&gt;&lt;set n="A"/&gt;&lt;/cond&gt;'''
+      '''&lt;barrier&gt;&lt;set n="C"/&gt;&lt;/barrier&gt;'''
+      '''&lt;link pos="1*"&gt;&lt;set n="B"/&gt;&lt;/link&gt;'''
+    &lt;/condition&gt;
+  &lt;/remove&gt;
+</code>
+|<code>
+  &lt;select&gt;
+    &lt;target&gt;&lt;tag n="D"/&gt;&lt;/target&gt;
+    &lt;condition&gt;
+      '''&lt;cond pos="1*"&gt;'''
+        '''&lt;tgt&gt;&lt;set n="A"/&gt;&lt;/tgt&gt;'''
+        '''&lt;barrier&gt;&lt;set n="C"/&gt;&lt;/barrier&gt;'''
+      '''&lt;/cond&gt;'''
+      '''&lt;link pos="1*"&gt;'''
+        '''&lt;tgt&gt;&lt;set n="B"/&gt;&lt;/tgt&gt;'''
+        '''&lt;barrier&gt;&lt;set n="C"/&gt;&lt;/barrier&gt;'''
+      '''&lt;/link&gt;'''
+    &lt;/condition&gt;
+  &lt;/remove&gt;
+</code>
+|-
+|}
 == <s>Sets (the original idea)</s> ==
@@ Line 215: / Line 252: @@
 : [[User:Krvoje|Krvoje]]: if you look at the examples for temporary sets and <code>or</code> above, you see it is exactly
 how I imagined it would look like -- of course there's still the question whether the first two should be <code>nset</code> or not. As for XML, I completely agree. :)
+<references/>

@@ Line 52: / Line 52: @@
 == Alternative set handling ==
-Set are defined ([[User:Unhammer|unhammer]] is right in that actual modification never happens) in the <code>'''&lt;sets&gt;'''...'''&lt;/sets&gt;'''</code> section.
+Sets are defined ([[User:Unhammer|unhammer]] is right in that actual modification never happens) in the <code>'''&lt;sets&gt;'''...'''&lt;/sets&gt;'''</code> section.
 There are two kinds of sets in CG: named and temporary. The obvious first question is: do we represent them as two different tags, or not? The two options are listed below:
@@ Line 123: / Line 123: @@
 Similar to its ''SETS'' counterpart, the ''CONSTRAINTS'' section is enclosed in a <code>'''&lt;constraints&gt;'''...'''&lt;/constraints&gt;'''</code> tag.
 At first I am going to cover only the three CG-2 constraint types: ''SELECT'', ''REMOVE'' and ''IFF''. Each type has its own tag; in this case, '''<code>select</code>''', '''<code>remove</code>''' and '''<code>iff</code>''', respectively (the other option, of course, would be '''<code>&lt;constraint type="</code>'''''select'''''<code>"</code>&gt;'''). Each rule shall have a '''<code>target</code>''' and 0 or more '''<code>cond</code>'''(ition)s.
 An example: <code>"&lt;fly&gt;" REMOVE (V) IF (-1C (DET));</code>
@@ Line 140: / Line 140: @@
 # Word-form conditions, which were traditionally written before the constraint name, are now on the same level as the other conditions. We could enforce that one rule can only have on word-form condition, or not.
+The question of '''<code>link</code>''' tags is a tricky one. I don't think it makes sense to create <code>&lt;link&gt;&lt;link&gt;&lt;link&gt;&lt;cond ... /&gt;&lt;/link&gt;&lt;/link&gt;&lt;/link&gt;</code>-type monstrosities. If we stick to SAX parsing, we could simply write them after the <code>&lt;cond&gt;</code> tag, i.e. <code>&lt;cond ... /&gt;&lt;link ... /&gt;&lt;link ... /&gt;</code>. Since this wouldn't look very nice if there are more than one conditions, I would enclose each such block into a '''<code>&lt;constraint&gt;</code>''' tag, e.g.
-'''TODO:''' LINK, BARRIER
+<code>
+  &lt;remove&gt;
+    &lt;target&gt;&lt;tag n="V"/&gt;&lt;/target&gt;
+    &lt;constraint&gt;
+      &lt;cond&gt;&lt;word n="fly"/&gt;&lt;/cond&gt;
+    &lt;/constraint&gt;
+    &lt;constraint&gt;
+      &lt;cond pos="-1" type="safe"&gt;&lt;tag n="DET"/&gt;&lt;/cond&gt;
+      &lt;link pos="-1" type="safe"&gt;&lt;tag n="PREDET"/&gt;&lt;/link&gt;
+    &lt;/constraint&gt;
+  &lt;/remove&gt;
+</code>
+Having a '''<code>constraint</code>''' also makes it easier to include negation:  the '''<code>cond</code>''' and '''<code>link</code>''' tags can have an attribute '''<code>not=true</code>''', while '''<code>constraint</code>''' can have a '''<code>negate=true</code>'''.
+'''TODO:''' BARRIER
 == <s>Sets (the original idea)</s> ==

@@ Line 196: / Line 196: @@
 </code>
 It's not as nice as the s-expressions, but it is after all XML :) --[[User:Krvoje|Krvoje]] 19:23, 1 July 2013 (UTC)
+: [[User:Krvoje|Krvoje]]: if you look at the examples for temporary sets and <code>or</code> above, you see it is exactly
+how I imagined it would look like -- of course there's still the question whether the first two should be <code>nset</code> or not. As for XML, I completely agree. :)

@@ Line 142: / Line 142: @@
 '''TODO:''' LINK, BARRIER
-== Sets (the original idea) ==
+== <s>Sets (the original idea)</s> ==
-Set definitions and modifications. The section itself in enclosed in a <code>'''&lt;sets&gt;'''...'''&lt;/sets&gt;'''</code> tag.
+<s>Set definitions and modifications. The section itself in enclosed in a <code>'''&lt;sets&gt;'''...'''&lt;/sets&gt;'''</code> tag.
 {| class="wikitable"
@@ Line 186: / Line 186: @@
 Note: I imagine the above to be akin to lisp operators, e.g. <code>(or A (concat B C) (diff D E))</code>. This format has the benefit of explicitly encoding the precedence in the formula, so grammarians won't have to memorize it.
-: CG never modifies sets. You can define one set based on other sets, but that's a new set definition, not an old set being changed. --[[User:Unhammer|unhammer]] 05:42, 28 June 2013 (UTC)
+: CG never modifies sets. You can define one set based on other sets, but that's a new set definition, not an old set being changed. --[[User:Unhammer|unhammer]] 05:42, 28 June 2013 (UTC)</s>

@@ Line 75: / Line 75: @@
 Well, the two options are almost the same, and both are very easy to write a parser for. However, I am a bit concerned about the (human) readability of the latter.
-As for set definition, there are currently two ways to do that: with the ''LIST'' and the ''SET'' keywords. The former is a big OR of tags (inc. lemmas and sequences), while the latter builds **TO BE CONTINUED**
+As for set definition, there are currently two ways to do that: with the ''LIST'' and the ''SET'' keywords. The former is a big OR of tags (inc. lemmas and sequences), while the latter builds sets from other sets. Again, we have two options here: we can either just have one tag (e.g. '''<code>set</code>'''), and it is up to the user to follow the conventions; or we can have separate tags for the two. I propose the latter:
 {| class="wikitable"
@@ Line 82: / Line 82: @@
 ! XML syntax
 |-
+|Basic set
-|Set definition
 |<code>LIST ''set-name'' = ''...'' ;</code>
-|'''<code>&lt;define-set name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/define-set&gt;</code>'''<br>
+|'''<code>&lt;basic-set name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/basic-set&gt;</code>'''<br>
- '''<code>&lt;dset name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/dset&gt;</code>'''
+ '''<code>&lt;bset name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/bset&gt;</code>'''
 |-
+|"Meta" set<sup>*</sup>
-|Set modification
 |<code>SET ''set-name'' = ''...'' ;</code>
-|'''<code>&lt;modify-set name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/modify-set&gt;</code>'''<br>
+|'''<code>&lt;meta-set name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/meta-set&gt;</code>'''<br>
  '''<code>&lt;mset name="</code>'''''set-name'''''<code>"&gt;</code>'''''...'''''<code>&lt;/mset&gt;</code>'''
 |}
+''(*) Suggestions on how to call this tag are welcome.''
-The '''<code>define-set</code>''' tag works exactly like '''<code>set</code>''', the only exception is that the former is named and can only be used in the SETS sections. The ''...'' in set modification can include the following set operations:
+The ''...'' in a meta set definition, as well as in case of temporary sets, can include the following set operations:
 {| class="wikitable"
@@ Line 102: / Line 104: @@
 |Union
 |''A OR B''
-|'''<code>&lt;union&gt;</code>???A???B???<code>&lt;/union&gt;</code>'''<br>
+|'''<code>&lt;union&gt;'''&lt;set name="</code>''A''<code>"&gt;&lt;set name="</code>''B''<code>"&gt;'''&lt;/union&gt;</code>'''<br>
- '''<code>&lt;or&gt;</code>???A???B???<code>&lt;or&gt;</code>'''
+ '''<code>&lt;or&gt;'''&lt;set name="</code>''A''<code>"&gt;&lt;set name="</code>''B''<code>"&gt;'''&lt;/or&gt;</code>'''
 |-
 |Concatenation
 |''A + B''
-|'''<code>&lt;concat&gt;</code>???A???B???<code>&lt;/concat&gt;</code>'''
+|'''<code>&lt;concat&gt;'''&lt;set name="</code>''A''<code>"&gt;&lt;set name="</code>''B''<code>"&gt;'''&lt;/concat&gt;</code>'''
 |-
 |Difference
 |''A - B''
-|'''<code>&lt;diff&gt;</code>???A???B???<code>&lt;diff&gt;</code>'''
+|'''<code>&lt;diff&gt;'''&lt;set name="</code>''A''<code>"&gt;&lt;set name="</code>''B''<code>"&gt;'''&lt;/diff&gt;</code>'''
 |-
 |}
-Note: I imagine the above to be akin to lisp operators, e.g. <code>(or A (concat B C) (diff D E))</code>. This format has the benefit of explicitly encoding the precedence in the formula, so grammarians won't have to memorize it.
+Note: The operation tags above can be thought of as functions that return a new set, e.g. <code>or(A, concat(B, C), diff (D, E))</code>. This format has the benefit of explicitly encoding the precedence in the formula, so grammarians won't have to memorize it.
-== Sets ==
+== Constraints ==
+== Sets (the original idea) ==
 Set definitions and modifications. The section itself in enclosed in a <code>'''&lt;sets&gt;'''...'''&lt;/sets&gt;'''</code> tag.
@@ Line 162: / Line 166: @@
 : CG never modifies sets. You can define one set based on other sets, but that's a new set definition, not an old set being changed. --[[User:Unhammer|unhammer]] 05:42, 28 June 2013 (UTC)
-== Constraints ==