I don't believe so. The intention of the @odata.nextLink field is to provide a mechanism to page resource collections that contain more data than can reasonably be returned in a single response. For example a System Event Log with 2000 entries or something of that nature. (I pick SEL as an example because LogService entries are meant to be expanded into the collection instead of linked via @odata.id, therefore a lot more data is rendered).
What the implementation might do in that circumstance is limit the number of resources that it will return in a collection (to 10, for example) and only return 10 of the entries in the collection instead of all 2000.
The collection's Members@odata.count field should still report the full number of resources in that collection, so @odata.nextLink is used to indicate how to read the next 10 entries (as without providing that, accesses to the URI will only ever return the first 10 entries).
So for example:
A GET on /redfish/v1/Managers/0/LogServices/SEL/Entries might return
In the context of a non-collection resource (such as Thermal), payloads cannot make use of the @odata.nextLink annotation. In addition, the Redfish spec does not call out the @odata.navigationLink annotation, so making use of those in implementations is outside the scope of standard Redfish.
Back to your example Thermal payload, you will need to add the expanded Temperatures, Fans, and Redundancy arrays like this. I would also recommend removing the @odata.navigationLink terms since Redfish-centric clients will unlikely be able to use them.
mraineri: It is true that Redfish is silent on the use of OData capabilities that Redfish has not specified. Also, I agree with your response format since the referenced redfish schema does specify OData.AutoExpand for the Temperatures and Fans collections. So, the original question is correct w.r.t. OData syntax, but not correct for the referenced schema.