- From: Norman Gray <norman@astro.gla.ac.uk>
- Date: Wed, 28 Sep 2011 19:13:05 +0200
- To: Sebastian Schaffert <sebastian.schaffert@salzburgresearch.at>
- Cc: "semantic-web@w3.org >> semantic-web@w3.org" <semantic-web@w3.org>, public-lod <public-lod@w3.org>
Sebastian, hello. On 27 Sep 2011, at 13:43, Sebastian Schaffert wrote: >> I think you're disappointed because your expectations may be wrong. > > My expectations are my expectations. But I accept that the world maybe does not satisfy them ;-) I often have the same feeling -- *sigh* -- I've come to think of it as the tragedy of adulthood.... > But from my experience in developing software together with industry partners out there I have a good guess that my expectations will more-or-less match with the expectations of other developers. Especially those who are not very deep in Semantic Web technologies. I'm nervous of opening up a potentially long discussion, but I've never understood what's so hard about httpRange-14. Any time I've explained it to someone -- including some pretty SemWeb-sceptical RDBMS people -- they've got the idea and its importance pretty promptly. I may have given one RDBMS colleague their SemWeb insight that way. I do appreciate that in certain circumstances, where one doesn't have good control over the data being LODified, there's no option but to say, in effect <http://example.org/foo> a foaf:Person; a foaf:Document. (I haven't looked at it, but I imagine that dbpedia either suffers from this or else has had to be very clever with domains to get round it). According to httpRange-14, of course, one of those statements must simply be false. So clients have to be smart to deal with this punning; but life is hard and we know this is the wild wild web: the httpRange-14 dogma cannot be absolute. >> When you dereference the URL for a person (such as .../561666514#), you get back RDF. Our _expectation_, of course, is that that RDF will include some remarks about that person (.../561666514#), but there can be no guarantee of this, and no guarantee that it won't include more information than you asked for. All you can reliably expect is that _something_ will come back, which the service believes to be true and hopes will be useful. You add this to your knowledge of the world, and move on. > > There I have my main problem. If I ask for "A", I am not really interested in "B". But if one does accept the logic of httpRange-14, then 'A' is something like 'B#', and it is _impossible_, as a consequence of the way HTTP is defined, to dereference specifically 'A', and thus any client which exists in a world with httpRange-14 in it, must necessarily be able to deal with the fact that what is described in the response may not be precisely what it did the HTTP transaction on. It presumably knows that it was asked to find out about 'A' = 'B#', so it can do its filtering process with that in mind, no? I agree, by the way, that we shouldn't expect that everyone in the world, including RDBMS diehards and junior programmers, should be expected to understand the formal subtleties here. But that's what libraries and layers are for, surely. You do understand the difference, so you write a thin layer which provides API-users with the information they expect. Am I misunderstanding a constraint? > - the data I get back is not about the resource I requested (discussion above), because there are competing philosophies about httpRange-14 (which is IMHO a never ending problem, unsolvable and also unnecessary in most situations), because there are several different recommendations about how to publish data on the web, or because some service somehow decides that some other data might be more useful or interesting than the one I asked for I'm prolonging this discussion because I'm trying to publish linked data myself (I just need to twist a few more SemWeb-sceptical arms), I believe I thoroughly understand the pattern and the point, and so I would be interested to find out if I've somehow drifted away from the mainstream. Best wishes, Norman -- Norman Gray : http://nxg.me.uk
Received on Wednesday, 28 September 2011 17:13:54 UTC