Re: How to avoid that collections "break" relationships

Hi Gregg, Tore,

On Thu, Mar 27, 2014 at 1:48 AM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

> On Mar 26, 2014, at 4:33 PM, エリクソン トーレ <t-eriksson@so.taisho.co.jp> wrote:
>
> > Alternative suggestion from the spectator seat:
> >
> >> Let's assume we want to build a Web API that exposes information about
> persons
> >> and their friends. Using schema.org, your data would look somewhat
> like this:
> >>
> >>  </markus> a schema:Person ;
> >>            schema:knows </alice> ;
> >>            ...
> >>            schema:knows </zorro> .
> >>
> >> All this information would be available in the document at /markus
> (please
> >> let's not talk about hash URLs etc. here, ok?). Depending on the number
> of
> >> friends, the document however may grow too large.
> >
> > </markus> a schema:Person ;
> >          rdfs:seeAlso </markus/friends/> .
> > </markus/friends/> foaf:topic schema:knows .
> >
> > And in </markus/friends/> (or its redirection target):
> >
> > </markus> schema:knows </alice>,
> >                       ...
> >                       </zorro> .
> >
> > Replace foaf:topic with appropriate schema: properyy if necessary.
>
> That's an interesting idea; in a JSON-LD representation, it might look
> like the following:
>
> {
>   "@id": "/markus",
>   "@type": "schema:Person",
>   "rdfs:seeAlso": {
>     "@id": "/markus/friends",
>     "foaf:primaryTopic": "schema:knows"
>   }
> }
>
> {
>   "@id": "/markus/knows",
>   "@type": "hydra:Container",
>   "hydra:member": "/gregg"
> }
>

This is basically the same pattern as the void:Linkset one, right? With the
less precise predicate foaf:primaryTopic instead of void:linkPredicate. But
that might be fine (especially since as mentioned VoID Linksets are about
linking separate datasets). Btw, I suggest using schema:about instead, if
we're using schema.org in general.


> The only problem I see from a Linked Data perspective is that
> </markus/friends> appears to be defined in the </markus> node definition,
> so it wouldn't be obvious that you would do a further redirection to get
> the container.
>

It is a separate resource, which should probably be described as such
(using e.g. schema:CollectionPage). It is not a problem to describe such
resources within other documents - in fact it is useful and often necessary
(and as I said previously, a recommended practice when publishing linked
data). For instance, the data received from </me> could contain:

    </me> a :Person .
    </me/details.en.html> a :WebPage; :about </me>; :name "About me";
inLanguage "en" .
    </me/details.sv.html> a :WebPage; :about </me>; :name "Om mig";
:inLanguage "sv" .

That should be enough for a client to be able to decide what to fetch,
depending on what the client understands and needs.

Regarding lists of friends - what is the need for connecting artificial
containers/lists of people, and just implying friendship? Is this really
about managing reified triples? Why not just publish documents containing
:knows links between me and my friends? The documents can of course be
collections, paginated and so on. But that's a dataset partitioning
mechanism (using linked documents), orthogonal from the links between me
and my friends. Conflating this seems to cause the problems we're having
here.

(And no, I'm not much bothered by hash-or-slash and such (200 vs 303). What
is troubling though is when the thing described is conflated with a
description of it. That always causes problems. Just keep them separate and
link them together (using e.g. schema:about, rdfs:seeAlso,
iana:describedby), and we can partition descriptions using all the REST
mechanisms we want.)

Cheers,
Niklas


>
> Gregg
>
> > Tore
>
>
>