Re: Questions about new collection design

Hello John.

That sounds extremely close to what I had in mind. Thank you for sharing
your experience.

I really like the header (metadata) / body (data) separation of concerns
and I think (more like feel, actually - I'm running a lot on intuition)
that it could greatly simplify things (and potentially address some of
Dietrich's concerns).

Unfortunately, I'm unable to back this with sound arguments (looking into
the formal specs of RDF datasets as we speak) as I need to develop a firmer
grasp on these matters.

Messing with a finalized design was also a bit foolish on my part, truth to
be told. I can't help but feel like the current collection design
strays too far from the immediacy of plain sets, though. It's a necessary
evil, I guess.

Perhaps I'll be able to come up with a reasonable way to deal with metadata
using named graphs in the future. I'd sure be interested in seeing what you
were working on.

Jacopo.

On Friday, February 6, 2015, <john.walker@semaku.com> wrote:

>  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/* <http://www.w3.org/TR/urls-in-data/>
>
> Regards,
>
> John
>
> *From:* Jacopo Scazzosi
> <javascript:_e(%7B%7D,'cvml','jacoposcazzosi@gmail.com');>
> *Sent:* ‎Thursday‎, ‎5‎ ‎February‎ ‎2015 ‎22‎:‎38
> *To:* Markus Lanthaler
> <javascript:_e(%7B%7D,'cvml','markus.lanthaler@gmx.net');>
> *Cc:* public-hydra@w3.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>>
>>
>>

-- 

--

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