Linked Data in the construction industry is a topic gaining serious interest over the last years. However, this interest remains largely academic and has not sparked much adoption of web technologies in the field. To nourish adoption of Linked Data in practice, access to the data has to be made more easy. SPARQL, the recommended RDF query language, has proven very powerful for retrieving and updating RDF datasets. However, due to its verbosity and complexity, it is often considered a threshold for developers to implement in their tools. In this paper, we compare SPARQL with Linked Data querying languages that extend the GraphQL syntax, in context of querying building datasets: HyperGraphQL and GraphQL-LD. Since it went open source in 2015, GraphQL has been adopted by a large community of developers, partly due to its elegance and conciseness. As a use case, the queries are performed on an RDF-based multi-model that relies on the recent ISO standard ICDD (ISO 21597). ICDD interlinks information on a subdocument identifier level, based on OWL. It is aimed at the industry in that it adds a layer of Linked Data to documentation formats that are still widely used in practice: IFC, spreadsheets, imagery etc. Therefore, it is considered a tuned use case for comparing these different RDF query languages.
GraphQL. The advent of Building Information Modelling (BIM) has brought a revolution to the way a construction project is designed, constructed and maintained. BIM addresses the need for an ‘information hub’ that contains and manages information on architecture, engineering and ’Mechanical, Electrical, Plumbing’ (MEP) topics. Through BIM, professionals in these disciplines are able to communicate in a much more streamlined way than before.
In an ideal building industry, linking of available information happens, and
happens on a data level. This has been proposed multiple times since the late
2000s [
In the building industry field, however, the use of RDF (Resource Description
Framework), OWL (Web Ontology Language) and other web technologies is still
largely an academic topic, and not all pitfalls are solved to convince BIM software
providers and the industry to dive into the world of Linked Building Data. More
achievable at the moment is a cross-document way of linking sources and BIM
documents, instead of implementing the project entirely in RDF. However, this
is not applied very frequently either. To improve an ontology-based, link
setoriented approach [
In the same ideal world, RDF data is queried by use of the official W3C
recommendation SPARQL (SPARQL Protocol and RDF Query Language)4. However,
SPARQL is often considered too high a threshold for developers to implement in
their tools as a querying language [
schemaless deployment. In this paper, we investigate the potential of both
HyperGraphQL and GraphQL when querying a fixed, local dataset. The discussed
use case differs from the one in [
2.1
In its own words, ICDD has been developed ‘in response to the need of the
construction industry to handle multiple documents as one information delivery or
data drop.’ It is a successor of the Dutch COINS standard and fits in a tradition
of ontology-based management of multi-models [
A container in .icdd format (using a ZIP-compression) consists of a fixed folder structure, with separations between ontologies (Ontology resources ), documents (Payload documents ), specific linksets (Payload triples ) and content description (index.rdf ) (Fig. 1). Graphs that describe a container’s content and links between documents are stored in different graphs, but refer to the same URIs of documents. A visual graph depicting the link between two documents is given in Fig. 2. 2.2
GraphQL7 is both a data query language and a specification to minimise and optimise data transfer over the web over a GraphQL API. It is specifically aimed at improving client-server interactions and has been adopted by multiple large players on the web. Its core exists of a schema that describes the data to use: its class, its fields and the classes or datatypes those fields may refer to. From this perspective, these schemes can be visualised as graphs. However, they should not be interpreted as RDF graphs, as the types and fields that are used are not uniquely identifiable, as is the case with RDF graphs. Nevertheless, this structure allows to describe interlinked data in a coherent way, to query this data and to update or delete it. One of the reasons GraphQL had such an adoption rate over the last years, is the simplicity of querying: essentially, it requires the client to state the desired classes and their fields, possibly accompanied by specific parameters (Table 1). The response will be a JSON object. This simplicity stands in contrast to, for example, SPARQL: although SPARQL is more expressive, a lot of developers prefer the much more minimalistic syntax of GraphQL. Although GraphQL has essentially no relationship to RDF, a GraphQL schema could be provided with the universal context that is missing in the original specification. Such context would extend the schema to the level of the semantic web, using IRIs. Thus far, two open source projects have implemented this extension in a slightly different way: either by implementing the original specification 7 https://graphql.org/ } } } } and schema syntax (HyperGraphQL) or by only adopting the query syntax and translate it to SPARQL ‘under-the-hood’ (GraphQL-LD).
HyperGraphQL In the approach of HyperGraphQL, an intermediary service is set up, connecting the GraphQL client with the RDF graphs to be queried. Just like in a ’classic’ GraphQL approach, HyperGraphQL needs a schema that defines the right types and fields. In RDF terms, the types that are defined relate to the resources defined in an ontology, which means instances of owl:Class as well as instances of owl:Property. The GraphQL types that refer to an owl:Class are then extended by fields that relate to the properties that have this class as a domain, ‘pointing’ at their range. Types that are not included in the schema, cannot be queried. This provides the data supplier with a mechanism of finegrained selection of which datatypes can be queried via the ‘lens’ of a GraphQL schema. A subset of a schema applied to the ICDD, is depicted in Listing 1.1. type __Context {
InternalDocument : _@href ( i r i : " c t : InternalDocument ") f i l e t y p e : _@href ( i r i : " c t : f i l e t y p e ") b e l o n g s T o C o n t a i n e r : _@href ( i r i : " c t : b e l o n g s T o C o n t a i n e r " ) C o n t a i n e r D e s c r i p t i o n : _@href ( i r i : " c t : C o n t a i n e r D e s c r i p t i o n ") type InternalDocument @ s e r v i c e ( i d : " i c d d ") { f i l e n a m e : S t r i n g @ s e r v i c e ( i d : " i c d d " ) b e l o n g s T o C o n t a i n e r : [ C o n t a i n e r D e s c r i p t i o n ] @ s e r v i c e ( i d : " i c d d ") } Listing 1.1. Fragment of a HyperGraphQL schema. <Container> in the Context should be replaced with the original URI.
Apart from that, a HyperGraphQL instance needs a config.json file as a setup guide (Listing 1.2. The config.json file states data for setting up the server, such as its name, the schema to use and the hosting port. Furthermore, it defines the RDF graphs that can be queried by providing a local path or URI to the graph. Multiple graphs can be included in one configuration file, although types in a schema can only be used to query one service. For example, the types defined in Listing 1.1 are set to be queried against the graph with ‘icdd’ as a name (defined in the config.json file). This means that for querying multiple graphs with the same types, these should be merged before querying. Listing 1.2 depicts a schema that uses a schema with name schemaICDD.graphl (relative path) and queries a local TTL graph with id ‘icdd’. { } " i d " : " i c d d " , " t y p e " : " LocalModelSPARQLService " , " f i l e p a t h " : " s r c / main / r e s o u r c e s /ICDD . t t l " , " f i l e t y p e " : "TTL"
Listing 1.2. Example of a config.json file used by a HyperGraphQL service.
GraphQL-LD In contrast with the HyperGraphQL approach, GraphQL-LD
does not require an additional service to be set up between server and client
[
Comparison Both solutions have their merits and disadvantages. As they are essentially querying tree structures, they are less expressive than SPARQL, but they allow a more accessible way of querying basic RDF datasets. Nevertheless, neither of them has the option to perform ‘mutations’, which can alter an existing database. Developers who want their apps to work with existing RDF databases (i.e. creating, reading, updating, deleting), can currently only read data if they use a GraphQL syntax. Furthermore, both are works in progress, which means not all expressivity of GraphQL can be implemented. For example, the concept
of subclasses is available in GraphQL, but not in HyperGraphQL: querying some
fields of a product:BuildingElement will not automatically query these fields
for subclasses defined in the ontology (product:Door or product:Window will
not be included in the results), because, as far as we know, there is currently no
equivalent of GraphQL Union or Interface implemented in HyperGraphQL. In
the case of GraphQL-LD, this is less of a problem, since the eventual query is
performed using SPARQL. If the query is performed against a SPARQL endpoint
with reasoning, there is no real difference with an ‘original’ SPARQL query.
A disadvantage (in certain contexts) of GraphQL-LD, on the other hand, is
that it is ’predicate-oriented’, which makes it difficult to perform subject-based
queries, requiring a workaround that complicates the GraphQL query itself. A
more detailed comparison between both query languages has been made by [
In the next section, an ICDD container will be queried using these approaches: HyperGraphQL, GraphQL-LD and SPARQL. A GraphQL schema and config.json for HyperGraphQL is automatically generated with a basic convertor tool in development10, as well as a JSON context for GraphQL-LD. 3
The sample dataset ‘usecase_1b_delivery’11 is used as a case study. It is a lightweight ICDD container that fits for demonstration purposes. Using the abovementioned query languages, the container will be queried for available sources, their name and filetype. Secondly, the container will be searched for links between the documents on a sub-document level. We will compare the results of different query types. 3.1
In order to set up a query engine with HyperGraphQL, some pre-processing steps need to be carried out first: 1. config.json: First, a configuration file is made, containing the information to be used by the HyperGraphQL engine (e.g. the schema that is used and the services that are queried). 2. Schema conversion: The next step is the conversion of the ontologies that are present in the ICDD folder into a HyperGraphQL schema. Each type in the schema refers to the service that it needs to query. 3. Data preparation: It has been mentioned that types in a HyperGraphQL schema are working on only one service, while a linked ICDD container essentially contains at least two describing graphs: the index.rdf graph and the links.rdf (or content.rdf ). Both need to be parsed into a single graph that can be used as one service in the config.json file, and to which the types in the schema can refer. 10 https://github.com/JWerbrouck/Ontology2GraphQL 11 http://www.iso-icdd.org/examples/part1/usecase_1b_delivery.icdd 4. Service setup: Quering with HyperGraphQL requires the setup of an intermediary service. This HyperGraphQL engine is bound to the schema, so if the schema alters, the engine needs to be restarted. After the startup of the service, a graphical interface (GraphiQL) for querying the graph is set up, which can be used for performing GraphQL queries. The first query is aimed at finding all documents that are linked in the container (Fig. 3). A first issue is that only subclasses of ct:Document are present in the folder. As mentioned, subclass inference is not implemented, so the different types of documents need to be queried explicitly. The second query searches for links between identifiers within documents (Fig. 4). However, the schema had to be adapted manually, for the range of ls:hasDocument to focus on InternalDocument instead of its superclass ct:Document. This is possible because we knew before that there were no other types of documents in the ICDD sample datasets. In a real world situation, this will not always be the case, which makes it quite a large disadvantage. The reason that it was possible in the first scenario to query withouth adapting the scheme, is because there, InternalDocument was queried as a GraphQL type, not as a field. 3.2
For querying with GraphQL-LD, only a JSON-LD context is needed (e.g. Listing 1.3). Since we focus on querying, we only use the GraphQL-to-SPARQL module and perform the resulting SPARQL query on a triple store (Fuseki) that contains both the index.rdf and links.rdf graphs. The same query looks slightly different when compared to the query performed in section 3.1, due to the difference in processing. Because GraphQL-LD is predicate-oriented, a workaround has to be made to query for an object with given class (Listing 1.4). Furthermore, the variables of the query are automatically set to the fields that are queried, ignoring the GraphQL classes. Because there is no field ‘uri’ (cf. the ‘_id’ field that is assigned to every type in HyperGraphQL), it is therefore difficult to get the URI of a queried type.
The same first query from Section 3.1 (Fig. 3) can be written in GraphQL-LD as depicted in Listing 1.4. This can be queried against any SPARQL endpoint, after conversion by the GraphQL-to-SPARQL module. This yields the SPARQL query that is shown in Listing 1.5. { " InternalDocument " :
" ht tp : / /www. i s o i c d d . org / [ . . . ] / C o n t a i n e r#InternalDocument " , " f i l e t y p e " : " http : / /www. i s o i c d d . org / [ . . . ] / C o n t a i n e r#f i l e t y p e " , " f i l e n a m e " : " http : / /www. i s o i c d d . org / [ . . . ] / C o n t a i n e r#f i l e n a m e " , "a " : " http : / /www. w3 . org /1999/02/22 r d f syntax ns#type " }
Listing 1.3. JSON-LD context for querying with GraphQL-LD { }
Listing 1.5. SPARQL translation of GraphQL query no. 1 Listing 1.6 shows the second query (Fig. 4), which is translated into SPARQL in Listing 1.7. Note that, in this SPARQL translation, only the document and the id were included as variables. A workaround for this could be to simply query for all variables, by either replacing them with an asterisk manually or by means of a code snippet. To avoid having identical variables, a concatenation takes place to join the variable name with the previous ‘branches’ in the GraphQL query. A naming of the fields is not required, but can be added for more clarity. { a (_: Link ) { l i n k E l e m e n t : hasLinkElement { document : hasDocument i d U r i : h a s I d e n t i f i e r {
i d : i d e n t i f i e r SELECT ? linkElement_document ? linkElement_idUri_id WHERE { ? b1 r d f : type l s : Link ;
l s : hasLinkElement ? l i n k E l e m e n t . ? l i n k E l e m e n t l s : hasDocument ? linkElement_document ;
l s : h a s I d e n t i f i e r ? l i n k E l e m e n t _ i d U r i . ? l i n k E l e m e n t _ i d U r i l s : i d e n t i f i e r ? linkElement_idUri_id .
Listing 1.7. SPARQL translation of GraphQL query no. 2 3.3
Finally, the ICDD container is queried using SPARQL. Here, the two queries can be combined into one (1.8). However, in this case the container only has one ct:ContainerDescription, which is why this variable is somewhat obsolete and therefore not listed in the results. Furthermore, the query searches for the links, the name and extension of the documents they refer to and the identifiers at sub-document level. PREFIX c t : <http : / /www. i s o i c d d . org / p a r t 1 /2019/ C o n t a i n e r#> PREFIX l s : <ht tp : / /www. i s o i c d d . org / p a r t 1 /2019/ L i n k s e t#> SELECT ? l i n k ?name ? type ? i d WHERE { ? i n d e x a c t : C o n t a i n e r D e s c r i p t i o n ;
c t : containsDocument ? doc . ? doc c t : f i l e n a m e ?name ;
c t : f i l e t y p e ? type . ? l i n k a l s : Link ;
l s : hasLinkElement ? LinkElement . ? LinkElement l s : hasDocument ? doc ;
l s : h a s I d e n t i f i e r ? id_guid .
? id_guid l s : i d e n t i f i e r ? i d . }
Listing 1.8. SPARQL translation of GraphQL query no. 2 As was the case in section 3.2, this query can be performed against all SPARQL endpoints, which makes it possible to enable reasoning engines. The results are depicted in Table 2. Three links are present in this ICDD container, two of which connect the IDs within two documents, one of them relates to three IDs. In this paper, three query syntaxes were discussed to retrieve data from an RDF dataset. The first two rely on the GraphQL syntax, but extend it towards linked data. While HyperGraphQL uses a schema that is fully compliant with the GraphQL specifications, GraphQL-LD translates the syntax of a GraphQL query into SPARQL ‘under-the-hood’. Another way for easily querying Linked Data, LDflex, was not included in the discussion because of its dependency on Javascript.
ICDD presents an interesting way of interlinking document-based information with RDF information, providing a way to use RDF to semantically annotate information that is nevertheless stored in a non-Linked Data way. ICDD datasets have a clear structure and are not overly complex, making them suitable to serve as use cases for testing the abovementioned query syntaxes. As ICDD is intended for use within the industry, being able to query it in a simple manner could certainly lower the threshold for developers to use Linked Data in their applications.
It is clear that SPARQL is the most expressive of these three languages.
SPARQL also inherently uses context, while for the other two, a context needs
to be provided. This makes it difficult to include external data sets on the web,
because the statements used in such datasets might not be explicitly available in
the context used for querying. However, for simple queries on a known dataset
(such as an ICDD container), GraphQL-based queries find their worthiness in
the fact that they hide the verbosity of SPARQL behind the elegant and concise
syntax of GraphQL. When a fixed dataset is present, such as an ICDD container
that contains only internal documents, HyperGraphQL offers a clean way of
querying, also due to its ‘introspection’ feature that helps querying the correct
schema definitions. On the other hand, as indicated in [
The authors would like to acknowledge the support by both the Special Research Fund (BOF) from Ghent University and the BIM4REN project, which has received funding from the European Union’s Horizon 2020 Research and Innovation Program under grant agreement No 820773.