- From: François-Paul Servant <francoispaulservant@gmail.com>
- Date: Mon, 16 Feb 2015 16:53:17 +0100
- To: public-hydra@w3.org
- Cc: Dietrich Schulten <ds@escalon.de>
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
Received on Monday, 16 February 2015 15:53:48 UTC