Combining graph and tree: writing SHAX, obtaining SHACL, XSD and more

RDF ([7], [8]) defines a unified view of information which enables the integration of wildly heterogenous data sources into a uniform graph of RDF nodes. A similar quality has XML. If understood as a data model and technology, rather than a syntax, it can translate tree-structured documents irrespective of the domain of information, the vocabulary used and even the media type (XML, HTML, JSON, CSV, …) into a uniform forest of XDM nodes. Thus both, RDF and XML, offer us the translation of heterogeneous information landscapes into homogeneous spaces of nodes, amenable to powerful tools for addressing, navigating and transforming the contents of these spaces. In spite of the similarities, though, both technologies have different and complementary key strengths, and an integration of RDF and XML technologies is a very promising goal.

A key aspect of integration is how we think about and model RDF data and XML data. Integration might be built upon a careful alignment of these concepts and models, but we must acknowledge a serious mismatch between the major data modeling languages used to describe RDF (RDFS [9] and OWL [5], [6]) and XML data (XSD [16]), respectively. RDF languages are designed for inferencing, and XML modeling concentrates on data validation. The differences do not only pose technical problems, they also reflect quite different mindsets prevailing in the RDF and XML communities.

A new situation has been created by the recent standardization of the Shapes Constraint Language (SHACL, [10]), which is an RDF data modeling and validation language. This paper attempts to identify new possibilities and takes a step towards using them. It introduces SHAX (SHAcl+Xml), which is essentially an XML syntax for SHACL, but might also be regarded as a new and very simple data modeling language which can be translated into both, SHACL and XSD, and thus target RDF and XML data alike. SHAX models are simple to write and to understand, and they may narrow the gap between RDF and XML both conceptually and technically. In particular, they can provide a platform on which to build model-driven translations between RDF graphs and XML trees.

Integration of RDF and XML can be inspired by a clear perception of their essential relationship. At first sight, RDF seems to take a totally unique and “lonely” view of information, reducing it to the atomic unit of a triple: subject, predicate, object. However, when grouping these primary units by subject resource, a secondary unit emerges, which is an entity and its properties. Similarly, a complex XML element can be viewed as an entity enclosing information content. Both, properties and content amount to an itemized description of the entity. Through the equating of properties and content items, one approaches an overarching abstraction: an information object. A brief, informal account follows:

Compared to XML, RDF is marked by key strengths. It captures information in an impartial way: RDF predicates do not presuppose that the subject is “larger”, more general or more interesting than the object. XML represents a partial view, as the containment relationship is arbitrarily directed (does a book contain authors or an author books?), usually reflecting an application-based perspective.

A second aspect is the amphibian nature of RDF: while it allows to perceive a solid structure composed of objects (see above), RDF data is at the same time a mere collection of triples, without any primary structure whatsoever. It is like a liquid of information, and this implies a huge benefit: RDF graphs can be merged. Finally, RDF is a natural representation of complex graphs (where anything can be related to anything), and such graphs are a natural representation of most non-trivial systems.

XML, however, has unrivalled power of its own. Tree structure is a natural response of the human mind to complexity, as it enables the perception of a coherent whole. It allows a switching between alternative levels of detail. Due to the “spatial” organisation of tree content, navigation can be expressed with superb elegance (XPath). Leveraging this navigation engine, the transformation of trees into all kinds of artifacts – including graphs – is accomplished with amazing ease (XQuery, XSLT).

RDF and XML functioning in cooperation may be regarded as a technological dream team. RDF excels as the organisation of “potentially useful information”; XML excels as the organisation of “ready-for-use” information. How to combine these fundamental strengths? Ultimately, both technologies are about shaping and processing datasets. If datasets can be viewed as instances of data models, the integration of RDF and XML might leverage the knowledge pent up in these models. What is clearly called for is model-driven approaches.

The integration of RDF and XML – or, more generally, graph and tree technology - has many interesting aspects. For example, if RDF data describe XML resources in terms of various metadata, XML navigation of a document forest (e.g. the internet) might be supported by SPARQL queries mapping conditions on resource metadata to resource URIs.

Distributed software components communicate via messages, which are usually tree-structured datasets. If the information required by a software component is RDF-based, the typical task at hand is thus the transformation of RDF graph data into an XML or JSON tree. Inversely, if an update of RDF data is necessary and the data is supplied by messages, the transformation of trees into graph data is required.

