Handling ambiguous operations
@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?
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
This is still relevant with kopflos' resource shapes