Re: How to avoid that collections "break" relationships

Hi Markus,

>> Check that collection X to find out if Markus knows more of them.
> That second sentence is where this approach loses its appeal for me. IMO, it
> doesn't really suggest to go and check "collection X to find out if Markus
> knows more of them". Of course, you can always do, but why should you.

Fully agree of course; but we could look at it the other way:
the server decides what is a good idea to include.
In most cases, it doesn't really make sense to add

    </people/markus/friends> foaf:knows [ hydra:memberOf </soccerteams/spain> ].

Okay, Markus knows a Spanish soccer player… Why put it like that?

I realize this is limited as-is, but good for many cases.
And for the other cases, detailing </soccerteams/spain> is the way to go.

>  {
>    "@id": "/markus",
>    "hasRelationshipIndirection": {
>      "property": "schema:knows",
>      "resource": "/markus/friends"
>    }
>  }

I like the concept, maybe not this exact execution.
Concretely, “hasRelationshipIndirection" is quite impossible to intuitively grasp.

Something along the lines of

   "@id": "/markus",
   "hasList": {
     "property": "schema:knows",
     "object": "/markus/friends"

seems easier to me. (hasList, hasMany, relatesTo, relatesToMany, …)

> It could also be tweaked into something like
>  {
>    "@id": "/markus",
>    "hasRelationshipIndirector": {
>      "schema:knows": "/markus/friends"
>    }
>  }
> so that it works nicely with property paths.

But then (and this is where I would agree with Peter)
you're really going beyond RDF model semantics;
there is some string interpretation required.
I don't like that, even though it is more general.



Received on Monday, 31 March 2014 21:10:41 UTC