Remembering the appropriateness of RDF to serve as an unbiased representation of “potentially useful information”, the translation of RDF data into a ready-for-use form inspires great interest. For the purpose of this paper, we concentrate on the transformation of trees into graphs and of graphs into trees. Such transformation can always be accomplished by custom code. But given the close relationship between the RDF and XML models (argued in the previous section), transformation should be facilitated by standards or products. Table 1 compiles some approaches to the transformation between RDF and XML data.

It is interesting to note that - apart from GraphQL ([1]) - none of these approaches builds on a data model describing the graph data in terms of type definitions that might be aligned with the building blocks of trees. Equally interesting is the fact that GraphQL is not concerned with RDF and XML data, but with a data source described by an abstract type system and a data target described by an abstract tree model. These observations have an explanation: before SHACL, there was no standardized data modeling language fit for supporting the transformation from/into graph data.

The advent of SHACL creates new possibilites. For the first time, integration might leverage an RDF data modeling language which can be aligned with an XML data modeling language - perhaps enabling the alignment of RDF data model components with XML data model components.

The W3C recommendation ([10]) introduces SHACL as a “language for describing and validating RDF graphs.” It is defined as an RDF vocabulary which can be used to describe data structures, data types and business rules. The key abstractions are constraints and shapes. A constraint is a condition which particular RDF nodes must meet. A shape is a set of constraints, which jointly must be adhered to. A shape can be thought of as a type, which may be a simple data type or an object type for resources with properties.

Let us consider a very simple example and try to model RDF data describing flight bookings. We decide that a flight booking is represented by a resource belonging to the RDF class e:FlightBooking. We want to introduce several constraints: a flight booking has …

This model is a fit for the following RDF graph, represented in Turtle syntax:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix e:   <http://example.org/ns/model#> .
@prefix o:   <http://example.org/ns/objects#> .

o:FB101  a                   e:FlightBooking ;
         e:BookingChannel    2 ;
         e:BookingDate       "2017-12-31"^^xsd:date ;
         e:BookingID         "123456789XYZ" ;
         e:OperatingAirline  o:AL902 , o:AL901 .

o:AL902  e:AirlineCode       "KL" ;
         e:AirlineName       "KLM - Royal Dutch Airlines" .

o:AL901  e:AirlineCode       "LH" ;
         e:AirlineName       "Lufthansa" .

The graph can be validated with a SHACL model, which is itself an RDF graph. Here comes a SHACL model encoding the description given above, represented in Turtle syntax.

@prefix sh:   <http://www.w3.org/ns/shacl#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix e:    <http://example.org/ns/model#> .

# object types
# ============ 
e:FlightBookingType
   a sh:NodeShape ;
   sh:targetClass e:FlightBooking ;
   sh:property [
      sh:path e:BookingID ;
      sh:minCount 1 ;
      sh:maxCount 1 ;
      sh:node e:BookingIDType ;
   ] ;
   sh:property [
      sh:path e:BookingDate ;
      sh:minCount 1 ;
      sh:maxCount 1 ;
      sh:datatype xsd:date ;
   ] ;
   sh:property [
      sh:path e:BookingChannel ;
      sh:maxCount 1 ;
      sh:datatype xsd:integer ;
   ] ;
   sh:property [
      sh:path e:OperatingAirline ;
      sh:minCount 1 ;
      sh:node e:AirlineType ;
   ] .

e:AirlineType
   a sh:NodeShape ;
   sh:property [
      sh:path e:AirlineCode ;
      sh:minCount 1 ;
      sh:maxCount 1 ;
      sh:node e:AirlineCodeType ;
   ] ;
   sh:property [
      sh:path e:AirlineName ;
      sh:maxCount 1 ;
      sh:datatype xsd:string ;
   ] .

# data types 
# ========== 
e:BookingIDType
   a sh:NodeShape ;
   sh:datatype xsd:string ;
   sh:minLength 12 ;
   sh:maxLength 40 .

e:AirlineCodeType
   a sh:NodeShape ;
   sh:datatype xsd:string ;
   sh:pattern "^[A-Z]{2}$" .

This structure can be read as follows: e:FlightBookingType is a shape modeling the members of a particular RDF class (e:FlightBooking), and each sh:property […] statement describes a mandatory or optional property of those resources, with a property name identified by sh:path:

e:FlightBookingType
   a sh:NodeShape ;
   sh:targetClass e:FlightBooking ;
   sh:property [sh:path: e:BookingID ; …];
   sh:property [sh:path: e:BookingDate ; …];
   sh:property [sh:path: e:BookingChannel ; …];
   sh:property [sh:path: e:OperatingAirline ; …];>

