Re: Questions about new collection design

Hello everyone! This is my first message ever to this list - I hope I'm off
for a good start.

First things first, huge thanks and loud high-fives to all of you. To a
newcomer to the world of JSON-LD, RDF, LDF and Linked-Data such as I am,
this list comes as an invaluable source of both theoretical and practical
understanding.

Now, to the point. I, too, do not like the current collection design that
is being discussed. Beside not providing the client with explicit
assertions about the managed predicate, in my *extremely* humble opinion
this design also confuses the actual triples of interest - representing
those that alice knows - with triples of a higher-order - such as
pagination triples - that actually describe the former triples rather than
alice herself. However... Isn't this what named graphs are for? Being able
to actually describe sets of triples with other triples?

So, here's my graphs-inspired idea...

{
  "@id": "/alice",
  "@type": "foaf:Person",
  "hydra:graphs": [
    {"@id": "/alice/graph/knows", "manages": "foaf:knows"}
  ],
}


{
  "@id": "/alice/graphs/knows",
  "isAbout": "/alice",
  "manages": "foaf:knows",
  "nextPage": "/alice/graphs/knows?p=2",
  "@graph":
  [
    {"@id": "/alice", "foaf:knows": "/bob"},
    {"@id": "/alice", "foaf:knows": "/linda"}
  ]
}

The general idea is to use dedicated graphs to serialise sets of triples
that need meta-data for their representations to be of practical use (such
as query and/or pagination data).

While I do prefer header-based pagination using the "Range" header, this
solution is pagination-agnostic. It can go with header-based pagination,
link-based pagination and whatnot. It also explicitly states who is it that
alice knows, although clients are still required to understand the
"manages" predicate in order to figure out which link to follow.

That's it.  Please forgive me if I have gotten something wrong, I'm still
wrapping my head around all this. Also, english is not my first language -
beware of grammatical and/or syntactical horrors.


--

Jacopo Scazzosi
Developer
http://www.jacoscaz.com

On Thu, Feb 5, 2015 at 9:22 AM, Dietrich Schulten <ds@escalon.de> wrote:

> Hi Markus, hi Tomasz,
>
> Am 03.02.2015 um 21:26 schrieb Markus Lanthaler:
> > On 3 Feb 2015 at 14:38, Dietrich Schulten wrote:
> >> Am 25.01.2015 um 23:31 schrieb Markus Lanthaler:
> >> Question: How to materialize the :knows relationship?
> >
> > It would look somewhat like this (please note the additional knownBy
> > property):
> >
> >   {
> >      "@context": { "knownBy": { "@reverse": "foaf:knows", "@type": "@id"
> }
> > },
> >      "@id": "/alice/friends",
> >      "@type": "Collection",
> >      "member": [
> >        {"@id":"/bob", "foaf:name": "Robert Rumbaugh", "knownBy":
> "/alice" },
> >        {"@id":"/zelda", "foaf:name": "Zelda Zackney", "knownBy":
> "/alice" }
> >      ]
> >   }
> >
> > Would be interesting to see how well compression works here
> >
>
> OK, now that both you and Tomasz tell me i have to use @reverse I think
> I'll give in and accept that this is the way the collection design works
> :) When used with a hydra:Collection, I need to add reverse properties
> to make the :X :hasProperty :A assertion.
>
> Thanks to both of you, anyway.
>
> I hate to spoil the party, but honestly, I do not like the design. I
> tend not to use it in hydra-java for the actual collection, at least not
> by default. I feel that using this design in services without RDF
> backend will seriously prevent adoption.
>
> IMO it *must* be possible to say
>
> "foaf:knows" : { "@id": "/alice/friends" }
>
> We stray too far from plain json-ld and also from the simple way other
> hypermedia types point to collections.
>
> I have several other reasons, but I'll stop here.
>
> Best regards,
> Dietrich
>
>