<commit_before>\documentclass{llncs}

\usepackage{url}

\begin{document}

\title{LIXR: Quick, succinct conversion of XML to RDF}

\author{
<NAME>\textsuperscript{1} \and
<NAME>\textsuperscript{2}}

\institute{
    \textsuperscript{1}Insight Centre for Data Analytics, National University of Ireland, Galway\\
    \email{<EMAIL>}\\
    \textsuperscript{2}Cognitive Interaction Technology, Cluster of Excellence,
    Bielefeld University\\
    \email{<EMAIL>}
}

\maketitle
\begin{abstract}
This paper presents LIXR, a system for converting between RDF and XML. LIXR is based on   domain-specific language embedded into the Scala programming language.
It supports the definition of transformations of 
datasets from RDF to XML in a declarative fashion, while still maintaining the flexibility of a full
programming language environment. We directly compare this system to other systems
programmed in Java and XSLT and show that the LIXR implementations are significantly
shorter in terms of lines of code, in addition to being bidirectional and conceptually simple to understand.

\end{abstract}

%\category{H.4}{Information Systems Applications}{Miscellaneous}
%\category{D.2.8}{Software Engineering}{Metrics}[complexity measures, performance measures]

%\terms{Theory}

\keywords{RDF, XML, Scala, format conversion}

\section{Introduction}

