RE: Questions about new collection design

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

Received on Thursday, 5 February 2015 21:03:07 UTC