Correct, the ‘predicate’ itself is only allowable in the predicate position of the RDF (SPO). The subject of a dgraph RDF can only be a uid (usually a hex encoded integer).
You very well could make a node that represents and contains metadata about a predicate and access it as such:
with the understanding that mypredicate is used as a unique ID to identify nodes that contain metadata for your predicate (this is tracked completely separately to the lifecycle of the predicate as a storage medium)
updates can use that same id:
upsert{
query{
# get the uid of the mypredicate=="swedishURL" node, whatever it is.
pid as var(func: eq(mypredicate,"swedishURL"))
}
mutation{
set {
# use that uid collected above as the subject
uid(pid) <regexFormat> "my-regex" .
}
}
}
with the understanding that mypredicate is used as a unique ID to identify nodes that contain metadata for your predicate (this is tracked completely separately to the lifecycle of the predicate as a storage medium)
With that, it indeed seems reasonable to have a separate lifecycle; in a way a superset of metadata for the predicates used in DQL schema: