Re: working around the identity crisis

Patrick.Stickler@nokia.com wrote:
> 
>>-----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 doesn't and it shouldn't.

> 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.

Sparql will be describe a web service behavior. You can use that to 
query a graph to obtain particular information about a URI.

here is one potential workflow:

  1) you have "http://example.com/foo#bar"
  2) you lookup the sparql service for "example.com"
  3) you ask the query you want about "http://example.com/foo#bar"
  4) you get the RDF subgraph you wanted.

voila', issue solved.

another approach that avoids the web service lookup is

  2) you send a SEARCH request (following DASL) to http://example.com/
  3) you get the RDF subgraph you wanted

NOTE: DASL has a query language negotiation ability so it can work along 
with existing DASL implementations.

> 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.

of course not.

> 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?

see above.

> OK, so perhaps you are aware of a few SPARQL enabled knowledge 
> services, or you are able to somehow discover such services.

if would be enough to mandate that the DASL URL be the root one for a 
particular domain.

> 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?

this is another concern and affects your MGET solution as well. you 
can't trust the information you receive to be the information the server 
sent unless you had some sort of crypto validation of the channel.

> 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?

Not more effort than to locate the IP address associated to the virtual 
host you want to dereference today.

> If all you have is the URI and you want an authoritative description of 
> the resource, there is a better way.

better? there are many ways, true. Better is just a subjective measure.

> 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.

Your solution solves a few problems but does not foster the notion of a 
web of queriable data. I would much rather kill two birds with one 
stone, but I also agree that for some systems Sparql might be overkill 
so I don't really care which solution gets deployed, as long as we 
understand that the hash vs. slash debate is no longer needed and URIs 
with # are not harder to lookup any longer.

> --
> 
> 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, 

there is *nothing* in sparql that indicates how centralized and 
decentralized the system should be.

> 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.

current web servers and clients are not aware of Sparql nor are aware of 
MGET. Both are viable solutions, I personally prefer a Sparql-based one 
because once you solve one problem (dereferencing URIs with hashes) you 
solved all of them (cross-querying and discovery).

> 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.

don't know about the httpRange-14 debate, but it does provide a solution 
for resolving information related to URIrefs with fragids, also allowing 
you to control how much (and what!) information you retrieve from those 
sources.

-- 
Stefano.

Received on Tuesday, 23 November 2004 16:52:43 UTC