Re: Questions about new collection design

Hi Jacopo,




I had a similar idea about using named graphs a while back, but quickly ran into similar issues about (lack of) formal semantics and didn’t get very far.




In a nutshell I was contemplating using a named graph for each resource described by an API as a uniform way to disambiguate between the JSON-LD (or whatever other RDF quads format) resource and the entity that document describes.

Basically the metadata statements about the JSON-LD resource would be in the default graph and the statements about the subject entity (or entities) of the resource would be in a named graph whose URI is the same as the JSON-LD resource.






My idea was that this would neatly separate matters whereby the statements in the named graph would be considered as the RDF ‘payload’ of the message and the statements in the default graph would be considered as a kind of ‘header’.

As such the default graph would contain the Hydra statements that describe possible operations on the resource.

I thought this might also make it easier to describe the expected shape/schema for the data in the named graph without mixing this up with the metadata.

Then when updating the resource the client would PUT/POST the named graph and the server take care of the default graph.

Potentially this might also allow one to link the shape/schema to the class of the JSON-LD resource rather than the class of the thing the JSON-LD resource describes.




Hopefully that makes some kind of sense, but probably there are a hundred reasons why it breaks semantics of something or other.




You might also read “URLs in Data Primer” and see what you think about the idea of direct and shorthand properties as a way of punning.




http://www.w3.org/TR/urls-in-data/





Regards,

John





From: Jacopo Scazzosi
Sent: ‎Thursday‎, ‎5‎ ‎February‎ ‎2015 ‎22‎:‎38
To: Markus Lanthaler
Cc: public-hydra@w3.org





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