Re: Links and graphs

KK:

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.

Cheers.

mca
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen




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
>
>