I found you! I’ve pin-pointed the issue. The funny thing is that neither my fixture nor the server-side generated code were wrong!

My client was sensitive for blank-node classes - in search for solid class definition which was supposed to be in a OWLs subClassOf chain it searched only for specific patterns. Unfortunately, for some cases server was sub-classing explicitely named classes, thus breaking my client’s logic.

The worst thing is that those cases are pretty legal from OWL point of view, yet parsing them is a real pain.

Consider a situation when an operation returns an instance of the Person class:

<api/people/{id} a hydra:Operation ;
	hydra:returns api:Person .

Another operation returns a collection of those instances of Person class:

<api/people> a hydra:Operation ;
	hydra:returns hydra:Collection .

In order to have a strongly-typed result description I’d need to do this:

<api/people> a hydra:Operation ;
	hydra:returns api:EnumerationOfPerson .

api:EnumerationOfPerson owl:subClassOf hydra:Collection ;
	owl:subClassOf [ a owl:Restriction; owl:onProperty hydra:member; owl:allValuesFrom api:Person ] .

Much better. But if I’d like to have i.e. an operation specific description of the returned type, I’d need to do this:

<api/people> a hydra:Operation ;
	hydra:returns [
		rdfs:comment "Returns collection of Person." ;
		owl:subClassOf api:EnumerationOfPerson ] .

api:EnumerationOfPerson owl:subClassOf hydra:Collection ;
	owl:subClassOf [ a owl:Restriction; owl:onProperty hydra:member; owl:allValuesFrom api:Person ] .

This means that the operation returns an anonymous class that is a sub-class of the api:EnumerationOfPerson, which is next a sub-class of a hydra:Collection and another anonymous class that restricts type of the collection members. While this is the least intrusive way of automatically generating OWL class descriptions, parsing it to build an actual view of a collection of people is a hell!

I’m gonna spend some time on this :(.