- From: Nathan <nathan@webr3.org>
- Date: Wed, 10 Nov 2010 22:26:07 +0000
- To: Jiří Procházka <ojirio@gmail.com>
- CC: public-lod@w3.org
Jiří Procházka wrote: > On 11/10/2010 11:44 AM, Nathan wrote: >> Hi Jiří, >> >> Jiří Procházka wrote: >>> Hi, >>> having read all of the past week and still ongoing discussion about HTTP >>> status codes, URIs and most importantly their meaning from Linked Data >>> perspective, I want share my thoughts on this topic. >>> >>> I don't mean to downplay anyone's work but I think the role of URI and >>> HTTP specifications (especially semantics) in Linked Data is >>> overemphasized, which unnecessarily complicates things. >> The URI is what makes Linked Data, Linked Data, it's the only hook to >> the real world, and via the domain name system + domain registration >> process gives us a hook on accountability, which is critically >> important. > > I am by no means giving up these utilities by what I suggest. > >> "#bar, as described by <http://example.com/foo>" resolves in >> two ways: >> (1) <http://example.com/foo> as a name for the literal description/graph >> (2) <http://example.com/foo> as a way of saying "the author of the >> description available at <http://example.com/foo>, stated X, and was >> responsible as delegated by the owners of example.com", where X is (1) >> and provable by the HTTP messages and logs. A status code of 200 vs 303 >> to some other domain or URI vs 4xx or 5xx plays a big part in that chain >> of accountability / validity / trust. > > I don't think Linked Data consumers should *have to* care about what > status codes HTTP request returns - it shouldn't be part of the core > Linked Data semantics. Of course it can be beneficial for clients to > listen to them to get more information, but treating HTTP library as a > simple function should be allowed (either it returns data or not). > Whether someone 303s (nice verb) to a different domain, it obviously > means he trusts it to maintain the description of his URI. snap, I don't think they should either, I also don't think they should have to constantly ask "is this a document or a toucan?" - it could all be so much easier. ps: 303 doesn't day "you'll find it here!", it says "maybe you try here instead?" >>> So lets stick with this. Lets just treat URIs as RDF does - as simple >>> names. When we dereference an URI we get back some useful data and >>> that's it. >> So, that'll be like mailto: or pop: or tel: then.. > > I don't follow here. I don't know of any standardized ways of getting > structured data out of such URIs. That's the point, RDF treats all URIs the same, you're saying we should treat URIs as RDF does, as nothing more than a logical hook - doesn't do us much good practically when we want to dereference and get back some useful data. >>> If we want to express, the data fetched are in fact a >>> document, we use the wdrs:isDefinedBy property. The data fetched are >>> just a data and any info about it should be contain in it. >> Expressing that the data fetched is infact a document, is indeed >> optional, but any response is always a message, a description, a >> /literal/ thing, you can't pretend it doesn't exist, it does - to say a >> description is anything other than that is like me saying you're an >> apple and insisting everybody believe me. Literals are self identifying, >> self naming, things. > > I don't get what you mean here either. Are you talking about RDF > semantics here or general ontological philosophy? If you are talking > about RDF, then be aware that literals can have names - URIs assigned to > literals. If talking about the latter, then I don't get you at all. > I am advocating making Linked Data as simple as possible, avoiding > abstract ontological definitions (in which I count the notion of > literal). The fact that what you say is incomprehensible to me further > strengthens me in my opinion. Much, much simpler - "this is an email", "this is a html document", "this is an rdf document", "this is a book" - why are people even trying to assert that one of those statements is false? > You have for example foaf:Agent which you dereference and get back the > data amended with: > foaf:Agent wdrs:isDefinedBy [ wdsr:location > "http://xmlns.com/foaf/0.1/Agent" ] . > > If the data already contains: > foaf:Agent wdrs:isDefinedBy foaf: . > foaf: wdrs:location "http://xmlns.com/foaf/0.1/" . > great, we get better info. /foaf#Agent = "Agent, as described by /foaf" seems much simpler to me. and nobody is going to say "Agent sameas Document" ..
Received on Wednesday, 10 November 2010 22:27:09 UTC