- From: Alexandre Bertails <bertails@w3.org>
- Date: Wed, 05 Jun 2013 14:05:00 -0400
- To: Mark Baker <distobj@acm.org>
- CC: Erik Wilde <dret@berkeley.edu>, Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>
On 06/05/2013 01:16 PM, Mark Baker wrote:
> On Tue, Jun 4, 2013 at 5:57 PM, Erik Wilde <dret@berkeley.edu> wrote:
>> hello.
>>
>> we really cannot redefine how the web works, only because RDF has chosen to
>> do things in some ways in which other metamodels have made other design
>> decisions. let's try to look at things with a little less "my metamodel eats
>> your metamodel for lunch" spirit. i think alexandre asked a specific
>> question here, and you guys just squirrel around without actually answering
>> his (very simple) question.
>
> Often the simplest questions have the most complicated answers :P
>
>> let's start with a bookmark, a resolvable HTTP URI. you GET it. we have two
>> possible paths here, and both are working designs, deployed today on the
>> web:
>>
>> - a specific media type such as application/atom+xml points directly to the
>> spec that will allow you to understand how you can drive future interactions
>> (such as "i can now try to GET an entry, and since it has an 'edit' link, i
>> can also try to DELETE it") based on what you find in the representation.
>
> That's not the case. Any URL can be DELETEd a priori without knowledge
> of Atom or what rel=edit means. The resource may not be deleted of
> course, due to permissions (e.g. 401), capability (e.g. 501), or other
> issues, but that doesn't change the fact that the message's meaning is
> unambiguous and required no additional information beyond the URI
> itself.
The "a priori" actually does not hold, as a protocol can decide to not
use DELETE for some reason. But DELETE is not very interesting as an
example as it acts as a function with no parameter.
Take POSTing some text/turtle to a resource advertising itself as
text/turtle:
1. this interaction is not defined in the Turtle spec
2. I could be POSTing as defined in the SPARQL Graph Protocol
3. I could be POSTing to an LDPC or an LDPR.
>
>> - a generic media type (one of the RDF ones, let's say text/turtle) allows
>> you to construct an RDF model and then you see LDP properties in it.
>> interaction affordances a.k.a. links ("use these URIs to engage in these
>> interactions by following these interaction rules") will have to be exposed
>> through the LDP vocabulary, and again you will need to read the spec to
>> understand how that works. nothing in RDF makes any statements about how to
>> use HTTP, certainly not at the level that LDP needs (non-GET interactions,
>> for starters).
>
> Yes, but ... there are limits to what the interaction rules can entail.
We don't want any limits in discovering the interactions that are
allowed: we want to know precisely which ones are possible, without
ambiguity. So far on the Web, this information is given by the media
type.
>
>> there really is no fundamental difference in dependencies here: at the end
>> of the day, somebody needs to implement the spec that allows a client to
>> drive its interactions based on the representations it finds; there is no
>> way how you can avoid reading the spec in either case. if your client
>> implements a vocabulary, you're good to go. if it doesn't, your stuck.
>
> There is a difference as noted above, but that's actually not the
> difference that is (directly) germane to Alexandre's question, which
> was;
>
>>> what is the general mechanism that tells me how to go from "this is text/turtle" to "I can interact with it as defined in the LDP spec"
>
> So to try to answer that again :) ... the mechanism is term grounding
> via namespaces in RDF, but that only takes you to the tiny part of the
> spec that defines that term; it cannot and should not inherit all the
> conformance criteria of the totality of the referenced specification
> (because there shouldn't be any there, as I've said before) or
> anything else that would, in effect, change the (uniform) interface.
Where exactly is this algorithm being defined? Certainly not in RDF or
in any of its serializations. People are extending the way media types
work in undocumented ways, which I've personally never seen used in
practice (I've explained why this also holds in the case of SPARQL
Graph Store Protocol), with the only argument that it was always
intended to be that way. But RDF is not HTTP. That's not how a client
understands what it can do with a resource nor how it says which
protocol it is using.
That would be fine if text/turtle was actually saying something about
that, but it does not, and will probably never do, because it's _only_
an RDF serialization.
> This is what I understood Alexandre to mean behind his use of the word
> "interact", which he appeared to reiterate in his IRC convo with
> Henry;
>
> 23:17 betehess: the content-type is also about the
> semantics/interactions, not only the representation
Which in the case of text/turtle means: there is nothing in the Turtle
spec about looking at the type of a resource to discover how to
interact with it.
Alexandre.
>
> Mark.
>
Received on Wednesday, 5 June 2013 18:05:21 UTC