Mapping Methodology

To identify the XML elements that contain information to be mapped to RDF we look at:

Although this is not necessary for the conversion of the Standard Form XML to RDF data, from a future-oriented perspective it is still useful to identify the eForm Business Terms corresponding to each Standard Form element. This should be pretty straight forward by looking at the “Standard Forms to eForms” mapping table.

Basically, in this step, we need to identify the appropriate classes, class attributes, and relationships between the ePO classes that can be used to represent the information contained in the various XML elements. This requires a deep understanding of the ePO model.

Identifying the relevant ePO terms might not be very straightforward in some cases, as there is quite a significant difference between the conceptualisation and abstractisations made in the two models, and we can often encounter situations where even the names used for the same concept might differ significantly in the two models. Therefore, in this step it is highly recommended consulting with people who have a high level of knowledge of the structure and content of the ePO model.

Make sure to document any problems and discrepancies that we discover, which prevents the creation of a perfect (one-to-one) mapping. This documentation should happen both on the spreadsheet (e.g. by highlighting problematic cells in certain colours and/or adding comments to them), but also by describing issues in a separate, dedicated, document that can be reviewed and addressed by ePO experts. For more on the documentation process see section below.

To identify the value sets (i.e. the possible different values) that are used in the XML data, either as certain element names, or attribute values), we need to look at:

For this step we have to identify the different vocabularies that are referenced by ePO attributes and relationships that are involved in the mapping of a certain XML element, and we should gain some familiarity with that vocabulary. At minimum, we should know what namespace they are using and what are some values and how are they encoded (i.e. which properties they are using to encode labels, ids, etc).

To give an example of an input (XML notice’s fragment), and it’s transformation (RDF result), let’s see a fragment of an organisation definition.

When we take a look at the way how the RML rules are writen (see technical mapping chapter) we notice that it is a set of TripleMap. Each one contains:

The main problem that we had when we are using XPath as parser of XML notices, is the old version used by RML Mapper to parse the XML notices. The only version that were supported is XPath 1.0 that did not offer enough features, functions and expressions to parse an XML file.

For example, XPath 1.0 does not support the default namespaces that we find in the notices that we are transforming. The consequences of having these namespaces in the XML notices is that RML Mapper did generate empty RDF result because XPath does not find any element that we are referring for. To handle this problem we started to think to add a pre-processing step that remove these default namespaces from the XML notices. We were not convinced by that solution because modifying/deleting element from the input can impact the quality of the expected results.

So that’s why we contacted the founders of RML Mapper to find a way to handle default namespaces without processing the XML notices.

The founders ended up by generously offering us a new version of RML Mapper that supports XPath 2.0/3.0 into witch the default namespaces are supported.

This step is about making sure that all necessary sources are defined properly in the YARRRML/RML files, and that these sources refer to files that already exist, or will be available at the time of running the mapping, in the mapping package.

Important: The path to the source files should be specified relative to the RML file(s). So, if the RML mapping files are in the transformation/mappings folder (as described above), then the sources they define should point to the ../../data/data.xml file, respectively to the various .json, .csv and/or .xml files in the ./resources folder

Please refer to the representative sample data selection chapter.

During the initial phase of our mapping creation process we started out writing the mapping rules in YARRRML (a human-readable text-based representation for declarative generation rules), instead of RML, because it seemed simpler, and the end result was more human friendly. However, as we gained more experience and confidence in how the mappings should be defined, we realised that writing RML rules directly could be even more powerful, and we started to rewrite all our YARRRML mapping rules into RML. If this transition proves to be successful, and writing RML rules directly will be more convenient, our process will not require writing YARRRML rules in the future. This is the reason for why this step is optional. It could be useful for small test cases, quick demos, or showcases, and in cases when some people are more familiar with YARRRML than RML. If people decide to write YARRRML rules, the next step will become unnecessary, as the RML rules will be automatically generated from the YARRRML rules, using dedicated tools that were developed for this purpose.

Since this step is optional, we will not describe in detail the individual issues that need to be worked on, but they are in principle the same as the ones described in the next section.

If in the previous step we have defined the mapping rules in YARRRML, then this step consists of the simple action of executing the tool that generates RML out of YARRRML.

Regardless of which file we chose to define manually, the YARRRML or the RML, at the end of this step we will need to have an RML mapping file that should be able to convert an XML notice into a corresponding RDF graph.

In the rest of this section we assume that the RML rules are being written manually, as this is the solution that promises the biggest potential benefit and this is the approach that we would like to pursue in the future.

The technical mappings are written in the RML mapping language. The version of RML used is 5.0.0-r362, which was recommended to us by Julian Rojas, its principal developer, in which the XPath version 3.1 is supported.