Re: How to avoid that collections "break" relationships

I don't see how this solves the problem.

Even if you augment RDF with this set construct (hydra:memberOf pointing to a 
separate document containing a collection of entities), what you are saying is 
thatMarkus knows some entity, and that that entity belongs to the set. It does 
not say which of the members of the set are friends of Markus, nor that any 
more than one of them has to be.


On 03/31/2014 01:34 AM, Ruben Verborgh wrote:
> Dear all,
> Sorry for hacking the discussion, but I think we should keep the discussion goal-focused.
> So let's therefore see what we want to achieve:
> 1. Having a way for clients to find out the members of a specific collection
> 2. Not breaking the RDF model while doing so
> A solution that satisfies 1 and 2 with minimal effort is good enough for Hydra;
> the rest can be discussed more deeply in other places.
> The easiest solution I could come up with that satisfies the above criteria is the following.
> Suppose a client needs to find Markus' friends, and the server use foaf:knows for that
> (which has the restrictive range foaf:Person, disallowing a collection).
> If the representation contains all of Markus' friends, then it could look like:
>      </people/markus> foaf:knows </people/Anna>.
>      </people/markus> foaf:knows </people/Bert>.
>      </people/markus> foaf:knows </people/Carl>.
> Now, more interestingly, if the list of Markus' friends is available
> as a separate resource /people/markus/friends, then it could look like:
>      </people/markus> foaf:knows [ hydra:memberOf </people/markus/friends> ].
> So we say that a blank node is one of Markus' friends, and where it can be found.
> This satisfies 1, because the client can follow the link and find all friends there.
> This satisfies 2, because the blank node is an actual person, not a collection.
> And that is all we need for hypermedia clients to work.
> Yes, I know this does not add a whole bunch of extensive semantics
> we might need for specific case X, but:
>    a) that's not necessary in general; a Hydra client has all it needs;
>    b) this solution is extensible to allow for that.
> If you like, you can add details about /people/markus/friends,
> say that they all have a foaf:knows relationship to /people/markus etc.
> Summarized: look at the minimum client needs, implement that;
> only thing we need is a blank node and a memberOf predicate.
> Hydra clients work; the model is happy too.
> Best,
> Ruben
> PS The only case this slightly breaks the model is if Markus has no friends yet;
> then you say Markus knows somebody while he actually doesn't.
> But saying something doesn't exists is a problem in RDF anyway.
> The easy way: just don't include any foaf:knows triple (or ignore slight breakage).
> If you insist to include _something_, we'd need to do have an explicit empty list:
>      </people/markus> foaf:knowsList ().
>      foaf:knowsList hydra:listPropertyOf foaf:knows.
> But then we'd be stuck with twice as many properties, which is not ideal either.

Received on Monday, 31 March 2014 14:55:20 UTC