- From: <Patrick.Stickler@nokia.com>
- Date: Tue, 23 Nov 2004 11:43:18 +0200
- To: <dirkx@webweaving.org>, <stefano@apache.org>
- Cc: <jeen@aduna.biz>, <A.J.Miles@rl.ac.uk>, <www-rdf-interest@w3.org>, <public-esw-thes@w3.org>
> -----Original Message----- > From: www-rdf-interest-request@w3.org > [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext > Dirk-Willem van > Gulik > Sent: 23 November, 2004 00:46 > To: Stefano Mazzocchi > Cc: Jeen Broekstra; Stickler Patrick (Nokia-TP-MSW/Tampere); > A.J.Miles@rl.ac.uk; www-rdf-interest@w3.org; public-esw-thes@w3.org > Subject: Re: working around the identity crisis > > > > > > On Thu, 18 Nov 2004, Stefano Mazzocchi wrote: > > > There is a difference. > > > > Dereferencing http://blah.com/foo#bar will send "foo" to > the server, and > > keep "bar" on the client. > > > > Dereferencing http://blah.com/foo/bar will send both "foo" > and "bar" to > > the server. Quite true. > .. > > I personally think that once Sparql web services are > available, the # > > vs. / debate will very likely disappear, because at that > point, you can > > dereference a single URI, even if it uses a # Really? How does SPARQL provide access to an actual representation? E.g. a JPEG, a PDF, an HTML web page? It might provide some RDF which indicates where one might access a representation, but SPARQL is not a URIref resolution solution. It does not replace HTTP or similar protocols. Are you suggesting that web clients, in order to access representations of resources, must collaborate with one or more *centralized* knowledge bases to obtain information that will allow them to locate/access representations? I hope not. That would be a huge leap backwards. -- In any case, if we're talking about discovering knowledge about a resource, how would a client benefit from SPARQL if all it has is the URI and no additional knowledge? Here is a URI: http://example.org/78fa28b3-aab7-4551-b9b0-99e28fa87ecf#x891 You have no other knowledge relating to the secondary resource identified by that URI, or the primary resource identified by the base URI, or the host 'example.org'. How does SPARQL help? OK, so perhaps you are aware of a few SPARQL enabled knowledge services, or you are able to somehow discover such services. Let's say that one or more of them actually know something about the resource in question. Well, how can you be sure that knowledge is authoritative? How do you know that the owners/managers of example.com will agree with what is being asserted by those third party services? And how much effort does your web client have to expend to locate and query those service and determine if the knowledge it provides is authoritative? If all you have is the URI and you want an authoritative description of the resource, there is a better way. With URIQA [1], you can do it with one request, even if you have a URIref with a fragid: MGET 78fa28b3-aab7-4551-b9b0-99e28fa87ecf Host: example.org URIQA-uri: http://example.org/78fa28b3-aab7-4551-b9b0-99e28fa87ecf#x891 (the header 'URIQA-uri:' specifically addresses the problem of fragids not being reliably conveyed to servers in the request URI) Now, the above URIQA request allows you to obtain an authoritative description of the resource in question, directly from the web authority (presuming the web authority is 'URIQA enlighted'). Of course, URIQA doesn't solve the inefficiency of obtaining a (kind of) representation of a secondary resource using just GET. Using URIs without fragids solves that problem. -- Before anyone jumps on me for supposedly "dissing" SPARQL, let me state that I think SPARQL is *great*, and I eagerly await a broad deployment of services supporting it. But there is a huge difference between a general query solution, which is inherently centralized, and globally ubiquitous, decentralized mechanisms for either (a) accessing representations of resources directly from a web authority of the identifying URI, or (b) bootstrapping the knowledge of an agent with authoritative knowledge from web authorities -- when in both cases all the agent has is the URI. SPARQL will provide a tremendous amount of utility, but it does not directly impact the httpRange-14 debate nor provide a solution for resolving URIrefs with fragids to representations. > Note that any DDDS lookup also includes the '#' - and hence > allows you to > sidestep this issue if needed. True. Though, unfortunately, I don't see DDDS ever taking off given the magnitude of the management hurdles that would be necessary to see global, ubiquitous deployment, such that it would provide the breadth and efficiency of access to representations presently provided by HTTP. I won't be disappointed if I'm proven wrong, as I think DDDS has alot of very nice features, but I'll be surprised if it ever really takes root on a global scale. Regards, Patrick
Received on Tuesday, 23 November 2004 09:44:51 UTC