In contrast to SF, which had XSD schemas as the only cue for the underlying model, there is an eForms SDK which prescribes eForm XML element XPaths in terms of nodes and fields, which lends an easier framework for the management and comprehension of the UBL-based XML model behind elements used across the eForm notices. The notices themselves are categorized under document, form and notice types and subtypes, such as Competition Notice, subtype 16 (EF16).

A new idea introduced into the mapping methodology is the notion of a Mapping Group (MG), which is a representation of RDF connections (relationships) and subject groupings in a simple, hyphen-delimited textual notation, in the form:

where, for example, the full path of an organisation’s address might be:

This serves to provide an indication of how RDF statements are logically grouped together to form the right (connected) instances, given that data for a given subject may be spread across completely different XPaths in the source XML. That is why, in the technical mapping, MGs are used to form the subject URIs of the RML rules (TriplesMaps), suffixed with the node name (as per the SDK) where the information comes from, for example:

Different nodes usually require different subject templates or iterators, especially those which are located at entirely different or orthogonal XPaths, requiring as many RML TriplesMaps with the same MG but different node names.

Given the large number of mappings that are necessry for the conversion of a certain eForms Notice (the CM contains around 500 entries for various fields and nodes that belong to a type of notice), a mapping package ends up containing 200+ RML TriplesMaps with 500+ predicateObjectMap, resulting in more than 11,000 lines of RML code. To be able to efficiently and properly manage this amount of information, we split it up into multiple RML files that are organized following a certain logic.

The structure of the RML files (we call them modules because they are modular files with RML rules that work together when combined) is based on the primary/root class of a set of mapping rules, which are part of one or more Mapping Groups (MGs) that share such a root class (the final segment of an MG name). An MG represents a logical grouping of related instances/resources (like a foaf:Person with all of its properties and relationships together with the instances of those relationships).

Another advantage of creating modularized RML files, is that it allows us to easier handle the differences that appear in various SDK versions. Since fields and nodes can appear or disappear in any (major or minor) SDK version, we need to be able to write different RML mappings for different SDK versions. Some of these mapping are valid for all SDK version (that exist as of now), some are valid only for one particular SDK version, while others are valid up to or starting from a given SDK version. Our approach is to place these mappings in files whose name reflect the SDK versions for which they apply, and at the time when we create a mapping package for a given SDK version, we select oll the modeles that apply for that SDK version.

Important Note: The TriplesMaps in the various RML modules, especially those that represent version specific mappings, can spread accross multiple files. For example, a TriplesMap can have it logical source/iterator, its subject map, and its various predicat-object maps in several files, depending on what aspect is specified in a given SDK version and/or belongs to a given module. However, this information needs to be provided and organized in such a manner that when they are combined together in a package, the RML mappings should be valid, complete, correct and non-conflicting. E.g. every TriplesMap, after the modules are combined, should have one and only one logical source and subject map, and the subject map and all predicate-obect maps should work with the logical source that they are conbined with.