Re: Collections with typed members

Well there might be a possibility that works under some cicumstances. The hydra:Collection has a manages block which contains the property that connects the members to a subject (in RDF triples where each member is an object). If that property has an rdfs:domain, then you are saying that the members are in that range, i.e. they are of that type. Note that this does not work by constraining the members, but by "making a promise" about the members.
It also works the other way around if your members are subjects in triples with a common object, if the property has an rdfs:domain.

However, that requires the client to apply some RDF reasoning and you can't expect all clients to do that. An alternative might be SHACL, once we decide to expect that from a compliant client.

Hydra has no official way to constrain the members.

It is also not possible to constrain possible request bodies (POST, PUT)  that are more complex than an object with flat members. That is for me the main pain point in hydra, because it doesn't allow me to express forms with possible values and pretty much prevents request bodies described in terms of schema.org with their nested types.
In Markus' priority list that would be "description of operations", and I hope we will get there soon. 

But my question is: what should a hydra-compliant client do with the information that the collection is typed?

Best,
Dietrich

Am 22.01.2016 09:34 schrieb Deian Tabakov <DTabakov@slb.com>:

Greetings hydraphils,

I have been studying Hydra on my own for the last few month. Finally, I hit
an issue that my search-fu cannot resolve.

Hydra supports Collections, but as far as I can tell, their members are not
described. For example (using Markus’ demo api) the /users request is
documented as “returns a Collection”. A client would not have apriori
knowledge about the types of elements in the collection. The type can only
be determined by consuming the collection and examining each element. 

The dual problem is when one wants to specify that a POST operation expects
as input a collection of vocab:User. Hydra can express that the expected
input is a Collection, but I cannot find a way to specify the expected type
of the members.

One solution might be to derive a sub class of hydra:Collection (say,
"TypedCollection") and explicitly specify the expected member type (say,
defining an "expectedMemberType" property). This would be informative (to a
human user of the API) but as far as I understand the theory behind, it
would not be normative. A standard JSON-LD parser would see
"expectedMemberType" as a property of "TypedCollection", and would not be
able to deduce the intended constraint on the types of the members.

Any hints how to do this?

Thanks,

Deian

--
Deian Tabakov
Software Engineer

Schlumberger (SIS)
Houston Technology Center
1-713-513-3768 
http://www.software.slb.com/products/foundation/Pages/pipesim.aspx