TypeDB Schema Introspection
And also this! We need to re-build the schema export functionality. I kind of want to to be available in TypeQL and a json-like structure (one of @christoph.dorn 's ideas!) which would be awesome IMO.
7 Replies
a json-like structure would be wonderful; would be easier to go from JSON -> define statement (and really, JSON -> anything) than going define -> JSON -> anything
that was our intuition / expectation, was that there would be a JSON-like representation available
I think this may also end up being very helpful for the SDKs / ORM layer
https://discord.com/channels/665254494820368395/983769458269114408/1352665818768609362
Definitely easier for us to make both versions instead of forcing you to parse the text version if JSONs are actually useful here
pulling in your message regarding TypeID - extending Anupam's example, it'd be great if
fetch and/or a JSON-like representation of data instances referenced a unique ID for the type
my understanding is that the name / label of a type can effectively be understood as a unique identifier for that type
though I imagine at some point in the future, it may make sense to have an additional unique identifier such that an entity could be renamed / migrated, and references to that entity would still hold
also, I'm still trying to get the right intuition around language here; when I say "entity" above, I'm referring to a reference to an entity type and not a data instanceSaying "entity type" would be more explicit and better for readers, and we, as devs, tend to use "entities" purely for instances. But I think that our users can mix it, and it's not too bad while you have some context around
Entity type -> type
Entity -> entity type instance -> instance
Well, it is reasonable since we continue pushing to expose iids. Something to think about
I believe that we haven't finished designing renaming and aliasing, and it can affect the decision
and ig this is tangential, but while we are talking on JSON representations - I was trying to push for a JSON-like representation of TypeQL
reason being, we can constrain LLMs to output JSON according to a schema, whereas we can't constrain an LLM to output valid TypeQL (at the token level, at least) - we can validate a generated TypeQL query string, but with a well-designed JSON representation we could constrain it much more strongly
my intuition was that this would make it much much easier to generate TypeQL
@actuallyepic thinks a bit differently and believes that reducing TypeQL to JSON would several limit its expressiveness / kill most of the benefit out of the gate
so I am just generally curious if there has been any work on other JSON-like representations specifically for TypeQL - I imagine the team has discussed and/or played around a bit here
I have been pretty succesfull creating valid schemas using Claude Sonnet 3.7 with extended thinking. I create a project and put all the TypeQL documentation as markdown and add instructions for it to check the documentation I added.
But I agree, I think it probably works better using JSON, as it has seen much more of it. But still no 100% guarantee.
Even JSON seems overkill. The schema is basically be a binary graph with "annotations" as labels. There's no nesting or anything complicated enough to bring in JSON
Even a TypeQL query is a pretty trivial graph. They're all typed binary edges, except for the links constraint, whose edge-type is parametrised by the role-type
What I meant was :
Can be written as
Surely this is easier than JSON. From a TCS perspective, you might even be able to parse it with just regex and no CFG.
I think the only nice thing about JSON is that it can be arbitrarily tree-shaped, and is plain-text.