Re: Collections with typed members

Hi all,

> 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.

If I understand everything correctly, as you said, currently a client
can only "guess" members of which classes from the supported ones
(i.e. defined in the api documentation as hydra:supportedClass) are in
a particular collection. And the client will have to use RDFS
reasoning for that.

To explicitly say members of which classes are in a particular
collection, one could use the VoID vocabulary [0]. In example:

</alice/friends> a hydra:Collection, void:Dataset ;
    void:classPartition [ void:class apidoc:Person ] .

and apidoc:Person is defined in the api documentation where a client
can find which properties and operations are supported by that
instances of this class.

Another use case is when one wants to describe members of which
classes are in a collection which is the range of a particular
hydra:Link. As I understand it was discussed already in [1]. I think,
in such case we can't use void:classPartition directly, because we do
not describe a particular collection (i.e. which is an instance of
void:Dataset and has an URI), but a class of collections which are
linked by this hydra:Link.

Option A: to describe such class of collections with object property
restrictions, which we'd say that the values of hydra:member property
of such collections are instances of particular classes. An example:

</alice> apidoc:friends </alice/friends> .

apidoc:friends a hydra:Link ;
    rdfs:range [
        a hydra:Collection ;
        rdfs:subClassOf [
            a owl:Restriction ;
            owl:onProperty :member ;
            owl:allValuesFrom apidoc:Person
        ]
    ] .

Option B: to use the SHACL vocabulary (they even have similar use case
[2], if I understood it correctly). The use of the SHACL is already
suggested in [3], but without examples for hydra:Link. An example for
hydra:Link:

</alice> apidoc:friends </alice/friends> .

apidoc:friends a hydra:Link ;
    rdfs:range [
        a hydra:Collection, sh:Shape ;
        sh:property [
            sh:predicate rdf:type ;
            sh:class apidoc:Person
        ]
    ] .

or Option B* (if you want to make focus on void:classPartition property):

apidoc:friends a hydra:Link ;
    rdfs:range [
        a hydra:Collection, sh:Shape ;
        sh:property [
            sh:predicate void:classPartition ;
            sh:valueShape [
                sh:predicate void:class ;
                sh:hasValue apidoc:Person
            ]
        ]
    ] .

[0]: https://www.w3.org/TR/void/
[1]: https://lists.w3.org/Archives/Public/public-hydra/2015Nov/0158.html
[2]: https://www.w3.org/TR/shacl-ucr/#uc17-specifing-subsets-of-data
[3]: https://www.w3.org/community/hydra/wiki/Integration_with_SHACL

Maxim

On Fri, Jan 22, 2016 at 11:33 PM, Deian Tabakov <DTabakov@slb.com> wrote:
> 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
>

Received on Monday, 8 February 2016 18:42:25 UTC