A graph is a very generic data structure, so it should be possible to express the data of any application in the form of a graph. And this graph, formed by all application data, is what we call the graph in GraphQL.
With GraphQL we look at the overall set of data that is exposed by an API provider. All this data is exposed via a single endpoint. Compared to REST endpoints, the single GraphQL endpoint exposes a lot of data. This comprehensive set of data with its entities and relationships between the various entities forms the graph of GraphQL. To retrieve any data at all, one needs to navigate the graph.
When using other philosophies for building APIs, such as REST, we usually create several API endpoints and whatever is exposed by any single one of the API endpoints is typically not a generic graph, but rather a single entity or a list of entities. But there can be graph-like relationships across all API endpoints of an API provider. And this is in fact attempted by REST: resources are linked by URLs.
Both philosophies are capable of expressing application data in form of a graph, with GraphQL the graph is more explicit since it is served on a single endpoint.