Re: Questions about new collection design

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
>