Further settings within the sh:property[…] statements constrain the property in terms of cardinality and value type, e.g.:

sh:property [
      sh:path e:BookingDate ;
      sh:minCount 1 ;
      sh:maxCount 1 ;
      sh:datatype xsd:date ;
   ] ;>

constrains the e:BookingDate property to have exactly one value which is a date.

The example demonstrated capabilities which are similar to those of the XSD language. XSD describes data structure in terms of element contents (attributes and child elements), whereas SHACL describes data structure in terms of resource properties (data and object properties). XSD constrains content items in terms of name, cardinality and a type which is either a simple data type or a model of (nested) element contents. SHACL constrains properties in terms of name, cardinality and a type which is either a simple data type or a model of (nested) resource properties.

Accepting the analogy between element contents and resource properties, one realizes that most capabilities of XSD can be expressed in SHACL. But SHACL has still more to offer. First, it supports constraints targeting pairs of properties – e.g. stating that the value of one property must be less than the value of another property. SHACL also allows the construction of complex constraints which are a logical combination of other constraints (sh:and, sh:or, sh:not, sh:xone). A property can for example be described as either a string or one of several alternative object types.

SHACL models can describe “virtual” properties, which do not correspond to a simple property IRI, but are defined as a property path expression. The following are a few examples:

sh:path ( ex:address ex:street )
sh:path [ sh:inversePath ex:parent ]
sh:path [ sh:alternativePath ( ex:father ex:mother ) ]
sh:path ( ex:reads [ sh:zeroOrMorePath ex:cites ] )

Perhaps most importantly, SHACL supports the use of SPARQL queries for expressing constraints of virtually unlimited complexity and specificity. Such expressions could be used to capture XSD features not explicitly supported (like choice groups, identity constraints and XSD 1.1 assertions), as well as arbitrary business rules which are typically validated by Schematron models.

To summarize, SHACL combines the capabilities of XSD and Schematron. Besides, it allows the construction of complex constraints and supports virtual properties.

The SHACL language enables a modeling of RDF data which makes them understandable for anyone familiar with data modeling, not requiring a deep understanding of RDF. Such models facilitate the development of applications processing or creating RDF data. Apart from this mental level, SHACL-based validation enables elaborate guarantees of data quality, which may reduce code complexity.

How to use these potential benefits in practice? Several problems must be overcome:

These difficulties might be overcome by an XML representation of SHACL models. It offers a simple tree structure which is trivial to write and read. An XML representation can be translated into object oriented structures (e.g. via JAXB [2]) or directly processed by powerful processing and transformation languages (XQuery [15] and XSLT [17]). The convolutions sometimes required to express basic grammatical constructs (choice groups and properties-as-building-blocks) can be hidden behind the façade of a straightforward expression of intent.

The promise of an XML representation goes beyond this simplification of writing, reading and processing of SHACL models. It may pave the way for abstract data models, which define data structures and data types, but refrain from prescribing the representation language, in particular RDF versus non-RDF expression like XML or JSON. This possibility could be realized by transforming the XML representation of a SHACL model alternatively into a SHACL model (applicable to RDF data) or an instance of a non-RDF data modeling language, like XSD ([16]) or JSON Schema ([3]), which describes a non-RDF representation of RDF content.

If the XML representation is designed to increase the abstraction level of a SHACL model, a single XML source might be used to generate alternative SHACL styles. An example is the use of local versus global shapes, comparable to XSD styles preferring local versus global types. Last but not least, an XML representation might prove a convenient platform for augmenting model components with metadata – for example metadata specifying a data source for constructing the item, or a data destination for dispatching the item.

The remainder of this paper introduces SHAX (= SHAcl+Xml), which can be regarded as an XML representation of (some core parts of) the SHACL language, or, alternatively, as a new data modeling language which may be translated into SHACL, XSD and JSON Schema.

A SHAX model describes object types in terms of their properties. The following SHAX model describes a single object type (e:FlightBookingType) which represents a flight booking:

<shax:model defaultCard="1"
    xmlns:shax="http://shax.org" xmlns:e="http://example.org/" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    
    <!-- object types
         ============ -->    
    <shax:objectType name="e:FlightBookingType" class="e:FlightBooking">
        <e:BookingID type="e:BookingIDType"/>
        <e:BookingDate type="xsd:date"/>
        <e:BookingChannel card="?" type="xsd:integer"/>        
    </shax:objectType>
    
    <!-- data types 
         ========== -->    
    <shax:dataType name="e:BookingIDType" 
                   base="xsd:string" minLen="12" maxLen="40"/>   
