- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 5 Jun 2013 20:05:39 +0200
- To: Alexandre Bertails <bertails@w3.org>
- Cc: public-ldp-wg@w3.org
On 5 Jun 2013, at 15:15, Alexandre Bertails <bertails@w3.org> wrote: > On 06/05/2013 02:21 AM, Henry Story wrote: >> 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 > > You forgot the most important comment: > > Jun 04 17:25:40 <betehess> not really, I'm not convinced > > Alexandre :-) Well, I just proved it from basic principles. You can decide not to be convinced, but that is beyond the reaches of reason then. If you explained what did not convince you then one could progress. > Social Web Architect http://bblfish.net/
Received on Wednesday, 5 June 2013 18:06:12 UTC