- From: John Walker <john.walker@semaku.com>
- Date: Sat, 7 Feb 2015 09:59:17 +0100 (CET)
- To: Jacopo Scazzosi <jacoposcazzosi@gmail.com>
- Cc: "public-hydra@w3.org" <public-hydra@w3.org>, Markus Lanthaler <markus.lanthaler@gmx.net>
- Message-ID: <1369763143.169308.1423299557717.open-xchange@oxweb01.eigbox.net>
Hi Jacopo,
Progress so far is in this repo:
https://github.com/jaw111/skos-api
Where I got into mental backflips was thinking about how to link from a resource
describing a concept to the collection of narrower concepts for example.
What would that collection look like?
What are the members of that collection, the narrower concepts, or the resources
containing that X skos:narrower Y statement?
I quickly found that maintaining a strict split between information and
non-information resources adds a lot of complexity.
However I'd like to get back to this and will hopefully have time to do so next
month.
John
> On February 7, 2015 at 12:22 AM Jacopo Scazzosi <jacoposcazzosi@gmail.com>
> wrote:
>
> 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
> <mailto: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
> > 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
> > >
> > >
> > >
> > > > > >
>
> --
>
> --
>
> Jacopo Scazzosi
> Developer
> http://www.jacoscaz.com
>
Received on Saturday, 7 February 2015 08:59:44 UTC