Re: Proposal to close ISSUE-19: Adressing more error cases, as is

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.

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

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

Mark.

Received on Wednesday, 5 June 2013 17:16:28 UTC