<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Hybrid Enterprise Knowledge Graphs</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Peter Haase</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>metaphacts GmbH</institution>
          ,
          <addr-line>Walldorf</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Knowledge graphs have emerged as a key technology to enable enterprise data management, serving as an integration hub across enterprise data source. In this talk we present Ephedra, a SPARQL federation engine aimed at supporting queries across hybrid knowledge graphs involving both native graph data as well as a range of other data sources, data modalities, and data processing techniques. We will present practical examples and experiences with hybrid enterprise knowledge graphs in real-world applications in various industries. 1 Knowledge graphs established a solid position in the enterprise world, serving as a central element in the organizational data management infrastructure. Knowledge graphs are becoming both the repository for organization-wide master data (ontological schema and static reference knowledge) as well as the integration hub for various legacy data sources: e.g., relational databases or data streams. Typically, a core knowledge graph is used to represent and materialise semantic descriptions of key entities and their relations in RDF, queryable via SPARQL, However, in many practical knowledge graph use cases there is a need to address hybrid information needs. Such needs can be characterized by the following dimensions: { Variety of data sources. There is often a need to integrate data stored in several physical repositories. These repositories can include both native RDF triple stores as well as datasets in other formats presented as RDF (e.g., a relational database exposed using R2RML mappings). { Variety of data modalities. Graph data in RDF often needs to be combined with other data modalities, e.g., textual, temporal or geospatial data. A SPARQL query then needs to support corresponding extensions for full-text, spatial, and other types of search. { Variety of data processing techniques. Retrieved data often has to be further processed using dedicated domain-speci c services: e.g., graph analytics ( nding the shortest path or interconnected graph cliques), statistical analysis and machine learning (applying a machine learning classi er, nding similar entities using a vector space model), etc. The main motivation for this work comes from our experience with the metaphactory knowledge graph management platform [1], which is used in a</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        variety of application domains (e.g., pharmaceutics, nancials, engineering and
manufacturing, and IoT). Typical application scenarios often require dealing
with a multitude of the above-listed dimensions simultaneously. To support this,
the metaphactory platform can connect to various di erent RDF stores as well as
non-RDF sources virtually integrated and exposed via a SPARQL interface. To
be able to interact with multiple data sources using virtual data integration, we
developed a SPARQL federation engine Ephedra [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]: In Ephedra, we adopt the
SPARQL 1.1 federation mechanism using the SERVICE keyword, but broaden
its usage to enable custom services to be integrated as data sources. In this way,
a complex information request requiring access to several data sources can be
expressed using a single query over a virtually integrated knowledge graph.
      </p>
      <p>Ephedra de nes a common implementation interface, in which interactions
with external services are encapsulated: A custom service can be registered in
the repository manager as yet another SPARQL repository and referenced inside
SERVICE clauses in SPARQL queries. SPARQL graph patterns speci ed inside
such SERVICE clauses are parsed to extract input parameters for a service call
as well as the variables to bind the results returned by the service. The Ephedra
SPARQL query execution strategy sends the sub-clauses of a query to
corresponding data sources, gathers partial results, combines them using union and
join operations, and produces result sets. Processing hybrid queries is
transparent and performed in the same way as ordinary SPARQL queries.</p>
      <p>In the talk, we will present examples of hybrid knowledge graphs in di erent
industries involving a range of data and compute services virtually integrated:
{ We will show how a core knowledge graph of physical devices (such as gas
turbines) acts as an integration backbone for heterogeneous data sources
including real-time sensor data. To be able to process relevant information in a
timely way and achieve intelligent diagnostics, knowledge graph data is
integrated with runtime information provided by relevant APIs on demand. The
Ephedra federation architecture enables combining the materialized
knowledge graph data with the data produced by the API services available.
{ In another example, we show how a knowledge graph containing master
data about products can be augmented with virtual relations that are not
explicitly known or asserted, but virtually integrated from a machine learning
algorithm, which provides relations such as similarity and returns as response
the classi cation results.
{ We will show examples that illustrate the power of Ephedra to e ectively
wrap data and compute services accessible via any REST API as a virtual
endpoint in a SPARQL federation.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Haase</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kozlov</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Herzig</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nikolov</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Trame</surname>
          </string-name>
          , J.:
          <article-title>metaphactory: A platform for knowledge graph management</article-title>
          .
          <source>Semantic Web Journal</source>
          (
          <year>2019</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Nikolov</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Haase</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Trame</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kozlov</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Ephedra: E ciently combining RDF data and services using SPARQL federation</article-title>
          .
          <source>In: Knowledge Engineering and Semantic Web</source>
          ,
          <string-name>
            <surname>KESW</surname>
          </string-name>
          <year>2017</year>
          , Szczecin,
          <string-name>
            <surname>Poland.</surname>
          </string-name>
          (
          <year>2017</year>
          )
          <volume>246</volume>
          {
          <fpage>262</fpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>