W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

Re: An IRC discussion with Alexandre Bertails re SSUE-19:

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Thu, 6 Jun 2013 12:25:03 +0200
Message-ID: <CA+OuRR-bqJ3JpR4MqBYrWCsHgo_nmfexLxy6XHkcj-ZNtAtkMw@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: Alexandre Bertails <bertails@w3.org>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Henry, Alexandre,

On Thursday, June 6, 2013, Henry Story wrote:

> Well that's my point: mime types are not the place to look
> at to find interaction patterns with web resources! That is
> not at all what they are designed for.

where then? The whole point of RESTful design (in my understanding) is that
you don't need to update your client everytime a new service is available
out there. For that, the service has to provide enough information so that
the client knows how to "use" it (interaction semantics). Typically, in
RESTful design, this interaction semantics is carried by the media-type
(e.g. HTML or Atom); by declaring a content-type, the server and the client
agree to use an externally defined interaction semantics.

True, many web APIs today do not comply with this principle; they
provide/consume application/json (or application/xml), and the client has
to know which "kind" of JSON can be used with which service. And still,
it's working! The question is: would it work better if they did respect
REST principles? I believe so (well, depending how you define "better", I

That being said, the point is not, IMHO, about using 'content-type' and
only that. I agree that this "externally defined interaction semantics"
could be indicated by other means, e.g. the use of some vocabulary inside
the media-type. This raises a number of problems, compared with the
content-type approach:
* you are forced to get and parse the body
* you can not do content negociation
but I think we can solve that (e.g. with 'profile' Link headers).

So I guess I disagree with Alexandre, who seems to think we can not succeed
without a new media type.
The way I see it, this group is actually *augmenting* the meaning of the
Turtle media type (and probably other RDF media-types), by providing it
with interaction semantics, captured by the LDP vocabulary.

More precisely, to answer Alexandre's questions:

> > * how do I know that <foo> is an LDPR?

Well, any resource that yields a Turtle representation becomes de facto an
LDPR (even if read-only).

> > * how do I know that <foo> is neither an LDPC nor an LDPR?

See above: if it yields Turtle, it *is* and LDPR.
(granted, it would be useful to be able to tell the difference btw a
read-only and a PUTable LDPR, though)

> > * how do I know that I can interact with <foo> using the SPARQL Graph
> Protocol?

Is that in our scope? If so, I guess we should have a class or a property
to state that about a given resource.

> > * if I find out that <foo> a ldp:Container while looking at <bar>,
> >  should I consider this information as authoritative?

Well, when you find the following HTML

  <form action="foo" method="foo">

at <bar>, do you believe it? Do you try and perform a POST on <foo>?
I guess the answer is the same: if you trust the source, then yes, you're
allowed to start interacting with <bar> as if it were an LDPC.

Received on Thursday, 6 June 2013 10:25:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:51 UTC