RE: Collections with typed members

Hi Dietrich,

 

“Manages” seems to be what I was looking for. If this is parsed as an RDF predicate on each member of the collection, then the client side has enough information how to use the API correctly. Enforcing correct usage is another story. At this point I would be content to return an error code if the client’s request is not in the proper form.

My intended usage is to indicate to the client that the input to a POST is a collection of things. To fulfill the request, I need to examine the color and the shape property of each item, which means that the client has to send me objects with both a color property and a shape property. Your suggestion gives me a way of documenting this.

 

Much appreciated!

 

Deian

 

--

Deian Tabakov
Software Engineer

 

From: Dietrich Schulten [mailto:ds@escalon.de] 
Sent: Friday, January 22, 2016 4:00 AM
To: Deian Tabakov <DTabakov@slb.com>
Cc: Hydra <public-hydra@w3.org>
Subject: 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__schema.org&d=CwQGaQ&c=uGuXJ43KPkPWEl2imVFDmZQlhQUET7pVRA2PDIOxgqw&r=7KTjK8y309yPsq2BIjS12g&m=i8luJH7MJCTOjiRSb7vykAHjVzOjuItJrbk6_SbHDDA&s=ajTedXmnnIWNEAil3JOIULkJC4UixZ1WrnVJshe7Xqc&e=>  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 <mailto: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