Re: Questions about new collection design

What hydra does is to use http://www.w3.org/ns/hydra/core#apiDocumentation 
as rfc 5988 extension relation type ("custom rel") to point to the 
hydra:ApiDocumentation. It is however not meant to describe the current 
resource alone but rather the entire API.


Best regards,

Dietrich


Am 16. Februar 2015 23:12:33 schrieb Jacopo Scazzosi 
<jacoposcazzosi@gmail.com>:

> Hello.
>
> A question originating from the newer proposals for the collection design
> in the other thread: the collection now sounds like a document describing
> another document, itself an array of resources (I really like this, by the
> way). Does Hydra have a general mechanism for pointing to a describing
> document? Perhaps using the IANA rel "describedBy" in a Link header?
>
> I wrote in this thread as I did not want to pollute the other one with
> excessive newbie-ness.
>
>
>
> --
>
> Jacopo Scazzosi
> Developer
> http://www.jacoscaz.com
>
> On Mon, Feb 16, 2015 at 3:53 PM, François-Paul Servant <
> francoispaulservant@gmail.com> wrote:
>
> > Hi,
> >
> > jumping into the discussion about collections, for my first message to
> > this list (as a short intro: I have been using RDF and Linked Data to
> > publish data, and Hydra seems to try to address many of the problems that I
> > got in this work, hence my interest).
> >
> > I wanted to say that I don't like the idea to have to include both the:
> > /alice foaf:knows /x.
> > triples and the
> > /alice/friends hydra:members /x.
> > triples in the data returned when getting /alice/friends (or a given page
> > in the pagination process)
> >
> > I know that we cannot say that
> > /alice foaf:knows /alice/friends.
> >
> > and I understand that we may be reluctant to require inferencing
> > capabilities from the client to infer the "foaf:knows" triples from the
> > "hydra:member" ones.
> >
> > That's why I'm feeling very close to Dietrich's idea:
> >
> > > keep the actual items outside of the hydra:Collection object and make
> > > them direct values of the property they belong to
> >
> > in other words, the data returned when getting /alice/friends (or any
> > related page) would basically be a graph of
> > /alice foaf:knows /x.
> > triples.
> >
> > I wouldn't go as far as dropping hydra:member, as Dietrich suggests. I
> > would rather require the client to use the "foaf:knows" triples to infer the
> > /alice/friends hydra:member x.
> > triples. (This way, we keep the "mental representation" of a collection as
> > a list of hydra:members)
> >
> > You may say that this is what we want to avoid (requiring inferencing
> > capabilities from the client). But this is not as bad as in the other way
> > around (from "hydra:member" to "foaf:knows") because a simple Linked Data
> > client would still be able to get the "real knowledge" that the server
> > wants to express (Alice"s friends) without needing any inference. The
> > "core" information is indeed the fact that, eg.,
> > /alice foaf:knows /bob.
> > not that
> > /alice/friends hydra:member /bob.
> >
> > And I don't think that it is really a big deal to require from a generic
> > hydra:client to handle the inference from foaf:knows to hydra:member: that
> > is exactly the meaning of the "manages" triples in the definition of
> > /alice/friends. hydra:manages tells that the client will have to look for
> > the
> > /alice foaf:knows /x
> > triples in the returned data.
> >
> > It doesn't seem really harder that looking for the
> > /alice/friends hydra:member /x
> > triples.
> >
> > And this avoids to have to put "twice the same thing" in the data. (OK,
> > it's not the same thing, but some people could think it is and may find it
> > stupid to have to write both in the same chunk of data. I feel uneasy to
> > explain why it has to be this way.)
> >
> > Hope this makes sense. Best,
> >
> > fps
> >