An important aspect towards realizing a web of data is the conversion of legacy resources into the 
Resource Description Framework~\cite[RDF]{cyganiak2014rdf}. There are tools and
W3C recommendations\footnote{\url{http://www.w3.org/TR/rdb-direct-mapping/}}
supporting the transformation of relational databases into RDF (e.g. D2RQ
\cite{bizer2004d2rq}), and even declaratively languages such as
R2RML\footnote{\url{http://www.w3.org/TR/r2rml/}}. Besides the relational model,
legacy data represented in XML is quite frequent. While there exist generic
mechanisms for transforming XML data into some other form, such as Extensible
Stylesheet Language Transformations (XSLT), these mechanisms are not ideal for
the conversion into RDF for the following reasons: 


\begin{enumerate}
\item The generated RDF typically contains more triples than necessary due to the fact that generic
converters create both a property and a node for each individual element in the XML.
\item It is uncommon for XML documents to reuse URLs from other resources. For
example it is typical for a resource to reuse the data categories of Dublin Core~\cite{weibel1998dublin}, 
but to recast them under a new namespace, that is not compatible with RDF.
\item XML provides no generic mechanisms for the representation of external
    links by URIs, using a proprietary linking schema instead such as
    XLink~\cite{derose2001xml}. 
\end{enumerate}

%These points can be further examined by considering a mini-example from
%the META-SHARE data described further below.
%
%\begin{verbatim}
%<languageInfo>
%  <languageId>bg</languageId>
%</languageInfo>
%\end{verbatim}
%
%In this case, it is unlikely that we would wish to create two properties for the 
%elements ({\tt 
%languageInfo}, {\tt languageId}) and an intermediate node, but instead
%would rather re-use a single existing property from Dublin Core ({\tt
%dc:language}) and even map the language identifier to a common repository such
%as LexVo~\cite{de2008language}. Such choices cannot be made with a 
%generic converter.

Further, transformation from XML to some other format are typically specified by means of  the  Extensible Stylesheet Language
Transformations (XSLT), an extension of XSLT such as
Krextor~\cite{lange2009krextor}, a specific mapping language such as
RML~\cite{dimou2014rml} or 
by writing a short script in some programming language. Thus, these transformations
are generally very verbose, as they must repeat many standard RDF modelling
structures, and unidirectional, as they are not well-formulated to cope with the 
polymorphic nature of RDF.

In order to meet these shortcomings, we developed a new system for specifying the
translation of XML documents into RDF and \emph{vica versa}, which we call the Lightweight Invertible
XML and RDF language (LIXR, pronounced `elixir').
%This system builds on a 
%Scala domain-specific language~\cite[DSL]{fowler2010domain,wampler2008programming}, which allows the conversion to be
LIXR is significantly more compact than existing systems and 
allows for transformation in both the direction of RDF to XML and from XML
to RDF.

%We describe the system and the features of the domain-specific language domain in Section
%\ref{sec:dsl}. Then we will consider a detailed use case, where we used the LIXR
%system to convert a very complicated XML schema into RDF, namely for the META-SHARE
%resources~\cite{mccrae2015ontology,piperidis2012meta}, in Section \ref{sec:metashare}. Next, we will present some qualitative evaluation
%of the methodology to demonstrate its brevity and discuss these results in Section
%\ref{sec:results} and conclude in Section \ref{sec:conclusion}.

\section{The LIXR Language}
\label{sec:dsl}

The LIXR language was created as a domain-specific language based on the Scala
Language. This choice was made as Scala has an exceptional amount of freedom in
expression, allowing us to compactly and clearly state transformations in a manner
that would be more cumbersome in other languages such as a fully RDF
approach~\cite{dimou2014rml}. 
%Moreover, the fact that Scala
%compiles to Java bytecode allows us to reuse existing libraries for handling
%RDF, including the Jena library\footnote{\url{http://jena.apache.org/}}.

The basic structure of LIXR is inspired by XSLT and is based around \emph{handlers},
which describe the action that should be taken when a specific XML element is 
encountered. These handlers are stated by linking an XML element name to a list
of \emph{generators} with the {\tt -->} operator. For example the following LIXR
expression can be used:

\begin{verbatim}
xml.language --> (
  dc.language > content
)
\end{verbatim}

This associates the XML element {\tt <xml:language>} to
generating the triple \emph{s} {\tt dc:language} {\tt "}\emph{c}{\tt "}, 
where \emph{s} is the current subject node, and \emph{c} is the text content of
the node\footnote{Note that for technical reasons the {\tt .} is used to conjoin the namespace
to the local name instead of the customary {\tt :}. This, in fact, is 
a dynamic call a relatively recent feature of the Scala language.} More typically
the converter works by means of two features: firstly, {\tt node}s instruct the RDF generation
to create a new node in the RDF graph and use it as subject for all triples
from this point in the generation. Secondly, the {\tt handle} tells the XML parser to look for all 
children matching a given element and call the appropriate handler for each matching
case. For example:

\begin{verbatim}
xml.metadata --> (
  node("http://.../metadata")(
    handle(xml.language),
    handle(xml.source)
  )
)
\end{verbatim}

This code asks the RDF generator to create a new root node with the given URI. The parser
then looks for matching children and calls the appropriate handlers
(such as in the first example). 
%In the opposite direction (RDF to XML), it is
%possible to generate the XML by walking the RDF diagram as a tree. 
More detail
of the language can be found on Github\footnote{\url{anonymous}}.
%\footnote{
%The LIXR language allows for cycles in RDF graphs only by double naming of
%{\tt node}s} generating a
%element for any handler where all of its mandatory generators and at least one 
%generator is active. For example, if a triple is generated this is considered
%mandatory, however {\tt handle}s are not mandatory. In some cases, this means that
%`round-tripping', that is the conversion of RDF to XML and back to RDF, may not
%be possible. For example, the {\tt substring} function can not be used in the
%inverse direction and is defined by means of two lambda functions, based on
%the generic {\tt transform} generator:
%
%\begin{verbatim}
%def substring(tg : TextGenerator, s : Int, e : Int) =
%  transform(tg)
%           (string => string.substring(s, e))
%           (throw new UnsupportedOperationException())
%\end{verbatim}
%
%This defines a substring as a {\tt transform} of a text element, {\tt tg}, which
%is realized in the XML-to-RDF direction by the lambda function that calls the <commit_msg>Fix a few more things<commit_after>\documentclass{llncs}

\usepackage{url}

\begin{document}

\title{LIXR: Quick, succinct conversion of XML to RDF}

\author{
<NAME>\textsuperscript{1} \and
<NAME>\textsuperscript{2}}

\institute{
    \textsuperscript{1}Insight Centre for Data Analytics, National University of Ireland, Galway\\
    \email{<EMAIL>}\\
    \textsuperscript{2}Cognitive Interaction Technology, Cluster of Excellence,
    Bielefeld University\\
    \email{<EMAIL>}
}

\maketitle
\begin{abstract}
This paper presents LIXR, a system for converting between RDF and XML. LIXR is based on   domain-specific language embedded into the Scala programming language.
It supports the definition of transformations of 
datasets from RDF to XML in a declarative fashion, while still maintaining the flexibility of a full
programming language environment. We directly compare this system to other systems
programmed in Java and XSLT and show that the LIXR implementations are significantly
shorter in terms of lines of code, in addition to being bidirectional and conceptually simple to understand.

\end{abstract}

%\category{H.4}{Information Systems Applications}{Miscellaneous}
%\category{D.2.8}{Software Engineering}{Metrics}[complexity measures, performance measures]

%\terms{Theory}

\keywords{RDF, XML, Scala, format conversion}

\section{Introduction}

An important aspect towards realizing a web of data is the conversion of legacy resources into the 
Resource Description Framework~\cite[RDF]{cyganiak2014rdf}. There are tools and
W3C recommendations\footnote{\url{http://www.w3.org/TR/rdb-direct-mapping/}}
supporting the transformation of relational databases into RDF (e.g. D2RQ
\cite{bizer2004d2rq}), and even declaratively languages such as
R2RML\footnote{\url{http://www.w3.org/TR/r2rml/}}. Besides the relational model,
legacy data represented in XML is quite frequent. While there exist generic
mechanisms for transforming XML data into some other form, such as Extensible
Stylesheet Language Transformations (XSLT), these mechanisms are not ideal for
the conversion into RDF for the following reasons: 


\begin{enumerate}
\item The generated RDF typically contains more triples than necessary due to the fact that generic
converters create both a property and a node for each individual element in the XML.
\item It is uncommon for XML documents to reuse URLs from other resources. For
example it is typical for a resource to reuse the data categories of Dublin Core~\cite{weibel1998dublin}, 
but to recast them under a new namespace, that is not compatible with RDF.
\item XML provides no generic mechanisms for the representation of external
    links by URIs, using a proprietary linking schema instead such as
    XLink~\cite{derose2001xml}. 
\end{enumerate}

%These points can be further examined by considering a mini-example from
%the META-SHARE data described further below.
%
%\begin{verbatim}
%<languageInfo>
%  <languageId>bg</languageId>
%</languageInfo>
%\end{verbatim}
%
%In this case, it is unlikely that we would wish to create two properties for the 
%elements ({\tt 
%languageInfo}, {\tt languageId}) and an intermediate node, but instead
%would rather re-use a single existing property from Dublin Core ({\tt
%dc:language}) and even map the language identifier to a common repository such
%as LexVo~\cite{de2008language}. Such choices cannot be made with a 
%generic converter.

Further, transformation from XML to some other format are typically specified by means of  the  Extensible Stylesheet Language
Transformations (XSLT), an extension of XSLT such as
Krextor~\cite{lange2009krextor}, a specific mapping language such as
RML~\cite{dimou2014rml} or 
by writing a short script in some programming language. Thus, these transformations
are generally very verbose, as they must repeat many standard RDF modelling
structures, and unidirectional, as they are not well-formulated to cope with the 
polymorphic nature of RDF.

In order to meet these shortcomings, we developed a new system for specifying the
translation of XML documents into RDF and \emph{vica versa}, which we call the Lightweight Invertible
XML and RDF language (LIXR, pronounced `elixir').
%This system builds on a 
%Scala domain-specific language~\cite[DSL]{fowler2010domain,wampler2008programming}, which allows the conversion to be
LIXR is significantly more compact than existing systems and 
allows for transformation in both the direction of RDF to XML and from XML
to RDF.

%We describe the system and the features of the domain-specific language domain in Section
%\ref{sec:dsl}. Then we will consider a detailed use case, where we used the LIXR
%system to convert a very complicated XML schema into RDF, namely for the META-SHARE
%resources~\cite{mccrae2015ontology,piperidis2012meta}, in Section \ref{sec:metashare}. Next, we will present some qualitative evaluation
%of the methodology to demonstrate its brevity and discuss these results in Section
%\ref{sec:results} and conclude in Section \ref{sec:conclusion}.

\section{The LIXR Language}
\label{sec:dsl}

The LIXR language was created as a domain-specific language based on the Scala
Language. This choice was made as Scala has an exceptional amount of freedom in
expression, allowing us to compactly and clearly state transformations.
%in a manner
%that would be more cumbersome in other languages such as a fully RDF
%approach~\cite{dimou2014rml}. 
%Moreover, the fact that Scala
%compiles to Java bytecode allows us to reuse existing libraries for handling
%RDF, including the Jena library\footnote{\url{http://jena.apache.org/}}.

The basic structure of LIXR is inspired by XSLT and is based around \emph{handlers},
which describe the action that should be taken when a specific XML element is 
encountered. These handlers are stated by linking an XML element name to a list
of \emph{generators} with the {\tt -->} operator. For example the following LIXR
expression can be used:

\begin{verbatim}
xml.language --> (
  dc.language > content
)
\end{verbatim}

This associates the XML element {\tt <xml:language>} to
generating the triple \emph{s} {\tt dc:language} {\tt "}\emph{c}{\tt "}, 
where \emph{s} is the current subject node, and \emph{c} is the text content of
the node\footnote{Note that for technical reasons the {\tt .} is used to conjoin the namespace
to the local name instead of the customary {\tt :}. This, in fact, is 
a dynamic call a relatively recent feature of the Scala language.} More typically
the converter works by means of two features: firstly, {\tt node}s instruct the RDF generation
to create a new node in the RDF graph and use it as subject for all triples
from this point in the generation. Secondly, the {\tt handle} tells the XML parser to look for all 
children matching a given element and call the appropriate handler for each matching
case. For example:

\begin{verbatim}
xml.metadata --> (
  node("http://.../metadata")(
    handle(xml.language),
    handle(xml.source)
  )
)
\end{verbatim}

This code asks the RDF generator to create a new root node with the given URI. The parser
then looks for matching children and calls the appropriate handlers
(such as in the first example). 
%In the opposite direction (RDF to XML), it is
%possible to generate the XML by walking the RDF diagram as a tree. 
More detail
of the language can be found on
Github\footnote{\url{https://github.com/liderproject/lixr}}.
%\footnote{
%The LIXR language allows for cycles in RDF graphs only by double naming of
%{\tt node}s} generating a
%element for any handler where all of its mandatory generators and at least one 
%generator is active. For example, if a triple is generated this is considered
%mandatory, however {\tt handle}s are not mandatory. In some cases, this means that
%`round-tripping', that is the conversion of RDF to XML and back to RDF, may not
%be possible. For example, the {\tt substring} function can not be used in the
%inverse direction and is defined by means of two lambda functions, based on
%the generic {\tt transform} generator:
%
%\begin{verbatim}
%def substring(tg : TextGenerator, s : Int, e : Int) =
%  transform(tg)
%           (string => string.substring(s, e))
%           (throw new UnsupportedOperationException())
%\end{verbatim}
%
%This defines a substring as a {\tt transform} of a text element, {\tt tg}, which
%is realized in the XML-to-RDF direction by the lambda function that calls the 
{'fraction_non_alphanumeric': 0.0698876805134605, 'fraction_numerical': 0.007369109169786652, 'mean_word_length': 4.733560477001704, 'pattern_counts': {'":': 0, '<': 21, '<?xml version=': 0, '>': 31, 'https://': 1, 'lorem ipsum': 0, 'www.': 4, 'xml': 12}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6925989', 'n_tokens_mistral': 4705, 'n_tokens_neox': 4458, 'n_words': 2278}