RE: How to avoid that collections "break" relationships

Hi Markus, Tore

> On March 27, 2014 at 2:14 AM エリクソン トーレ <t-eriksson@so.taisho.co.jp> wrote:
>
>
> March 27, 2014 9:49 AM Gregg Kellogg <mailto: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"
> > }
> >
> > 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.

Based on AAA assumption, would it be wrong to assume that just because
</markus/friends> is the subject of some triples in </markus> resource, that I
would not get additional information by following the link?

For example in the friends list, I would expect it is reasonable and useful to
include the foaf:name of all the people you know so you can present these to the
user without having to follow each of those links individually to fetch the
persons name.
In fact doing this kind of flexible denormalization in the data publishing layer
is one of the strong points of RDF and Linked Data IMHO.
Sticking to a world view where data is only published in normalized form is
losing a lot of useful points.

In the above example, I would expect the use of rdfs:seeAlso gives a strong hint
to the user agent to follow that link, plus including some info about that
resource gives a hint of what you can expect to find there.

>
> Sorry, I have no knowledge of Hydra.
> My though was to skip the container completely and only serve
> a bunch of raw
> </markus> schema:knows [] .
> triples from </markus/friends> or the redirection target </markus/friends..rdf>
>
> Paging seems like overkill but I guess it could be necessary in other
> situations.
>
> Tore

Based on the JSON-LD example from Markus, what seems logical for me is as
follows.
I minted a new hydra:relation property that tells you by which property the
primary topic of the list is linked to the members by.

{
"@id": "/markus",
"@type": "schema:Person",
"rdfs:seeAlso": {
"@id": "/markus/friends",
"@type": "hydra:Container",
"foaf:primaryTopic": "/markus",
"hydra:relation": "schema:knows"
}
}

{
"@id": "/markus/friends",
"@type": "hydra:Container",
"rdfs:label": "List of Markus' friends" ,
"foaf:primaryTopic": "/markus",
"hydra:relation": "schema:knows" ,
"hydra:member":  [
{ "@id": "/gregg" },
{ "@id": "/bill" }
]
}

So with appropriate inference rules you could entail that markus knows gregg and
bill, or also just state these triples explicitly in the friends list.

When Markus is a very popular guy the list can also be paginated.

Hope that makes sense.

Cheers,
John