Definition of language- and data-type maps.

Given the following XML for example:

<tasks>
  <task>
    <task_id>1</task_id>
    <description lang="en">Design Mockups</description>
    <description lang="fr">Concevoir des maquettes</description>
  </task>
  <task>
    <task_id>2</task_id>
    <description lang="en">Develop Frontend</description>
    <description lang="fr">Développer le frontend</description>
  </task>
  <task>
    <task_id>3</task_id>
    <description lang="en">Develop Backend</description>
    <description lang="fr">Développer le backend</description>
  </task>
</tasks>

Iterating over /tasks/task, I want to generate English and French labels from tasks.

      rml:predicate ex:description ;
      rml:objectMap [ rml:reference "description[@lang='en']" ; rml:language "en" ; ] ; 
      rml:objectMap [ rml:reference "description[@lang='fr']" ; rml:language "fr" ; ] ; 
  ] ;

Allows me to do that, but why "hard-code" the languages. The problem is that

      rml:predicate ex:description ;
      rml:objectMap [ rml:reference "description" ; rml:languageMap [ rml:reference "description/@lang" ] ] ;
  ] ;

leads to a Cartesian product of labels and languages. This respects the definition of language-maps (and data-maps, by extension): "Given the list of values resulting from a language-taggable term map T, and the list of values resulting from its language map L, the resulting terms are generated by the n-ary Cartesian product combination of T × L, where the values in T are the lexical forms, and the values in L are the non-empty language tags."

Is this something we want (seems contradictory w.r.t. a seemingly conceivable use case). If not, there is (IMHO) something wrong with the specification, and we likely need some iteration manipulation (as @frmichel once suggested). If not, then the spec should give a concrete example with maybe a note or two.

kg-construct / rml-core

Definition of language- and data-type maps. #145