Military Communications and Information Technology: A Trusted ...
Military Communications and Information Technology: A Trusted ... Military Communications and Information Technology: A Trusted ...
216 Military Communications and Information Technology... In Language Representation 2 (Slovak) we require: • Commands finished with dots (.); • Concrete syntax of the move command is Presuň do ; • Concrete syntax of the destroy command is Znič zbraňou cieľ . Similarly, these concrete language requirements can be fulfilled using the following productions: 1. → . 5. → Presuň do #process_ move 6. → Znič zbraňou cieľ #process_destroy The aim of semantic processing is to properly interpret language constructs that are recognized by the parser. Of course, semantic meaning of the corresponding language constructs in both language representations should be the same and the aim is also to utilize language-independently as much of the semantic processing as possible. Lexical elements (in our example, key words, identifiers of military units and weapon systems and GPS coordinates) might be language-dependent and that is why a separate lexical analyzer has to be constructed for each language representation. Another aspect that must be taken into account during lexical as well as semantic processing comes from different naming conventions, measurement units, data formats and representations, etc. For example, in our grammars describing concrete syntaxes we can derive the following semantically equivalent language constructs: • move Platoon 1 to N49˚4'1,21'' E19˚35'53,62''; destroy N49˚5'3,2'' E19˚34'33,12'' by Tank 1; • Presuň Čata 1 do 49˚4‘1,21‘‘N 19˚35‘53,62‘‘E. Znič zbraňou Tank 1 cieľ 49˚5‘3,2‘‘N 19˚34‘33,12‘‘E. For the majority of the semantic routines it is necessary to pass some data (called semantic attributes) to other semantic routines. For example, the semantic routine #process_coordinates needs to pass the GPS coordinates recognized by the lexical analyzer to the semantic routines #process_move or #process_destroy. This task can be accomplished using a semantic stack [13]. A semantic stack is a second stack maintained by the parser which contains semantic records associated with the terminals and variables of productions being parsed. Each semantic record can contain arbitrary information (semantic attributes) that needs to be passed between individual semantic routines. The semantic records associated with the variables of individual productions are depicted in the pseudocode of semantic routines in the same way as the corresponding , but using the Courier font. Next follows the description of semantic routines:
Chapter 3: Information Technology for Interoperability and Decision... 217 #process_move { Call the Executive Control Subsystem to process the move command instructing the object to move to the coordinates ; } #process_destroy { Call the Executive Control Subsystem to process the destroy command instructing the weapon system to destroy the target at the coordinates ; } #process_unit { ← unit recognized by the lexical analyzer; } #process_weapon_system { ← weapon system recognized by the lexical analyzer; } #process_coordinates { ← coordinates recognized by the lexical analyzer; } The common abstract syntax tree of the above mentioned language constructs (i.e. independent of a concrete language representation) is depicted in Fig. 4, the parse tree for the Language Representation 1 is in Fig. 5. In both figures the flow of semantic attributes during semantic processing is depicted. We would like to point out that the semantic information contained in the semantic attributes (.object_type, .unit_type, .coordinates, etc.) is in a unified (canonical) form regardless of the concrete language representation used. To demonstrate the power of the presented language processing techniques we intentionally used different formats of GPS coordinates and different order of “weapon system” and “target” clauses in the individual language representations in the examples of language constructs.
- Page 166 and 167: 166 Military Communications and Inf
- Page 168 and 169: 168 Military Communications and Inf
- Page 170 and 171: 170 Military Communications and Inf
- Page 172 and 173: 172 Military Communications and Inf
- Page 174 and 175: 174 Military Communications and Inf
- Page 176 and 177: 176 Military Communications and Inf
- Page 178 and 179: 178 Military Communications and Inf
- Page 180 and 181: 180 Military Communications and Inf
- Page 182 and 183: 182 Military Communications and Inf
- Page 184 and 185: 184 Military Communications and Inf
- Page 186 and 187: 186 Military Communications and Inf
- Page 188 and 189: 188 Military Communications and Inf
- Page 190 and 191: 190 Military Communications and Inf
- Page 192 and 193: 192 Military Communications and Inf
- Page 194 and 195: 194 Military Communications and Inf
- Page 196 and 197: 196 Military Communications and Inf
- Page 199: Chapter 3 Information Technology fo
- Page 202 and 203: 202 Military Communications and Inf
- Page 204 and 205: 204 Military Communications and Inf
- Page 206 and 207: 206 Military Communications and Inf
- Page 208 and 209: 208 Military Communications and Inf
- Page 210 and 211: 210 Military Communications and Inf
- Page 212 and 213: 212 Military Communications and Inf
- Page 214 and 215: 214 Military Communications and Inf
- Page 218 and 219: 218 Military Communications and Inf
- Page 220 and 221: 220 Military Communications and Inf
- Page 222 and 223: 222 Military Communications and Inf
- Page 224 and 225: 224 Military Communications and Inf
- Page 226 and 227: 226 Military Communications and Inf
- Page 228 and 229: 228 Military Communications and Inf
- Page 230 and 231: 230 Military Communications and Inf
- Page 232 and 233: 232 Military Communications and Inf
- Page 234 and 235: 234 Military Communications and Inf
- Page 236 and 237: 236 Military Communications and Inf
- Page 239 and 240: Run-Time Ontology on the Basis of E
- Page 241 and 242: Chapter 3: Information Technology f
- Page 243 and 244: Chapter 3: Information Technology f
- Page 245 and 246: Chapter 3: Information Technology f
- Page 247 and 248: Chapter 3: Information Technology f
- Page 249 and 250: Chapter 3: Information Technology f
- Page 251 and 252: Chapter 3: Information Technology f
- Page 253 and 254: A Robust and Scalable Peer-to-Peer
- Page 255 and 256: Chapter 3: Information Technology f
- Page 257 and 258: Chapter 3: Information Technology f
- Page 259 and 260: Chapter 3: Information Technology f
- Page 261 and 262: Chapter 3: Information Technology f
- Page 263 and 264: Chapter 3: Information Technology f
- Page 265 and 266: Automatic Exploitation of Multiling
216 <strong>Military</strong> <strong>Communications</strong> <strong>and</strong> <strong>Information</strong> <strong>Technology</strong>...<br />
In Language Representation 2 (Slovak) we require:<br />
• Comm<strong>and</strong>s finished with dots (.);<br />
• Concrete syntax of the move comm<strong>and</strong> is Presuň do ;<br />
• Concrete syntax of the destroy comm<strong>and</strong> is Znič zbraňou <br />
cieľ .<br />
Similarly, these concrete language requirements can be fulfilled using the following<br />
productions:<br />
1. → . <br />
5. → Presuň do #process_<br />
move<br />
6. → Znič zbraňou cieľ <br />
#process_destroy<br />
The aim of semantic processing is to properly interpret language constructs<br />
that are recognized by the parser. Of course, semantic meaning of the corresponding<br />
language constructs in both language representations should be the same <strong>and</strong><br />
the aim is also to utilize language-independently as much of the semantic processing<br />
as possible. Lexical elements (in our example, key words, identifiers of military<br />
units <strong>and</strong> weapon systems <strong>and</strong> GPS coordinates) might be language-dependent<br />
<strong>and</strong> that is why a separate lexical analyzer has to be constructed for each language<br />
representation. Another aspect that must be taken into account during lexical as well<br />
as semantic processing comes from different naming conventions, measurement<br />
units, data formats <strong>and</strong> representations, etc.<br />
For example, in our grammars describing concrete syntaxes we can derive<br />
the following semantically equivalent language constructs:<br />
• move Platoon 1 to N49˚4'1,21'' E19˚35'53,62''; destroy N49˚5'3,2''<br />
E19˚34'33,12'' by Tank 1;<br />
• Presuň Čata 1 do 49˚4‘1,21‘‘N 19˚35‘53,62‘‘E. Znič zbraňou Tank 1 cieľ<br />
49˚5‘3,2‘‘N 19˚34‘33,12‘‘E.<br />
For the majority of the semantic routines it is necessary to pass some data<br />
(called semantic attributes) to other semantic routines. For example, the semantic<br />
routine #process_coordinates needs to pass the GPS coordinates recognized<br />
by the lexical analyzer to the semantic routines #process_move or<br />
#process_destroy. This task can be accomplished using a semantic stack [13].<br />
A semantic stack is a second stack maintained by the parser which contains semantic<br />
records associated with the terminals <strong>and</strong> variables of productions being<br />
parsed. Each semantic record can contain arbitrary information (semantic attributes)<br />
that needs to be passed between individual semantic routines. The semantic<br />
records associated with the variables of individual productions are depicted<br />
in the pseudocode of semantic routines in the same way as the corresponding<br />
, but using the Courier font. Next follows the description<br />
of semantic routines: