RE: Questions about new collection design

Hello Markus.

When you're in doubt, it's safe to assume I am the one confusing things. At
least for now... :)

I'd go on explaining how I came to my proposal and address your points but,
in light of the document on the semantics of datasets (thanks for pointing
me to that, I had somehow managed to miss it) and your kind answer, I
realise I have quite a lot more to figure out.

I'll go back to my cave and educate myself some more on these subjects.

I'm using Hydra in a web-based framework for environment intelligence I'm
experimenting with - I bet I'll come up a lot of questions!

Keep going, this list is amazing.

Jacopo.
On Feb 5, 2015 9:03 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:

> On Thursday, February 05, 2015 1:30 PM, Jacopo Scazzosi wrote:
> > Hello everyone! This is my first message ever to this list - I hope
> > I'm off for a good start.
>
> Welcome Jacopo!
>
>
> > 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.
>
> Thanks for the nice words. It's great to hear its valuable for you.
>
>
> > 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?
>
> Unfortunately not really. You can use them that way but that's not how
> they have been standardized. If you want dig into this and have a couple of
> hours you might wanna read "RDF 1.1: On Semantics of RDF Datasets"
>
>    http://www.w3.org/TR/rdf11-datasets/
>
>
> > 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",
>
> I can't see a substantial difference to the current collection design to
> be honest...
>
> >   "@graph":
> >   [
> >     {"@id": "/alice", "foaf:knows": "/bob"},
> >     {"@id": "/alice", "foaf:knows": "/linda"}
> >   ]
> > }
>
> ... and the biggest issue is that this would put the /alice foaf:knows ___
> triples into different named graphs.
>
>
> > 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).
>
> I don't know whether I misunderstand you here or whether you are confusing
> something here. These triples do not need "need meta-data for their
> representations to be of practical use". The client, however, needs some
> information about where to find these triples. That's the whole purpose of
> pagination: providing pointers to places where more of these triples can be
> found.
>
>
> > While I do prefer header-based pagination using the "Range" header,
> > this solution is pagination-agnostic. It can go with header-based
> pagination
>
> What range would you apply here? Bytes don't make much sense. Triples
> neither. Anything else?
>
>
> > 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 exactly what happens in the current collection design. Have you
> read my reply to Dietrich?
>
>    http://lists.w3.org/Archives/Public/public-hydra/2015Feb/0016.html
>
>
> > Here's a link to a working snippet of what I have in mind, running in
> > the JSON-LD playground: http://tinyurl.com/loacumv .
> >
> > It shows a paginated collection of "foaf:knows" values implemented
> > using a different named-schema per each page of the collection, each
> > with appropriate pagination links. The normalized output looks fine to
> > me.
> >
> > Granted, the semantics of "hydra:manages", "hydra:next", etc... etc...
> > are slightly different than the current ones.
>
> Have you noticed that the triples are segregated into three different
> graphs?
>
>
> > 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.
>
> No need to apologize :-) Quite the contrary, thanks for taking the time to
> share your thoughts. Maybe you could elaborate a bit on what you don't like
> in the current design so that we can see whether we missed something.
>
>
> Cheers,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
>