DOCSLIB.ORG

RDF Triplestores and SPARQL Endpoints

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

RDF triplestores and SPARQL endpoints Lecturer: Mathias Bonduel [email protected] LDAC summer school 2019 – Lisbon, Portugal Lecture outline • Storing RDF data: RDF triplestores o Available methods to store RDF data o RDF triplestores o Triplestore applications – databases – default graph – named graphs o List of triplestore applications o Comparing triplestores o Relevant triplestore settings o Communication with triplestores • Distributing RDF data: SPARQL endpoints o Available methods to distribute RDF data o SPARQL endpoints o Reuse of SPARQL queries o SPARQL communication protocol: requests and responses June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 2 Storing RDF data June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 3 Available methods to store RDF data • In-memory storage (local RAM) o Working memory of application (e.g. client side web app, desktop app) o Frameworks/libraries: RDFLib (Python), rdflib.js (JavaScript), N3 (JavaScript), rdfstore-js (JavaScript), Jena (Java), RDF4J (Java), dotNetRDF (.NET), etc. o Varied support for SPARQL querying • Persistent storage (storage drive) o RDF file/dump (diff. RDF serializations): TTL, RDF/XML, N-Quads, JSON-LD, N-triples, TriG, N3, TriX, RDFa (RDF embedded in HTML), etc. o RDF triplestore o (ontology editing applications: Protégé, Topbraid Composer, etc.) June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 4 RDF triplestores “a database to store and query RDF triples” • Member of the family of graph/NoSQL databases • Data structure: RDF • Main query language: SPARQL standards • Oftentimes support for RDFS/OWL/rules reasoning • Data storage is typically persistent June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 5 Triplestore applications – databases - default graph - named graphs • An RDF triplestore instance (application) can have one or multiple databases (repositories) • Each database has one default graph and zero or more named graphs o a good practice is to place TBox in a separate named graph. Most triplestores’ reasoning engines consider all TBox statements in the database o You can also use the TBox without reasoning => query directly June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 6 Instance of an RDF triplestore application (e.g. an Apache Jena Fuseki instance) Named graph 1 Default graph Default graph Named graph n Named graph 2 Database 1 Database 2 Database m June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 7 List of triplestore applications • Apache Jena: o TDB o Fuseki • Blazegraph DB • Stardog • Strabon • Apache Marmotta/KiWi • Ontotext GraphDB (former OWLIM) • Openlink Virtuoso • Cambridge Semantics AnzoGraph • Amazon Neptune • Franz AllegroGraph • BBN Parliament • ClioPatria • ... June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 8 List of triplestore applications • Apache Jena Fuseki • Stardog • Ontotext GraphDB • BBN Parliament June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 9 Comparing triplestores (1/4) • Hardware sizing: recommended RAM, disk space, etc. • Efficiency (speed and memory usage) o RDF loading/import efficiency o Querying efficiency o Reasoning efficiency • License options o open source/proprietary o free/educational/commercial • Security: SSH, access roles June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 10 Comparing triplestores (2/4) • API programming language support • SPARQL 1.1 support + SPARQL extensions (spatial, temporal, PATHS, etc.) • Reasoning: support for RDFS, OWL flavors, rule languages, SHACL • Validity/conformity check of input data • Documentation (or the lack of it) • (Commercial) support • Extras: o GraphQL, support for Apache TinkerPop API (e.g. Gremlin), etc. o plug-and-play cloud database o full-text search, machine learning o virtual graphs June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 11 Disclaimer: no liability regarding Comparing triplestores (3/4) completeness and correctness Name GeoSPARQL Multiple repositories Named Supported reasoning Licensing options Bulk triplestore querying per DB instance graphs schemes loading Apache Jena No* Yes Yes RDFS/OWL rule Open source (Apache Yes Fuseki engines** License v2.0) Stardog Yes Yes Yes RDFS, OWL DL/QL/RL, Proprietary: Enterprise Yes SL (includes SWRL), licenses (60 day trial), SHACL free academic license Ontotext No*** Yes Yes RDFS, OWL QL/RL, Proprietary: Enterprise Yes GraphDB custom rulesets license (60 day trial), standard license (60 day trial), free license BBN Yes No Yes Selection of RDFS and Open source (BSD) Yes Parliament OWL rules (config), SWRL * Limited custom geospatial queries possible over WGS84 and GeoSPARQL WKT data (newest versions might include GeoSPARQL querying) ** Jena modules can be connected for extensions: http://jena.apache.org/documentation/inference/ *** Limited custom geospatial queries possible over WGS84 data (GraphDB functions) June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 12 Disclaimer: no liability regarding Comparing triplestores (3/4) completeness and correctness Name Support Programming Extras: rule languages, validity check, built-in security triplestore interface Apache Jena (Public Java (Jena) Support for rules, authentication (Apache Shiro), extensions via Jena Fuseki mailinglist) (advanced reasoning, geospatial querying, full text search, etc.) Stardog Commercial Java (SNARL Validation (SHACL/ICV), rules (SWRL and Stardog Rules), PATHS queries, support, (native API), virtual graphs (RDBMS, CSV/JSON/XML, MongoDB, Cosmos DB, Stardog forum Sesame, RDF4J, Cassandra, etc. using R2RML or Stardog mapping syntax), GraphQL, Jena) property graph model (Tinkerpop), built-in authentication, full-text search, NLP, query/reasoning(inconsistency/inference)/validation explanations, machine learning functions Ontotext Commercial Java (RDF4J, Jena) Validity check, separate plug and play cloud database, full-text search, GraphDB support, RDFRank (interconnectedness), built-in authentication, custom email, Stack GraphDB Rules, query explanations Overflow BBN (Github) Java, C++ Support for SWRL rules, temporal indexing Parliament June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 13 Relevant triplestore configuration settings (1/2) • SPARQL endpoint host and port • Query timeout RAM • Heap size JVM Heap Off-Heap OS • Security and authorisation o Connection methods to HTTP server: enable/require SSL encryption o users: name and password o roles connected to users o rights for user/role: read/write RDF content, create/delete databases, adjust settings/users, grant/revoke permissions • Treatment of literals: strict parsing, canonicalization Settings with potential impact on loading/querying efficiency June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 14 Relevant triplestore configuration settings (1/2) • Indexing: regular, geospatial, temporal, text (literals) • Query scope: default graph, union of all named graphs, union of all named graphs and default graph • Active reasoning profiles: RDFS, OWL RL, OWL QL, etc. • Active rule engines • Enable spatial querying, reasoning, etc. • ... Settings with potential impact on loading/querying efficiency June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 15 Communication with triplestores • SPARQL over HTTP request: SPARQL protocol (code, cURL, Postman, etc.): o SPARQL endpoint URL: read update o Options: query, authentication, inference, input/output format o standardized • Native API of triplestore (own code, commandline): o Bulk loading RDF files o Management of databases: (all/active) databases, start, stop, drop, settings, roles, etc. o Direct queries • Web/desktop client: o Triplestore specific client: via SPARQL protocol or native API o Generic client: via SPARQL protocol June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 16 Links to installation guidelines • Apache Jena Fuseki: o Visual interface: Fuseki web app on localhost:3030 (comes with triplestore) o Triplestore: all OS • Stardog: o Visual interface: Stardog Studio (and web app) o Triplestore: Linux and Mac OS / Docker / Windows • GraphDB: o Visual interface: GraphDB workbench web app on localhost:7200 (comes with triplestore) o Triplestore: Linux / Mac OS / Windows • Parliament: o Visual interface: Parliament web app on localhost:8089/parliament (comes with triplestore) o Triplestore: all OS (download from Github repository, old website is depreciated) June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 17 Distributing RDF data June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 18 Available methods to distribute RDF data • SPARQL endpoint • Triple Pattern Fragment in-memory RDF store server endpoint (local access only) • RDF files: o dump file o subject page o RDF embedded in HTML (i.e. RDFa) Source: http://linkeddatafragments.org/concept/ June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 19 SPARQL endpoint (1/4) “An entry point for HTTP access to shared RDF data using SPARQL as a query language” ( standardized SPARQL communication protocol) June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias Bonduel 20 SPARQL endpoint (2/4) Triplestores RDF files HTTP request with SPARQL query RDBMS NoSQL HTTP response Virtual Client Server graphs XML files JSON files CSV files Triple Pattern Fragment Servers June 18, 2019 RDF triplestores and SPARQL endpoints | Mathias
Recommended publications
  • Including Co-Referent Uris in a SPARQL Query

    Including Co-Referent Uris in a SPARQL Query

    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Heriot Watt Pure Including Co-referent URIs in a SPARQL Query Christian Y A Brenninkmeijer1, Carole Goble1, Alasdair J G Gray1, Paul Groth2, Antonis Loizou2, and Steve Pettifer1 1 School of Computer Science, University of Manchester, UK. 2 Department of Computer Science, VU University of Amsterdam, The Netherlands. Abstract. Linked data relies on instance level links between potentially differing representations of concepts in multiple datasets. However, in large complex domains, such as pharmacology, the inter-relationship of data instances needs to consider the context (e.g. task, role) of the user and the assumptions they want to apply to the data. Such context is not taken into account in most linked data integration procedures. In this paper we argue that dataset links should be stored in a stand-off fashion, thus enabling different assumptions to be applied to the data links during query execution. We present the infrastructure developed for the Open PHACTS Discovery Platform to enable this and show through evaluation that the incurred performance cost is below the threshold of user perception. 1 Introduction A key mechanism of linked data is the use of equality links between resources across different datasets. However, the semantics of such links are often not triv- ial: as Halpin et al. have shown sameAs, is not always sameAs [12]; and equality is often context- and even task-specific, especially in complex domains. For ex- ample, consider the drug \Gleevec". A search over different chemical databases return records about two different chemical compounds { \Imatinib" and \Ima- tinib Mesylate" { which differ in chemical weight and other characteristics.
  • Mapping Spatiotemporal Data to RDF: a SPARQL Endpoint for Brussels

    Mapping Spatiotemporal Data to RDF: a SPARQL Endpoint for Brussels

    International Journal of Geo-Information Article Mapping Spatiotemporal Data to RDF: A SPARQL Endpoint for Brussels Alejandro Vaisman 1, * and Kevin Chentout 2 1 Instituto Tecnológico de Buenos Aires, Buenos Aires 1424, Argentina 2 Sopra Banking Software, Avenue de Tevuren 226, B-1150 Brussels, Belgium * Correspondence: [email protected]; Tel.: +54-11-3457-4864 Received: 20 June 2019; Accepted: 7 August 2019; Published: 10 August 2019 Abstract: This paper describes how a platform for publishing and querying linked open data for the Brussels Capital region in Belgium is built. Data are provided as relational tables or XML documents and are mapped into the RDF data model using R2RML, a standard language that allows defining customized mappings from relational databases to RDF datasets. In this work, data are spatiotemporal in nature; therefore, R2RML must be adapted to allow producing spatiotemporal Linked Open Data.Data generated in this way are used to populate a SPARQL endpoint, where queries are submitted and the result can be displayed on a map. This endpoint is implemented using Strabon, a spatiotemporal RDF triple store built by extending the RDF store Sesame. The first part of the paper describes how R2RML is adapted to allow producing spatial RDF data and to support XML data sources. These techniques are then used to map data about cultural events and public transport in Brussels into RDF. Spatial data are stored in the form of stRDF triples, the format required by Strabon. In addition, the endpoint is enriched with external data obtained from the Linked Open Data Cloud, from sites like DBpedia, Geonames, and LinkedGeoData, to provide context for analysis.
  • Versioning Linked Datasets

    Versioning Linked Datasets

    Master’s Thesis Versioning Linked Datasets Towards Preserving History on the Semantic Web Author Paul Meinhardt 744393 July 13, 2015 Supervisors Magnus Knuth and Dr. Harald Sack Semantic Technologies Research Group Internet Technologies and Systems Chair Abstract Linked data provides methods for publishing and connecting structured data on the web using standard protocols and formats, namely HTTP, URIs, and RDF. Much like on the web of documents, linked data resources continuously evolve over time, but for the most part only their most recent state is accessible. In or- der to investigate the evolution of linked datasets and understand the impact of changes on the web of data it is necessary to make prior versions of such re- sources available. The lack of a common “self-service” versioning platform in the linked data community makes it more difficult for dataset maintainers to preserve past states of their data themselves. By implementing such a platform which also provides a consistent interface to historic information, dataset main- tainers can more easily start versioning their datasets while application develop- ers and researchers instantly have the possibility of working with the additional temporal data without laboriously collecting it on their own. This thesis, researches the possibility of creating a linked data versioning plat- form. It describes a basic model view for linked datasets, their evolution and presents a service approach to preserving the history of arbitrary linked datasets over time. Zusammenfassung Linked Data beschreibt Methoden für die Veröffentlichung und Verknüpfung strukturierter Daten im Web mithilfe standardisierter Protokolle und Formate, nämlich HTTP, URIs und RDF. Ähnlich wie andere Dokumente im World Wide Web, verändern sich auch Linked-Data-Resourcen stetig mit der Zeit.
  • A Comparative Evaluation of Geospatial Semantic Web Frameworks for Cultural Heritage

    A Comparative Evaluation of Geospatial Semantic Web Frameworks for Cultural Heritage

    heritage Article A Comparative Evaluation of Geospatial Semantic Web Frameworks for Cultural Heritage Ikrom Nishanbaev 1,* , Erik Champion 1,2,3 and David A. McMeekin 4,5 1 School of Media, Creative Arts, and Social Inquiry, Curtin University, Perth, WA 6845, Australia; [email protected] 2 Honorary Research Professor, CDHR, Sir Roland Wilson Building, 120 McCoy Circuit, Acton 2601, Australia 3 Honorary Research Fellow, School of Social Sciences, FABLE, University of Western Australia, 35 Stirling Highway, Perth, WA 6907, Australia 4 School of Earth and Planetary Sciences, Curtin University, Perth, WA 6845, Australia; [email protected] 5 School of Electrical Engineering, Computing and Mathematical Sciences, Curtin University, Perth, WA 6845, Australia * Correspondence: [email protected] Received: 14 July 2020; Accepted: 4 August 2020; Published: 12 August 2020 Abstract: Recently, many Resource Description Framework (RDF) data generation tools have been developed to convert geospatial and non-geospatial data into RDF data. Furthermore, there are several interlinking frameworks that find semantically equivalent geospatial resources in related RDF data sources. However, many existing Linked Open Data sources are currently sparsely interlinked. Also, many RDF generation and interlinking frameworks require a solid knowledge of Semantic Web and Geospatial Semantic Web concepts to successfully deploy them. This article comparatively evaluates features and functionality of the current state-of-the-art geospatial RDF generation tools and interlinking frameworks. This evaluation is specifically performed for cultural heritage researchers and professionals who have limited expertise in computer programming. Hence, a set of criteria has been defined to facilitate the selection of tools and frameworks.
  • V a Lida T in G R D F Da

    V a Lida T in G R D F Da

    Series ISSN: 2160-4711 LABRA GAYO • ET AL GAYO LABRA Series Editors: Ying Ding, Indiana University Paul Groth, Elsevier Labs Validating RDF Data Jose Emilio Labra Gayo, University of Oviedo Eric Prud’hommeaux, W3C/MIT and Micelio Iovka Boneva, University of Lille Dimitris Kontokostas, University of Leipzig VALIDATING RDF DATA This book describes two technologies for RDF validation: Shape Expressions (ShEx) and Shapes Constraint Language (SHACL), the rationales for their designs, a comparison of the two, and some example applications. RDF and Linked Data have broad applicability across many fields, from aircraft manufacturing to zoology. Requirements for detecting bad data differ across communities, fields, and tasks, but nearly all involve some form of data validation. This book introduces data validation and describes its practical use in day-to-day data exchange. The Semantic Web offers a bold, new take on how to organize, distribute, index, and share data. Using Web addresses (URIs) as identifiers for data elements enables the construction of distributed databases on a global scale. Like the Web, the Semantic Web is heralded as an information revolution, and also like the Web, it is encumbered by data quality issues. The quality of Semantic Web data is compromised by the lack of resources for data curation, for maintenance, and for developing globally applicable data models. At the enterprise scale, these problems have conventional solutions. Master data management provides an enterprise-wide vocabulary, while constraint languages capture and enforce data structures. Filling a need long recognized by Semantic Web users, shapes languages provide models and vocabularies for expressing such structural constraints.
  • Ontotext Platform Documentation Release 3.4 Ontotext

    Ontotext Platform Documentation Release 3.4 Ontotext

    Ontotext Platform Documentation Release 3.4 Ontotext Apr 16, 2021 CONTENTS 1 Overview 1 1.1 30,000ft ................................................ 2 1.2 Layered View ............................................ 2 1.2.1 Application Layer ...................................... 3 1.2.1.1 Ontotext Platform Workbench .......................... 3 1.2.1.2 GraphDB Workbench ............................... 4 1.2.2 Service Layer ........................................ 5 1.2.2.1 Semantic Objects (GraphQL) ........................... 5 1.2.2.2 GraphQL Federation (Apollo GraphQL Federation) ............... 5 1.2.2.3 Text Analytics Service ............................... 6 1.2.2.4 Annotation Service ................................ 7 1.2.3 Data Layer ......................................... 7 1.2.3.1 Graph Database (GraphDB) ........................... 7 1.2.3.2 Semantic Object Schema Storage (MongoDB) ................. 7 1.2.3.3 Semantic Objects for MongoDB ......................... 8 1.2.3.4 Semantic Object for Elasticsearch ........................ 8 1.2.4 Authentication and Authorization ............................. 8 1.2.4.1 FusionAuth ..................................... 8 1.2.4.2 Semantic Objects RBAC ............................. 9 1.2.5 Kubernetes ......................................... 9 1.2.5.1 Ingress and GW .................................. 9 1.2.6 Operation Layer ....................................... 10 1.2.6.1 Health Checking .................................. 10 1.2.6.2 Telegraf ....................................... 10
  • Design and Analysis of a Query Processor for Brick

    Design and Analysis of a Query Processor for Brick

    Design and Analysis of a Query Processor for Brick Gabe Fierro David E. Culler UC Berkeley UC Berkeley [email protected] [email protected] ABSTRACT to increase energy efficiency and comfort, as well as provide mon- Brick is a recently proposed metadata schema and ontology for de- itoring and fault diagnosis. While many such applications exist, scribing building components and the relationships between them. the lack of a common description scheme, i.e. metadata, limits the It represents buildings as directed labeled graphs using the RDF portability of these applications across the heterogeneous building data model. Using the SPARQL query language, building-agnostic stock. applications query a Brick graph to discover the set of resources While several efforts address the heterogeneity of building meta- and relationships they require to operate. Latency-sensitive ap- data, these generally fail to capture the relationships and entities plications, such as user interfaces, demand response and model- that are required by real-world applications [8]. This set of re- predictive control, require fast queries — conventionally less than quirements drove the development of Brick [6], a recently proposed 100ms. metadata standard for describing the set of entities and relationships We benchmark a set of popular open-source and commercial within a building. Brick succeeds along three metrics: completeness SPARQL databases against three real Brick models using seven (captures 98% of building management system data points across six application queries and find that none of them meet this perfor- real buildings), expressiveness (can capture all important relation- mance target. This lack of performance can be attributed to design ships) and usability (represents this information in an easy-to-use decisions that optimize for queries over large graphs consisting manner).
  • Semantics Developer's Guide

    Semantics Developer's Guide

    MarkLogic Server Semantic Graph Developer’s Guide 2 MarkLogic 10 May, 2019 Last Revised: 10.0-8, October, 2021 Copyright © 2021 MarkLogic Corporation. All rights reserved. MarkLogic Server MarkLogic 10—May, 2019 Semantic Graph Developer’s Guide—Page 2 MarkLogic Server Table of Contents Table of Contents Semantic Graph Developer’s Guide 1.0 Introduction to Semantic Graphs in MarkLogic ..........................................11 1.1 Terminology ..........................................................................................................12 1.2 Linked Open Data .................................................................................................13 1.3 RDF Implementation in MarkLogic .....................................................................14 1.3.1 Using RDF in MarkLogic .........................................................................15 1.3.1.1 Storing RDF Triples in MarkLogic ...........................................17 1.3.1.2 Querying Triples .......................................................................18 1.3.2 RDF Data Model .......................................................................................20 1.3.3 Blank Node Identifiers ..............................................................................21 1.3.4 RDF Datatypes ..........................................................................................21 1.3.5 IRIs and Prefixes .......................................................................................22 1.3.5.1 IRIs ............................................................................................22
  • Data Platforms Map from 451 Research

    Data Platforms Map from 451 Research

    1 2 3 4 5 6 Azure AgilData Cloudera Distribu2on HDInsight Metascale of Apache Kaa MapR Streams MapR Hortonworks Towards Teradata Listener Doopex Apache Spark Strao enterprise search Apache Solr Google Cloud Confluent/Apache Kaa Al2scale Qubole AWS IBM Azure DataTorrent/Apache Apex PipelineDB Dataproc BigInsights Apache Lucene Apache Samza EMR Data Lake IBM Analy2cs for Apache Spark Oracle Stream Explorer Teradata Cloud Databricks A Towards SRCH2 So\ware AG for Hadoop Oracle Big Data Cloud A E-discovery TIBCO StreamBase Cloudera Elas2csearch SQLStream Data Elas2c Found Apache S4 Apache Storm Rackspace Non-relaonal Oracle Big Data Appliance ObjectRocket for IBM InfoSphere Streams xPlenty Apache Hadoop HP IDOL Elas2csearch Google Azure Stream Analy2cs Data Ar2sans Apache Flink Azure Cloud EsgnDB/ zone Platforms Oracle Dataflow Endeca Server Search AWS Apache Apache IBM Ac2an Treasure Avio Kinesis LeanXcale Trafodion Splice Machine MammothDB Drill Presto Big SQL Vortex Data SciDB HPCC AsterixDB IBM InfoSphere Towards LucidWorks Starcounter SQLite Apache Teradata Map Data Explorer Firebird Apache Apache JethroData Pivotal HD/ Apache Cazena CitusDB SIEM Big Data Tajo Hive Impala Apache HAWQ Kudu Aster Loggly Ac2an Ingres Sumo Cloudera SAP Sybase ASE IBM PureData January 2016 Logic Search for Analy2cs/dashDB Logentries SAP Sybase SQL Anywhere Key: B TIBCO Splunk Maana Rela%onal zone B LogLogic EnterpriseDB SQream General purpose Postgres-XL Microso\ Ry\ X15 So\ware Oracle IBM SAP SQL Server Oracle Teradata Specialist analy2c PostgreSQL Exadata
  • Domain Landscape Review and Data Value Chain Definition

    Domain Landscape Review and Data Value Chain Definition

    Ref. Ares(2018)2305100 - 30/04/2018 H2020 - INDUSTRIAL LEADERSHIP - Information and Communication Technologies (ICT) ICT-14-2016-2017: Big Data PPP: cross-sectorial and cross-lingual data integration and experimentation ICARUS: “Aviation-driven Data Value Chain for Diversified Global and Local Operations” D1.1 – Domain Landscape Review and Data Value Chain Definition Workpackage: WP1 – ICARUS Data Value Chain Elaboration Authors: University of Cyprus (UCY), Suite5, UBITECH, CINECA, AIA, PACE, ISI, CELLOCK, TXT, OAG Status: Final Classification: Public Date: 30/04/2018 Version: 1.00 Disclaimer: The ICARUS project is co-funded by the Horizon 2020 Programme of the European Union. The information and views set out in this publication are those of the author(s) and do not necessarily reflect the official opinion of the European Communities. Neither the European Union institutions and bodies nor any person acting on their behalf may be held responsible for the use which may be made of the information contained therein. © Copyright in this document remains vested with the ICARUS Partners. D1.1 - Domain Landscape Review and Data Value Chain Definition ICARUS Project Profile Grant Agreement No.: 780792 Acronym: ICARUS Aviation-driven Data Value Chain for Diversified Global and Local Title: Operations URL: http://www.icarus2020.aero Start Date: 01/01/2018 Duration: 36 months Partners UBITECH (UBITECH) Greece ENGINEERING - INGEGNERIA INFORMATICA SPA (ENG) Italy PACE Aerospace Engineering and Information Technology GmbH (PACE) Germany SUITE5 DATA
  • Qualifikationsprofil #10309

    Qualifikationsprofil #10309

    QUALIFIKATIONSPROFIL #10309 ALLGEMEINE DATEN Geburtsjahr: 1972 Ausbildung: Abitur Diplom, Informatik, (TU, Kaiserslautern) Fremdsprachen: Englisch, Französisch Spezialgebiete: Kubernetes KENNTNISSE Tools Active Directory Apache Application Case CATIA CVS Eclipse Exchange Framework GUI Innovator ITIL J2EE JMS LDAP Lotus Notes make MS Exchange MS Outlook MS-Exchange MS-Office MS-Visual Studio NetBeans OSGI RACF SAS sendmail Together Turbine UML VMWare .NET ADS ANT ASP ASP.NET Flash GEnie IDES Image Intellij IDEA IPC Jackson JBOSS Lex MS-Visio ODBC Oracle Application Server OWL PGP SPSS SQS TesserAct Tivoli Toolbook Total Transform Visio Weblogic WebSphere YACC Tätigkeiten Administration Analyse Beratung Design Dokumentation KI Konzeption Optimierung Support Vertrieb Sprachen Ajax Basic C C# C++ Cobol Delphi ETL Fortran Java JavaScript Natural Perl PHP PL/I PL-SQL Python SAL Smalltalk SQL ABAP Atlas Clips Delta FOCUS HTML Nomad Pascal SPL Spring TAL XML Detaillierte Komponenten AM BI FS-BA MDM PDM PM BW CO FI LO PP Datenbanken Approach IBM Microsoft Object Store Oracle Progress Sybase DMS ISAM JDBC mySQL DC/Netzwerke ATM DDS Gateway HBCI Hub Internet Intranet OpenSSL SSL VPN Asynchronous CISCO Router DNS DSL Firewall Gateways HTTP RFC Router Samba Sockets Switches Finance Business Intelligence Excel Konsolidierung Management Projektleiter Reporting Testing Wertpapiere Einkauf CAD Systeme CATIA V5 sonstige Hardware Digital HP PC Scanner Siemens Spark Teradata Bus FileNet NeXT SUN Switching Tools, Methoden Docker Go Kubernetes Rational RUP
  • Franz's Allegrograph 7.1 Accelerates Complex Reasoning Across

    Franz's Allegrograph 7.1 Accelerates Complex Reasoning Across

    Franz’s AllegroGraph 7.1 Accelerates Complex Reasoning Across Massive, Distributed Knowledge Graphs and Data Fabrics Distributed FedShard Queries Improved 10X. New SPARQL*, RDF* and SHACL Features Added. Lafayette, Calif., February 8, 2021 — Franz Inc., an early innovator in Artificial Intelligence (AI) and leading supplier of Graph Database technology for AI Knowledge Graph Solutions, today announced AllegroGraph 7.1, which provides optimizations for deeply complex queries across FedShard™ deployments – making complex reasoning up to 10X faster. AllegroGraph with FedShard offers a breakthrough solution that allows infinite data integration through a patented approach unifying all data and siloed knowledge into an Entity-Event Knowledge Graph solution for Enterprise scale analytics. AllegroGraph’s unique capabilities drive 360-degree insights and enable complex reasoning across enterprise-wide Knowledge Fabrics in Healthcare, Media, Smart Call Centers, Pharmaceuticals, Financial and much more. “The proliferation of Artificial Intelligence has resulted in the need for increasingly complex queries over more data,” said Dr. Jans Aasman, CEO of Franz Inc. “AllegroGraph 7.1 addresses two of the most daunting challenges in AI – continuous data integration and the ability to query across all the data. With this new version of AllegroGraph, organizations can create Data Fabrics underpinned by AI Knowledge Graphs that take advantage of the infinite data integration capabilities possible with our FedShard technology and the ability to query across