Handling ambiguous operations

[tpluscode]

@bergos I wonder if you have thoughts on processing requests which match more than one operation.

Specifically, a common case will be hydra:Collection vs hydra:Resource. If both of those base classes would support a GET operation, trying to dereference any collection would fail because of that ambiguity. That is inevitable if the store would use inferring, since hydra:Collection rdfs:subClassOf hydra:Resource

I kinda have this pattern in mind to make operation "overrides", so that one operation can explicitly be marked as having priority over another

<GetResource> a hydra:Operation .

# For collections, use this and not the one above
<GetCollection> a hydra:Operation ; hydra-box:overrides <GetResource>.

Is that something that would make sense to be a hydra-box feature?

[tpluscode]

On second thought, this could also be disambiguated based on class hierarchy.

Collection is a specialisation of Resource, so maybe it is only logical that conflicting operations would be resolved by the order, favouring child classes

[tpluscode]

This is still relevant with kopflos' resource shapes