Scope of the term "graph"

[tpluscode]

You write about resources

# Defined by Hydra
* how resources can incorporate Hydra descriptions and/or controls
  * in particular, in which graph this should happen

Do you mean graph in RDF sense? If so, I think that we should be more agnostic. I recall people interested in describing APIs which are not-that-much-RDF so to speak...

[RubenVerborgh]

Do you mean graph in RDF sense?

I phrased the problem in RDF terms, but it actually translates translates more broadly to "should we mix the data and the controls"? For instance, looking at HAL, it's really easy to distinguish the controls from the data, as controls are in _link. With Hydra (JSON-LD or other), this might get more tricky.

One possible solution is different graphs (on the model level, but non-RDF-minded people don't need to know).

For a detailed discussion, see https://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/#graphs-let-us-combine-data-context-and-controls-neatly

[tpluscode]

Okay, this makes a lot of sense. I'm familiar with RDF and so immediately fished out graph. Not sure how non-RDF people would respond to that. On the other hand someone familiar with JSON-LD already could mistake it for @graph which is not how Hydra works for example.

Thus, I'd consider rephrasing that. I like the use of controls and data above. You think we can work with that?