rdf has shacl and shex property graphs? no commonly …olafhartig.de/slides/slidesgrades2019.pdf1...

1Defining Property Graph Schemas by using the GraphQL Schema Definition LanguageOlaf Hartig, Jan Hidders

● Range of graph database use cases broadensand new application requirements emerge

● One such requirement: solutions tospecify rigid forms of logical schemas– What does a valid instance has to look like?– What constraints does it have to satisfy?

● RDF has SHACL and ShEx

● Property Graphs? No commonly agreed-upon approach


So what?

● GraphQL APIs are based on some form of schema● Specified in a developer-friendly language

Research Question:

Can the GraphQL Schema Definition Language berepurposed to also define schemas for Property Graphs?

Defining Property Graph Schemas by using the GraphQL Schema Definition Language

Olaf Hartiga, Jan Hidders b

(a) Dept. of Computer and Information Science, Linköping University, Sweden

(b) currently unaffiliated


Our Contributions

Approach to adopt the GraphQL SDLfor Property Graph schemas, incl.formal definition of the approach

Formalization of the notion of schemaas captured by the GraphQL SDL

Fundamental properties of the approach (validation problem is in AC0; checking satisfiabilityof schemas is NP-hard and in PSPACE)

GraphQL Schemas in a Nutshell


GraphQL Schemas in a Nutshell

declaration of an object type with its fields and their types

argument

declaration of an object type with its fields and their types

declaration ofan interface type and an implementation

declaration ofa union typedeclaration ofa union type

declaration of the query type

(possible root fields of queries)

Overview of the Approach


Specifying Types of Nodesusing Object Type Definitions

● Defines three types of nodes: nodes with the label User, nodes with the label Post, and nodes with the label Section– We assume only one label per node

Post

User

Usertype User { … }

type Post { … }

type Section { …}

Section

Section


type User { login: String! nicknames: [String!]!}

type Post { … }

type Section { …}

Specifying Node Propertiesusing Field Definitions that are based on scalar types

● User nodes may have two properties, login and nicknames

Post

User

login: "bob23"nicknames: ["Bobby", "Bob"]

User

login: "ali"

Section

Section


type User @key(fields:["login"]) { login: String! @required nicknames: [String!]!}

type Post { … }

type Section { …}

Constraints on Node Propertiesusing Directives

● User nodes may have two properties, login and nicknames● login property required● login property is a key (i.e., values must be unique)

Post

User


User

login: "ali"

Section

Section


Section

Section

Post

User

User

login: "ali"

author sec

sec


type Post { author: User! sec: [Section!]!}

type Section { …}

Specifying Types of Outgoing Edgesusing Field Definitions that are based on object types

● Post nodes may have an author edge pointing to a User node● Post nodes may have several sec edges to Section nodes




type Post { author: User! @required sec: [Section!]! @distinct @requiredForTarget}

type Section { …}

Constraints on Edge Typesusing Directives

● every Post node must have an (outgoing) author edge● all sec edges of a Post node must point to different Section nodes● every Section node must have at least one incoming sec edges

Section

Section

Post

User


User

login: "ali"

author sec

sec



type Post { author: User! sec: [Section!]! @distinct @requiredForTarget}

type Section { …}

Constraints on Edge Typesusing Directives (cont'd)

● @noloop: edges cannot connect a node with itself● @uniqueForTarget: nodes that are target of a given edge type can

have at most one incoming edge of this type

Section

Section

Post

User


User

login: "ali"

author sec

sec


Specifying Edges with Multiple Target Typesusing Unions

● Every Person node may have a favoriteVehicle edgepointing either to a Motorcycle node or to a Car node

Motor-cycle

Person

name: "Alice"

favoriteVehicle …

Car

Person

name: "Bob"

favoriteVehicle …

type Person { name: String! favoriteVehicle: Vehicle}

union Vehicle = Car | Motorcycle

type Motorcycle { … }

type Car { … }


Motor-cycle

Person

name: "Alice"

favoriteVehicle

type Person { name: String! favoriteVehicle: Vehicle}

interface Vehicle { … }

type Motorcycle implements Vehicle { … }

type Car implements Vehicle { … }

Specifying Edges with Multiple Target Typesusing Interfaces

● Every Person node may have a favoriteVehicle edgepointing either to a Motorcycle node or to a Car node

…

Car

Person

name: "Bob"

favoriteVehicle …


Author

name: "Bob"

influencedBy

Specifying Edge Propertiesusing Field Argument Definitions

● Every influencedBy edge (between Author nodes) may havea significance property with a floating point number as value

type Author { name: String! influencedBy(significance: Float): [Author!]!}

Author

name: "Alice"

significance: 0.8

Properties of the Approach


Schema Validation Problem

Definition: Given a Property Graph G anda GraphQL schema S,

does G strongly satisfy S?

Theorem*: Under the assumption that– the set of scalar types is fixed and finite, and– the problem of deciding if a given scalar value

is of a given scalar type is in AC0,

the computational complexity of theschema validation problem is in AC0.

*expressed more formally in the paper


Not all schemas are satisfiable

type OT1 {}

interface IT { hasOT1: OT1 @uniqueForTarget}

type OT2 implements IT { hasOT1: [OT1] @requiredForTarget}

type OT3 implements IT { hasOT1: [OT1] @requiredForTarget}

● Assume OT1 node n1

● n1 must have in-edge from an OT2 node n2

● n1 must have in-edge from an OT3 node n3

● n1 can have at most one such in-edge

● thus, n2 = n3,which contradicts that nodes can have only one label/type


Object-Type Satisfaction Problem

Definition: Given a GraphQL schema S andan object type ot in S,

is there a Property Graph that strongly satisfy Sand contains at least one node of type ot?

Theorem: The object-type satisfiability problem is NP-hard.

Theorem: The object-type satisfiability problem is in PSPACE.

Summary and Outlook


Our Contributions in a Nutshell

Approach to adopt the GraphQL SDLfor Property Graph schemas, incl.formal definition of the approach

Formalization of the notion of schemaas captured by the GraphQL SDL

Fundamental properties of the approach● validation problem is in AC0● checking satisfiability of schemas

is NP-hard and in PSPACE


Future Work

● Characterize the computational complexityof schema satisfiability more precisely

● Approach to generate a GraphQL API basedon an SDL-based Property Graph schema– Basis: the SDL-based Property Graph schema

must be extended into a GraphQL API schema


Our Other GraphQL-Related Research Work

● Semantics and Complexity of GraphQL– Evaluation problem is NL-complete (combined complexity)– Algorithm to compute result size in polynomial time

● An Empirical Analysis of GraphQL API Schemas– 2081 distinct schemas extracted from open code repos

● Linköping GraphQL Benchmark (LinGBM)– Ongoing work, see https://github.com/LiUGraphQL/LinGBM/ – Tests the performance of GraphQL server implementations– Designed based on the LDBC methodology– 16 “choke points” (technical challenges)– 16 query templates that cover the CPs– Synthetic datasets (RDB, RDF) of arbitrary size

www.liu.se

https://github.com/LiUGraphQL/LinGBM/

rdf has shacl and shex property graphs? no commonly …olafhartig.de/slides/slidesgrades2019.pdf1...

Documents