W3C home > Mailing lists > Public > public-ldp@w3.org > December 2012

Re: Links and graphs

From: mca <mca@amundsen.com>
Date: Sun, 16 Dec 2012 14:53:09 -0500
Message-ID: <CAPW_8m5+GjrzUPwvEaobBGC=gRFmUg66EKv9yHo4Z8ogVooygw@mail.gmail.com>
To: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Cc: public-ldp@w3.org, W3C provenance WG <public-prov-wg@w3.org>

thanks for the jumping in here. my only complaint w/ your reply is that you
"described to me" how you would express this choice, but didn't _show_ me.
i am serious, too.

i am most interested in how this _looks_ and how clients can code for
choices in responses.

anything that you can point to that is tangible evidence of this M2M style
coding where clients make choices is most welcome.


skype: mca.amundsen

On Sun, Dec 16, 2012 at 2:45 PM, Kjetil Kjernsmo <kjetil@kjernsmo.net>wrote:

> On Sunday 16. December 2012 12.21.04 mike amundsen wrote:
> > show me how you would express this choice between SPARQL endpoint and
> > REST service in a message in a way a machine could operate on it - make
> > a choice - successfully.
> I would argue that the most useful think is that "if it isn't SPARQL, then
> it is RESTful on some level". Our service description document is already
> there -- it is VoID -- and in VoID, you can express a link to a SPARQL
> endpoint, which has its own service description.
> For everything else, there should be some triples following the description
> of each and every resource telling an agent what it could do with it. So, a
> machine reading the a description of a resource will already know what it
> can do with it, replace, augment, delete or just read, add similar
> resources to a collection, etc., or it will be pointed to a VoID
> description where it can learn that SPARQL queries may be used.
> I tend to prefer not to think of link relations, neither in HTML terms nor
> in HTTP header terms, as I believe we should have the full expressivity of
> RDF.
> Best,
> Kjetil
Received on Sunday, 16 December 2012 19:53:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:09 UTC