Difference between revisions of "User:David Nemeskey/CG XML brainstorming"

From Apertium
Jump to navigation Jump to search
Line 52: Line 52:
 
== Alternative set handling ==
 
== 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:
 
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.
 
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.
+
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>
 
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.
 
# 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> ==
 
== <s>Sets (the original idea)</s> ==

Revision as of 11:58, 2 July 2013

This page lists my (and others') ideas of how the CG XML format could or should look like.

Sets and lists

The words set and list are used interchangeably in CG. This is in contrast to how these term are used in CS, and partly to the commonsensical meanings of the words as well. The current planning process might be just the right time to fix this issue. I propose to say good-bye to list.

The (XML) tags below will be used throughout the grammar for specifying tags and sets in e.g. constraint conditions.

Item CG syntax XML syntax Fran's suggestion
Regular tag nom <tag>nom</tag> <tag n="nom"/>
Sequence tag (n pl) <seq><tag>n</tag><tag>pl</tag></seq>
Reading base-form "dog" <lemma>dog</lemma>
Word-form "<dogs>" <word>dogs</word>
Set (...) see below
Special tags >>> and <<< <sbegin/> and <send/>

Observations:

  1. seq and set are very similar, which might be a problem when skimming through a CG
  2. I don't know if we even need set -- in the construction rules, you have to put sets to everywhere, and those will have separate XML tags anyway.
  3. seq could be combined(-tag)?

Delimiters

Probably the easiest of the bunch:

<delimiters>(word forms, sets, etc.)</delimiters>

Alternative set handling

Sets are defined (unhammer is right in that actual modification never happens) in the <sets>...</sets> 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:

Set type CG syntax XML syntax 1 XML syntax 2
Named Nominal <nset name="Nominal"/> <set name="Nominal"/>
Temporary (n) OR (adj) <set><or><tag n="n"/><tag n="adj"/></or></set> <set><or><tag n="n"/><tag n="adj"/></or></set>

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 sets from other sets. Again, we have two options here: we can either just have one tag (e.g. set), and it is up to the user to follow the conventions; or we can have separate tags for the two. I propose the latter:

Item CG syntax XML syntax
Basic set LIST set-name = ... ; <basic-set name="set-name">...</basic-set>
<bset name="set-name">...</bset>
"Meta" set* SET set-name = ... ; <meta-set name="set-name">...</meta-set>
<mset name="set-name">...</mset>

(*) Suggestions on how to call this tag are welcome.

The ... in a meta set definition, as well as in case of temporary sets, can include the following set operations:

Operation CG syntax XML syntax
Union A OR B <union><set name="A"><set name="B"></union>
<or><set name="A"><set name="B"></or>
Concatenation A + B <concat><set name="A"><set name="B"></concat>
Difference A - B <diff><set name="A"><set name="B"></diff>

Note: The operation tags above can be thought of as functions that return a new set, e.g. or(A, concat(B, C), diff (D, E)). This format has the benefit of explicitly encoding the precedence in the formula, so grammarians won't have to memorize it.

Constraints

Similar to its SETS counterpart, the CONSTRAINTS section is enclosed in a <constraints>...</constraints> 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, select, remove and iff, respectively (the other option, of course, would be <constraint type="select">). Each rule shall have a target and 0 or more cond(ition)s.

An example: "<fly>" REMOVE (V) IF (-1C (DET));

 <remove>
   <target><tag n="V"/></target>
   <cond><word n="fly"/></cond>
   <cond pos="-1" type="safe"><tag n="DET"/></cond>
 </remove>

Observations / questions:

  1. target is always a set, so in case of a simple tag, there is no need to convert it to a set manually (the parentheses in the original format)
  2. cond has two parameters: the position (pos) and the type, which is empty by default, but can be C (safe?), *, **, etc.
  3. 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 link tags is a tricky one. I don't think it makes sense to create <link><link><link><cond ... /></link></link></link>-type monstrosities. If we stick to SAX parsing, we could simply write them after the <cond> tag, i.e. <cond ... /><link ... /><link ... />. Since this wouldn't look very nice if there are more than one conditions, I would enclose each such block into a <constraint> tag, e.g.

 <remove>
   <target><tag n="V"/></target>
   <constraint>
     <cond><word n="fly"/></cond>
   </constraint>
   <constraint>
     <cond pos="-1" type="safe"><tag n="DET"/></cond>
     <link pos="-1" type="safe"><tag n="PREDET"/></link>
   </constraint>
 </remove>

Having a constraint also makes it easier to include negation: the cond and link tags can have an attribute not=true, while constraint can have a negate=true.

TODO: BARRIER

Sets (the original idea)

Set definitions and modifications. The section itself in enclosed in a <sets>...</sets> tag.

Item CG syntax XML syntax
Set definition LIST set-name = ... ; <define-set name="set-name">...</define-set>
<dset name="set-name">...</dset>
Set modification SET set-name = ... ; <modify-set name="set-name">...</modify-set>
<mset name="set-name">...</mset>

The define-set tag works exactly like set, 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:

Operation CG syntax XML syntax
Union A OR B <union>???A???B???</union>
<or>???A???B???<or>
Concatenation A + B <concat>???A???B???</concat>
Difference A - B <diff>???A???B???<diff>

Note: I imagine the above to be akin to lisp operators, e.g. (or A (concat B C) (diff D E)). 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. --unhammer 05:42, 28 June 2013 (UTC)
A nice way to annotate set operations could be something like this:

<or>
 <set n="A"/>
 <set n="B"/>
 <set>...</set>
</or>

It's not as nice as the s-expressions, but it is after all XML :) --Krvoje 19:23, 1 July 2013 (UTC)

Krvoje: if you look at the examples for temporary sets and or 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 nset or not. As for XML, I completely agree. :)