Supported operations per hydra:Class instance

Greetings,

I will use the Hydra Console demo application (the Issue tracker) to describe my concern.

Here you can view an instance of the Issue class: http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/api-demo/issues/2#

If you click on the comments IRI, the dialog is knowledgable about the GET and POST operations. This is because “comments” is a hydra:Link instance; per instance of hydra:Link you may specify the supported operations on the associated IRI, and the demo application has done so.

Now GET the comments: http://www.markus-lanthaler.com/hydra/console/?url=http://www.markus-lanthaler.com/hydra/api-demo/issues/2/comments/#

On this screen we no longer know the supported operations on the comments. This is because the entity is an instance of the hydra:Collection class, and that class does not specify any supported operations (because there are no operations it can presume). It seems puzzling that, unlike the hydra:Link type, you cannot specify the supported operations per instance of a hydra:Class (noting that hydra:Collection is a subtype of hydra:Class). This means that supported operations are tied to class definitions, rather than instances, and thus the only solution here is to subtype hydra:Collection merely to define supported operations.

Imagine that you were listing blog posts on a website with multiple authors, and only the author of a particular post was able to edit that post. In that scenario it is not possible to model the supported operations because the granularity must be per instance of the (hypothetical) Post class.

Thanks for your comments,
Eric