The current implementation of the type system requires a predicate to specify the type of a node. It’s currently named simply “type” but a lot of users are already using this name and upgrading to 1.1 would involve migrating their data beforehand.
Other names have been suggested:
Opening this post for more discussion.
UPDATE: (03/22/19)
dgraph.type = 5 votes
node.label = 2 votes
How this would look like in the schema and mutation? the user has to type in the “type” for each node in the mutation?
update:
I see:
{
"set": [
{
"name": "Alice",
"type": "Employee"
},
{
"name": "Bob",
"type": "Employer"
}
]
}
+1 for dgraph.type
padding to reach 20 chars
In my opinion “type” is a good option it is much simpler. But to solve problems we should define solutions. Maybe modify the export to change the “type” that the user has (like a rename). Or maybe analyze if the Type that the user has can be adopted in the new Type System.
Opening it up to Dgraph community, so they can have a say.
+1 for dgraph.type
Slightly different opinion, but I feel like type generally refers to value types. I am not so much pro “label”, but personally like it better than “type”. Could be “node.label” too.
Another suggestion “node.type” 
node.type makes sense.
+1 for dgraph.type
I think type (and less likely node.type) are already used in production by many people. Renaming a field in a schema can be painful, as I’ve learned while migrating Gru.
Let me try to explain why I think dgraph.type is useful.
Clearly labels the predicate as something related to the database.
Sure, maybe a user wants to use dgraph.type for their own application. Well, the user owns the data but Dgraph owns the process and this clearly indicates look but dont touch. A fair agreement between parties. Using plain type is bound to mistakes and confusion.
Creates a namespace for any other future internal predicate names.
I think it will be easier to alias internal Dgraph to GraphQL vars with dgraph.* to __*. When we detect the user needs an internal value the transform can be linear. Also, the namespace makes the internal logic a lot simpler to follow.
Looks official and cool. 
Here’s how introspection is done in GraphQL:
https://graphql.org/learn/introspection/
In brief property named __type points to an object with possible fields name, kind, fields, ofType.
If we want to support GraphQL natively, for most definitions of “natively” we’d have to else use their approach or implement some kind of renaming.
We solved this with dgx by prefixing all attributes on a node. So for instance name would become user.name. dgx.Dogma does that automatically for us, as long the type instances pushed to Dgraph implement a special Method Prefix() string that provides that prefix.
+1 “dgraph.type”
I like namespaced keys as it makes it so obvious what value or kind of data is stored.
While transfering data from sql databases where DB or “db.” are often the package name or class prefix, I use “dg.” for refering dgraph data. So “dg.type” is maybe something to consider too, if you like that idea.
+1 “dgraph.type”
Sounds official and reserved internally for dgraph.
Since most people agreed on it, I have renamed the reserved predicate to “dgraph.type”.