</shax:model>
            

Flight bookings have three properties:

The BookingChannel is optional (@card="?"), and the other properties are mandatory (@defaultCard="1"). The model is matched by the following RDF data:

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix e:   <http://example.org/ns/model#> .
@prefix o:   <http://example.org/ns/objects#> .

o:FB101 a                 e:FlightBooking ;
        e:BookingChannel  2 ;
        e:BookingDate     "2017-12-31"^^xsd:date ;
        e:BookingID       "123456789XYZ" .>

After downloading the SHAX processor from github ([14]), we can translate our SHAX model into a SHACL model. The command line call:

    shax "shacl?shax=flightBooking01.shax"

produces the following model:

@prefix sh:  <http://www.w3.org/ns/shacl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix e:   <http://example.org/ns/model#> .

# object types
# ============ 
e:FlightBookingType
   a sh:NodeShape ;
   sh:targetClass e:FlightBooking ;
   sh:property [
      sh:path e:BookingID ;
      sh:minCount 1 ;
      sh:maxCount 1 ;
      sh:node e:BookingIDType ;
   ] ;
   sh:property [
      sh:path e:BookingDate ;
      sh:minCount 1 ;
      sh:maxCount 1 ;
      sh:datatype xsd:date ;
   ] ;
   sh:property [
      sh:path e:BookingChannel ;
      sh:maxCount 1 ;
      sh:datatype xsd:integer ;
   ] .

# data types 
# ========== 
e:BookingIDType
   a sh:NodeShape ;
   sh:datatype xsd:string ;
   sh:minLength 12 ;
   sh:maxLength 40 .>

