An IRC discussion with Alexandre Bertails re SSUE-19:

Where we find out that we can get from first principles of URIs, RESTful HTTP interactions on Resources that return representations
(interpreted by mime types to some model - in particular a graph ), which said model can describe the resource referred to by the URI. 
On the difference between meaning and truth/falsehood and how one comes to trust a statement on the web. How one can relinquish
trust is also treated in this this short socratic dialog with Alexandre yesterday evening.

12:53 bblfish: Does a URI refer to a Resource?
22:53 betehess: hrmmm, I've said yes twice
22:53 bblfish: Ok.
22:55 bblfish: Does an HTTP resource return a represntation of that resource when interacted with using GET ?
22:55 betehess: if it's a good web citizen, I would expect the answer to be Yes
22:55 bblfish: I think this is necessarily the case
22:55 betehess: but RDF does not say anything about it
22:56 bblfish: I have not come to RDF yet
22:56 betehess: and SPARQL does not care
22:56 betehess: right
22:56 bblfish: ok. don't jump the gun
22:56 betehess: I'll let you continue then :-)
22:56 betehess: but so far, Yes and Yes
22:56 bblfish: Good, so other than Cache corruption issues, the representation returned by an HTTP resource is a representation of that resource at that time.
22:57 bblfish: If the representation is in an RDF format as per mime type, you can interpret the representation as a Graph, right?
22:57 betehess: almost true
22:57 bblfish: where's the almost hitch?
22:57 betehess: what about #-URIs?
22:57 bblfish: #URIs are defined by the URI spec.
22:58 bblfish: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html
22:58 bblfish: ( I don't know why we don't get the HTML anymore )
23:00 bblfish:   The fragment identifier component of a URI allows indirect
23:00 bblfish:   identification of a secondary resource by reference to a primary
23:00 bblfish:   resource and additional identifying information.  The identified
23:00 bblfish:   secondary resource may be some portion or subset of the primary
23:00 bblfish:   resource, some view on representations of the primary resource, or
23:00 bblfish:   some other resource defined or described by those representations.  A
23:00 bblfish:   fragment identifier component is indicated by the presence of a
23:00 bblfish:   number sign ("#") character and terminated by the end of the URI.
23:00 bblfish: http://tools.ietf.org/html/rfc3986#section-3.5
23:01 betehess: anyway, the GET gives you some information about the state of the resource
23:01 bblfish: yes, that can be interpreed as a graph if the mime type is correct
23:01 betehess: they don't necesseraly describe the resource
23:01 bblfish: of course you don't necessarily do that.
23:01 bblfish: I am looking at cases where they do.
23:02 bblfish: if that graph contains a triple that refers to the resource, then it describes that resource.
23:02 bblfish: as being related in some way to something else
23:02 bblfish: yes?
23:03 bblfish: RDF Semantics specifies what has to be true for the graph to be true.
23:03 betehess: I'm getting confused by words but yes, I suppose do
23:04 betehess: s/do/so/
23:04 bblfish: ok.
23:04 bblfish: Good so now if we define ldp:Container to be the set of resources which can be interacted with in a certain 
23:04 bblfish: way and if the resource says { <> a ldp:Container . }
23:05 bblfish: then we can assume it is saying that certain interactions can be done on it: namely LDP interactions.
23:05 bblfish: if we can not interact that way with it then the statement was false.
23:05 betehess: that's the part I'm not sure about
23:05 betehess: why is it true?
23:05 bblfish: why is what true?
23:05 betehess: as far as HTTP is concerned, that's not how it works
23:06 bblfish: HTTP is a different layer
23:09 betehess: knowing for reason that [[ <> a ldp:Container ]] does not mean I can do it. RDF assumes that it's true, but it's only true if <> tells you so
23:10 bblfish: If you look at the RDF Semantics it will tell you when <> a ldp:Container is true.
23:10 bblfish: It is true iff <> is a resource that is part of the set refered to by ldp:Container.
23:11 betehess: for example, you can learn that [[ <foo> a ldp:Container ]] by dereferencing <bar>
23:11 betehess: it does not mean anything in practice
23:11 bblfish: no, it _means_ exactly that
23:11 betehess: <foo> may be an image
23:11 betehess: for RDF, yes
23:11 betehess: but HTTP does not care
23:11 bblfish: you need to distinguish meaning and truth
23:12 bblfish: { <foo> a ldp:Container } is true iff <foo> is an LDPC
23:12 bblfish: but it may not be.
23:12 betehess: can you instanciate  meaning and truth in my example?
23:12 bblfish: yes, if <foo> acts like an LDPC then the relation is true
23:13 bblfish: but the case is more clear cut when a resource speaks about itself as being an LDPC.
23:13 bblfish: of course it  can also be lying
23:13 bblfish: but you go on the presumption of innoncence
23:14 bblfish: Or as Donald Davidson wrote in Truth and Interpretation, you use a principle of charity, which is that the agents you are communicatiing with are truthful.
23:14 bblfish: but if they are not, then you stop interacting with them.
23:14 bblfish: and you stop linking to them.
23:15 bblfish: or you say things like <foo> a ldp:nonContainer
23:15 bblfish: so people don't follow the link
23:15 bblfish: or <foo> a log:Falsehood .
23:15 betehess: this is making everything just complex. You cannot convince people with such hard reasoning about how to jump from RDF truth (which the specs assume today) to a resource being an LDPC in practice
23:16 betehess: and you need to look at the content, always
23:16 betehess: it's the point of the Content-Type to save you here
23:16 bblfish: this is just what you get when you read RDF Semantics. It defines truth in a Tarskian way
23:16 bblfish: no content-type is just a way to specify the language of the representation.
23:17 betehess: yes, it would true in all realizations, which is not true in practice...
23:17 bblfish: If it is JSON content then you need to create special mime types
23:17 betehess: RDF does not say who is authoritative
23:17 bblfish: well not quite
23:17 betehess: the content-type is also about the semantics/interactions, not only the representation
23:18 bblfish: no.
23:18 betehess: yes
23:18 bblfish: no
23:18 bblfish: absolutely not
23:18 betehess: you just don't see that often at w3c because we don't define web apis
23:18 bblfish: that is the error the REST folks who use XML make
23:18 betehess: you mean webarch is wrong?
23:19 betehess: we're defining a Web API
23:19 bblfish: no, the REST folks only use formats where they need to use mime types that way 
23:19 bblfish: ( to distinguish the meaning from other interpretations ) but that is their problem
23:19 betehess: if it was only about GETs, I wouldn't care about your interpretation
23:20 bblfish: btw { <> a ldp:Container . } also specifies how to do POST, etc...
23:20 bblfish: it creates some restrictions on HTTP: namely those specified in the ldp spec
23:21 bblfish: ( if you believe it to be true of course )
23:21 bblfish: or rather the other way around. It is true, if those interactions hold.
23:22 betehess: Henry, here is the thing: why should I accept { <> a ldp:Container . } to be true?
23:22 bblfish: 1. because you probably got there through a link you trust
23:23 bblfish: 2. if you interact and you don't get the results expected you come to the conclusion there is a bug or it is lying
23:23 betehess: and [[ if those interactions hold ]] means that it does not require { <> a ldp:Container . } to be true either
23:24 betehess: I really don't get why webarch speaks about presentation and interaction...
23:24 bblfish: true. But on the web the best resource to trust on its state is the resource itself
23:24 betehess: you're saying that interaction is implied by [[ those interactions hold ]]
23:25 betehess: anyway, I have to be 5 km away in 5 minutes...
23:25 bblfish: yes, http defines POST, PUT etc. LDP  vocab creates further restrictions on it
23:25 betehess: (biing)
23:25 bblfish: ok hope that helps