How to get the unique identifier of a thing in the graph?

Online I’m finding ways to get the automatically-generated unique identifier corresponding to an object – what I believe TypeDB calls, or at least used to call, an iid. For instance (according to a hodgepodge of personal notes and things I’ve seen online outside of this site),

match $o isa $t; get $o;

ought to return the iid for everything in the graph. But it’s not working for me. I keep getting this error:

com.vaticle.typeql.lang.common.exception.TypeQLException: [TQL04] TypeQL Error: The class 'TypeQLGet' cannot be casted to 'TypeQLFetch'.

That made it sound like I should try fetch instead, so I did, and got a different error:

[PRO03] Invalid projection operation: The variable projection 'n' cannot be used to fetch entity or relation instances. Entities and relations must be mapped to attributes.

Is there still a way to get the iid of a thing in the database? (In the meantime I’m just generating my own, which is easy enough, but inefficient and ugly.)

How are you issuing the queries? Studio / Console / Java driver?

The Python driver – which I believe means I’m using the Console grammar.

Can you post the line in your python driver that sends the query? ( to make sure you’re indeed calling transaction.query.get and not transaction.query.fetch
Also, what core/driver version please?

Oh, that was the trick! I had to change .fetch to .get.

I don’t really understand why those are different. Is that discussed anywhere? (It doesn’t seem to be the topic of any forum discussion, but it might be in the body of one.)

The docs should be your go-to for such things: TypeDB | Docs > Manual > Reading data

Thanks again, Krishnan.

I had read those pages, but hadn’t understood completely, and really I still don’t.

First of all, what is a concept? I found this stub in the glossary apparently waiting to be filled:

<I’m not allowed to post the link, but it’s what you find in the glossary if you search for “concept”.>

These two pages describe the idea:

https://typedb.com/docs/typeql/concepts/concept-variables
https://typedb.com/docs/typeql/concepts/overview

but I still don’t get it. Is a concept distinct from a concept variable? Are concepts a supercategory that includes values, but not vice-versa? Can values only occupy the universe of built-in atomic data types like float and string?

When I run a get or a fetch from the Python driver, in both cases I get JSON. But maybe the get is different because it can be used in a subquery to get a variable to which other subqueries refer, and you can’t refer to fetched values that way, only to gotten concepts (even though a value might be a concept, per my earlier confusion)?

I don’t mean to dump a lot of homework on you! I’m not actually sure I need the deeper understanding, now that I see how to run fetches and gets.

On a separate note – it seems like if the links are in the typedb domain (and maybe a few others like github) they shouldn’t count against a new user’s link limit, right? I’m apparently only allowed to post at most two links at a time.

Thanks again!

On the link limit:
Idk how easy or hard it its to configure domain-based exceptions. You can just wrap them in these and let the humans do the work of copy-pasting. We’d rather that than have spambots spamming links.

Can values only occupy the universe of built-in atomic data types like float and string?

Yes.

The right answer to your conceptual (sorry) questions will be found in the TypeQL paper & the video. But here’s one tl;dr view of things:

What are concepts?
A simplified view (and one that I use most of the time) is that types, things & values are all concepts, which occupy different spaces. Each ‘thing’ has a type. An attribute is a thing which also has a value.

You can see concepts as the vertices in the graph or as the ‘terms’ in a predicate-logic view. A get query should be returning a ConceptMap. These to me resemble a substitution in logic or the mapping that the ‘Graph Pattern Matching’ problem describes. Though there doesn’t seem to be a standard definition, it usually looks like [1]

A fetch seems less principled but easier to use in software applications where you likely already have to deal with data from API in JSON formats. It’s made under the assumption that the IDs of the vertices aren’t really interesting, but the attributes are. You can see fetch as a post-query step where you use a match find the concept you’re interested in, and then fetch its attributes.
The handy part is that it can return lists of attributes in a single result (& other arbitrarily nested structures), whereas get would have to return one result per item in a list.

[1] Given a graph G=(V,E,Lv: V -> Tv, Le: E -> Te), and a pattern graph P=(V', E', L'v: V' -> Tv, L'e: E' -> Te) , the results of the pattern matching of P on G is a set of mappings mapping Mi: V' -> V such that L'v(v) = Lv(Mi(v)) and L'e( (u,v) ) = Le( M(u), M(v))
V is the set of vertices, E is the set of edges - ordered pairs of vertices, Lv is a mapping of vertices to vertex-labels , Le is a mapping of edges to edge-labels.
Ofcourse, In TypeDB the labels are replaced by types, which are slightly more complicated, though the basic idea should remain the same.

The idea of a substitution in logic is similar. It’s a mapping from ‘variables’ to ‘terms’ which make a ‘formula’ true in a given ‘theory’ .