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
