Can edges refer to parts of the schema?

In an RDF store, the “schema” is just a set of triples in the store itself, and you can make statements about the rdfs:Classes or rdfs:Properties (types or predicates in dgraph parlance) which you define.

However I haven’t yet found an equivalent mechanism to make statements about the type system in dgraph. The root of my question is “do types or predicates get uids?” i.e. can we add edges to/from them in the graph itself.

I’ll give a concrete example that I’m thinking about. Imagine that you have:

type Person {
  height: float

I’d like to be able to describe the distribution of heights (say normal with some mean/stddev) and then be able to randomly sample from that distribution to generate a realistic height on demand. The distribution would clearly be a property of the predicate, rather than any specific node or edge in the graph.

I can imagine a way to do this by building a shadow schema inside the store, and relating it to the actual schema using strings, but that feels brittle. Is such a thing possible or on the roadmap?


I do not think I understand the use case all so well, but you should be able to write your query without the need for shadow schema in such a way that you could still use the properties of schema in the query. May be, if you provide an example of a query that you want to run with the shadow schema, we can help you figure out how to do it without the shadow schema.

Otherwise, we do not store the schema in similar way as we store the data. The types on the other hand, are just stored with a predicate called <dgraph.type>. Hope that helps.

Thanks for the reply!

Another way to explain the use-case is as a D&D random character generator. For that narrow use-case, I could hard-code it, because I know that Characters have a Race and a Class, etc. up front. However, I’d like to generalize this feature into an arbitrary thing generator, where a thing could be a Character or a city or a weapon, etc.

Say I want to generate a random a random thing of <dgraph.type> “Foo”. I’d need to:

  1. Enumerate all the predicates for “Foo”.
  2. For each predicate find out what the “range” is (i.e. the scalar type or the <dgraph.type> of a uid predicate)
  3. If it’s a uid predicate, then it’s probably just a uniform choice among all the objects with that <dgraph.type> though some choices might be more common than others. If it’s not a uniform choice, I’d like to be able to express the relative odds of each choice.
  4. If it’s a scalar type, we’ll want some some description of the distribution of values to choose from. Even if it’s uniformly distributed, there will probably be limits like a narrower range of values, etc.

I know I can express all these things if types and predicates have uids, though I haven’t totally worked out what the schema schema would be yet. I’m also pretty sure I could express this in an RDF data store, but I was excited to try out dgraph because of the distributed nature and apparent scalability/performance benefits over those types of stores.