Re: hydra:returns for operations returning collections of class instances

On Jun 19, 2014, at 3:20 AM, Jindřich Mynarz <mynarzjindrich@gmail.com> wrote:

> On Wed, Jun 18, 2014 at 11:47 PM, Markus Lanthaler
> <markus.lanthaler@gmx.net> wrote:
>>> Wouldn't this design lead to proliferation of "collection classes" for
>>> many popular classes? I can imagine that if this was recommended
>>> practice, then we could see several classes of collections of
>>> schema:Person or schema:Product etc.
>> 
>> I don't think so because those classes don't need to have a name (or identifier if you prefer). As you see above, you would just
> 
> If you used blank nodes for the collection classes, then you'd likely
> have to duplicate the class description. For example, the same
> collection class can be described in hydra:Operation's hydra:returns
> and in the representation of collection instance (as rdf:type).
> 
> 
>>> The description is in OWL (albeit in a simple subset) and there might
>>> be few clients and developers, who create these clients, that read
>>> OWL. If the main goal is to support a machine-readable API
>>> description, which is also readable to most web developers, and
>>> reasoning support isn't required, then OWL might not be the best way
>>> how to achieve this goal.
>> 
>> Fully agreed. If this feature turns out to be important, we can introduce a shortcut or something directly into Hydra.
> 
> It would be great to have more input on the mailing list from people
> building Hydra clients. So far, it seems that most of the people on
> this list are instead building Hydra servers. This might be a yet
> another "chicken or the egg" problem...

In my modeling, I have found it more convenient to use concrete/named subclasses of hydra:Collection with an owl:Restriction on hydra:member. However, the restriction probably doesn't help the client too much, and it really just serves as documentation; a client should probably respond to whatever's returned, or note the exception IMO. A restriction is more useful to validate the results, and probably makes more sense for configuring the server than the client. Client's interactions are more governed by operations, where hydra:expects signals the expected type, at least for POSTed data.

>>> This design doesn't help solving the ISSUE #41 (a.k.a. collections
>>> breaking relationships), which I think is very much related, so a
>>> solution to this issue should be aligned with the solution to ISSUE #41.
>> 
>> I think it's a mostly unrelated issue.
> 
> I think the issues are at least a bit related because they both
> discuss how to "look inside of hydra:Collection" to discover the types
> of the collection members.

The question for the spec is MUST, SHOULD, or MAY for subclassing Collection and restricting the value of hydra:member (along with hydra:manages/hydra:property) using OWL or some other mechanism. IMO, this is a MAY and clients should not expect this and be prepared to handle returned results. But, it will take something other than a generic Hydra client to prove this out.

Gregg

> - Jindřich
> 
> -- 
> Jindřich Mynarz
> http://mynarz.net/#jindrich
>

Received on Thursday, 19 June 2014 17:13:22 UTC