On 03/31/2014 08:02 AM, Ruben Verborgh wrote:
Hi Peter,
I don't see how this solves the problem.
Recall that “the problem” for Hydra clients is (in my opinion):
1. Having a way to find out the members of a specific collection
2. Not breaking the RDF model while doing so
what you are saying is thatMarkus knows some entity, and that that entity
belongs to the set.
…and I give that set a URL, too.
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 purpose, since it is not needed at all to solve 1 and 2.
</people/markus> foaf:knows [ hydra:memberOf </people/markus/friends> ].
Gives you the URL of the set, which allows you to retrieve it.
Then if you retrieve it, it will list its members and say they are friends of
Markus:
</people/markus> foaf:knows </people/Anna>.
</people/markus> foaf:knows </people/Bert>.
</people/markus> foaf:knows </people/Carl>.
But this is violating both the spirit and the letter of RDF. It would be
better to introduce entirely new syntactic mechanisms, for example, something like
</people/markus> foaf:knows **http://.../people/markus/friends**
which could be read as shorthand for replacing the **...** with an object list
containing the objects in the document being pointed at.
This is exactly the reason I propose this approach;
I know many people want more semantics in there;
and that's totally fine and even possible with this approach
(like I said, you can further describe /people/markus/friends if you like.)
But all we need for Hydra clients is a way to get Markus' friends.
This solution offers it. No more semantics needed.
Huh? If you want to be in the RDF camp, you have to play by RDF rules.
However, maybe all you want is something that is syntactically RDF. In that
case there are a multitude of solutions. Yours might be somewhat better than
the other ones, but the differences look rather superficial when viewed
through an RDF lens.
Best,
Ruben
peter