In order to see this model at work, we launch the “SHACL playground” ( http://shacl.org ) in a browser and copy model and instance data into the areas labeled “Shapes Graph” and “Data Graph”. Using the “Update” buttons beneath both areas, we observe that the data are valid against the model. We also observe how various manipulations of instance data or the model cause validation errors (see area “Validation Report”, where any error reports appear).

Having seen that our SHAX model can be compiled into a functional SHACL model, we proceed to extend our model, adding a property OperatingAirline. This is an object property, as the property values are objects which have their own properties: a mandatory code (two uppercase letters) and an optional name (string). Here comes the new version:

<shax:model defaultCard="1"
    xmlns:shax="http://shax.org/ns/model" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:e="http://example.org/ns/model">
    
    <!-- object types
         ============ -->    
    <shax:objectType name="e:FlightBookingType" class="e:FlightBooking">
        <e:BookingID type="e:BookingIDType"/>
        <e:BookingDate type="xsd:date"/>
        <e:BookingChannel card="?" type="xsd:integer"/>        
        <e:OperatingAirline card="+" type="e:AirlineType"/>
    </shax:objectType>
    
    <shax:objectType name="e:AirlineType">
        <e:AirlineCode type="e:AirlineCodeType"/>
        <e:AirlineName card="?" type="xsd:string"/>       
    </shax:objectType>
    
    <!-- data types 
         ========== -->    
    <shax:dataType name="e:BookingIDType" 
                   base="xsd:string" minLen="12" maxLen="40"/>
    <shax:dataType name="e:AirlineCodeType" 
                   base="xsd:string" pattern="^[A-Z]{2}$"/>    
    
</shax:model>

Note the cardinality constraint (@card="+"), which means “one or more” values. In the final step we add a Customer property:

<shax:model defaultCard="1"
    xmlns:shax="http://shax.org/ns/model" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:e="http://example.org/ns/model">
    
    <!-- properties
         ========== -->    
    <shax:property name="e:FlightBooking" type="e:FlightBookingType"/>

    <!-- object types
         ============ -->    
    <shax:objectType name="e:FlightBookingType" class="e:FlightBooking">
        <e:BookingID type="e:BookingIDType"/>
        <e:BookingDate type="xsd:date"/>
        <e:BookingChannel card="?" type="xsd:integer"/>        
        <e:OperatingAirline card="+" type="e:AirlineType"/>
        <e:Customer type="e:CustomerType"/>        
    </shax:objectType>
    
    <shax:objectType name="e:AirlineType" class="e:Airline">
        <e:AirlineCode type="e:AirlineCodeType"/>
        <e:AirlineName card="?" type="xsd:string"/>       
    </shax:objectType>
    
    <shax:objectType name="e:CustomerType" class="e:Customer">
        <e:LastName type="xs:string"/>
        <e:FirstName type="xs:string"/>
        <shax:choice>
            <e:PassportNumber type="xsd:string"/>
            <shax:pgroup>
                <e:LoyaltyProgramCode type="e:LoyaltyProgramCodeType"/>
                <e:LoyaltyProgramMemberID type="xsd:integer"/>
            </shax:pgroup>
        </shax:choice>
    </shax:objectType>    

    <!-- data types 
         ========== -->    
    <shax:dataType name="e:BookingIDType" 
                   base="xsd:string" minLen="12" maxLen="40"/>
    <shax:dataType name="e:AirlineCodeType" 
                   base="xsd:string" pattern="^[A-Z]{2}$"/>    
    <shax:dataType name="e:LoyaltyProgramCodeType" 
                   base="xsd:integer" min="1" max="999"/>
</shax:model>

Here comes a conforming RDF graph, this time represented in JSON-LD:

{
   "@context": { 
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "e": "http://example.org/ns/model#",
      "o": "http://example.org/ns/objects#"
   },
   "@graph": [
      {    
         "@id": "o:FB101",
         "@type": "e:FlightBooking",
         "e:BookingID": "123456789XYZ",
         "e:BookingDate": {"@value": "2017-12-31", "@type": "xsd:date"},
         "e:BookingChannel": 2,
         "e:OperatingAirline": [
             {
                "@id": "o:AL901",
                "e:AirlineCode": "LH",
                "e:AirlineName": "Lufthansa"
             },
             {
                "@id": "o:AL902",             
                "e:AirlineCode": "KL",
                "e:AirlineName": "KLM - Royal Dutch Airlines"
             }
         ],
         "e:Customer": {
            "e:LastName": "Perez",
            "e:FirstName": "Deborah",
            "e:LoyaltyProgramCode": 800,
            "e:LoyaltyProgramMemberID": 81557 
        }         
      }
   ]
}

The SHAX model is translated into a SHACL model which is more than three times as long (see Appendix A, SHACL model obtained from SHAX). Note that the SHACL model does implement the choice group structure (see the sh:xone element), but it does not make this structure explicit.

To summarize, this section demonstrated various features of SHAX models, including object and data types, cardinality constraints and the grammatical structure of a choice group. The next section gives a more systematic overview of the SHAX language.

A SHAX model is represented by a shax:model element which contains various kinds of top-level model components:

Models can import other models, using shax:import elements.

<shax:objectType name="e:BookingType" class="e:Booking" nodeKind="IRI">…

<shax:objectType name="e:BookingType" class="e:Booking" nodeKind="IRI">
    <e:BookingID type="e:BookingIDType"/>
    <e:BookingDate type="xsd:date"/>
    <e:BookingChannel card="?" type="xsd:integer"/>        
</shax:objectType>

<shax:objectType name="e:FlightBookingType" extends"e:BookingType">
    <e:OperatingAirline card="+" type="e:AirlineType"/>
</shax:objectType>

<shax:objectType name="e:FlightBookingType" extends"e:BookingType">
    <e:OperatingAirline card="+"/>
</shax:objectType>
    …
<shax:property name="e:OperatingAirline" type="e:AirlineType"/>

<shax:choice>
     <e:PassportNumber type="xsd:string"/>
     <shax:pgroup>
         <e:LoyaltyProgramCode type="e:LoyaltyProgramCodeType"/>
         <shax:choice>
             <e:LoyaltyProgramMemberID type="xsd:integer"/>
             <e:PreliminaryMemberID type="xsd:string"/>
         <shax:choice>
     </shax:pgroup>
</shax:choice>

<shax:objectType name="e:FlightBookingType" extends"e:BookingType">
    <e:Airline card="+"/>
</shax:objectType>
   …
<shax:property name="e:Airline" type="e:AirlineType"/>
<shax:property name="e:OperatingAirline" type="e:AirlineType"                                                                     
               substitutes="e:Airline"/>
<shax:property name="e:MarketingAirline" type="e:MarketingAirlineType"                                                                        
               substitutes="e:Airline"/>
   …
<shax:objectType name="e:MarketingAirlineType" extends="e:AirlineType">…

<shax:dataType name="e:AirlineCodeType" 
               base="xsd:string" pattern="^[A-Z]{2}$"/>
               
<shax:dataType name="e:GenderType" base="xsd:string"> 
    <shax:value>male</shax:value>
    <shax:value>female</shax:value>
</shax:dataType/>

<shax:dataType name="e:AirlineCodesType" 
               itemType="xsd:AirlineCodeType" 
               minSize="1">
               
<shax:dataType name="e:ExtendedCurrencyType" 
               memberTypes="xsd:CurrencyCodeType xsd:int">

SHAX can be used for constructing abstract data models – models defining structures of information content, but not prescribing the data format of concrete representations. In order to allow validation of data against a SHAX model, data can be represented in different formats:

For each of these formats, a SHAX model can be translated into an appropriate data validation language (SHACL, XSD, JSON Schema). Note that these translations may involve a certain loss of information. The sequence of properties, for example, is not preserved when translating into JSON Schema, and when translating into SHACL, although it is preserved as information (using sh:order), it loses its impact on validation. Another example is property pair constraints (e.g. @shax:lessThan) which are only preserved when translating into SHACL.

sh:resultMessage "Value does not have shape e:BookingIDType" ;
sh:resultMessage "Value has less than 12 characters" ;

<e:FlightBooking xmlns:shax="http://shax.org/ns/model" 
                 xmlns:e="http://example.org/ns/model" 
                 xmlns:o="http://example.org/ns/objects" 
                 shax:IRI="o:FB101">   
    <e:BookingID>123456789XYZ</e:BookingID>
    <e:BookingDate>2017-12-31</e:BookingDate>
    <e:OperatingAirline shax:IRI="o:AL901">
        <e:AirlineCode>LH</e:AirlineCode>
        <e:AirlineName>Lufthansa</e:AirlineName>        
    </e:OperatingAirline>
    <e:OperatingAirline shax:IRI="o:AL902">
        <e:AirlineCode>KL</e:AirlineCode>
        <e:AirlineName>KLM - Royal Dutch Airlines</e:AirlineName>        
    </e:OperatingAirline>
    <e:Customer>
        <e:LastName>Perez</e:LastName>
        <e:FirstName>Deborah</e:FirstName>
        <e:LoyaltyProgramCode>800</e:LoyaltyProgramCode>
        <e:LoyaltyProgramMemberID>81557</e:LoyaltyProgramMemberID>        
    </e:Customer>
</e:FlightBooking>

A SHAX processor accomplishes the translation of SHAX models into SHACL, XSD and JSON Schema models. An implementation of a SHAX processor is available on github (https://github.com/hrennau/shax). The processor is provided as a command line tool. Example calls:

shax shacl?shax=airportSystem.shax
shax xsd?shax=airportSystem.shax
shax jschema?shax=airportSystem.shax

Any transformation of RDF data into XML documents can be accomplished by custom code. However, in situations where source and/or target data are described by data models, it would be unsatisfactory if custom code were the only option. A model-driven alternative might define a way how available descriptions of source or target structures can control the transformation and thus significantly reduce the effort. A detailed investigation of such possibilities is beyond the scope of this paper, but an example is sketched. The general goal is to enable transformation implemented in a declarative way, that is, modeling the transformation, rather than coding it.

A transformation of RDF data into an XML representation might be defined in terms of an EFRUG model, which expresses transformation as the successive application of operations to RDF source data. The operations have a generic definition and respond to model facts in a configurable way. Starting with a root resource to be transformed …

Note that the key step is a filtered iteration over properties, combined with recursive expansion of object properties. It is easy to implement such an iteration, given a graph model expressed in SHAX, and it should not be difficult to render the filtering configurable, perhaps using whitelists and blacklists of regular expressions.

The SHAX language as described in this paper is only a preliminary version serving as a proof of concept. It focuses on a subset of the SHACL language which enables the definition of a traditional object type system, as this subset is key for aligning RDF models and tree models like XSD. Future work should strive for a steady increase of the supported capabilities of SHACL. It is to be hoped that the simplicity and clarity of the SHAX language will be preserved in the process.

We regard the SHACL language as an important advance, which makes the introduction of an abstract data modeling language possible – a language capable of describing graph and tree encoded information. Key aspects of this language are the definition of equivalence between RDF and non-RDF representations, and the transformation of the abstract model into concrete, validating models for each major representation language.

The greatest problem ahead may not be a technical one, but a cultural one: to arouse in both communities, RDF and XML, an awareness of how complementary their technologies are, of how incomplete they are without each other.