RE: working around the identity crisis

> -----Original Message-----
> From: ext Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: 23 November, 2004 18:53
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: www-rdf-interest@w3.org; public-esw-thes@w3.org
> Subject: 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"

How? Where? On example.com? Again, how?

(I a little bit playing devil's advocate here... you haven't
 fully addressed the 'bootstrapping' requirements)

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

WebDAV DASL?

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

Do you mean using DASL to access a SPARQL savvy query service?


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

Well, that's really true of any web server/client interaction, and
true whether you are asking the web authority of the URI or some
third party. 

Thus, my point about asking for an authoritative description from 
the actual web authority versus some third party is still valid.

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

Yes, but it constitutes an explicit step that a web client
making a URIQA request need not concern itself with. It's
about layering, and not having to deal with operations that
should be handled below the layer of focus for a given
client.

There is, again, the issue of authority. When you use DNS to
obtain the IP address of some symbolic domain name, you are
getting that IP address from the owner/manager of that domain,
not from some arbitrary third party.

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

???

You may want to review the URIQA spec and numerous discussions
about URIQA.

URIQA is *specifically* about providing for a web of queriable data.

URIQA does not alleviate the need for, or compete with more generalized
query solutions such as SPARQL, but provides a bootstrapping mechanism
which makes it more likely that clients can locate and utilized solutions
such as SPARQL. 

In fact, the approach we use in implementing URIQA is to redirect
URIQA requests to a query service portal which serves as the 
knowledge authority for the resource in question (even if the
query portal is hosted on an entirely different server).  And
such a query portal could also provide full support for SPARQL.

URIQA and SPARQL are complimentary.

I was simply trying to point out that SPARQL alone does not
address either (a) the bootstrapping problem or (b) resolution
of URIrefs with fragids to representations.

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

The hash vs. slash debate has never been a significant issue 
for either SPARQL or URIQA.

It does, though, remain an issue for more traditional access
to representations, such that with fragids, direct access to
representations is not possible.

Apples and oranges. URIQA and SPARQL have nothing (explicitly) to 
do with representations of resources.

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

Fair enough. Though I think that it fosters a more centralized
way of thinking, which is true for most knowledgebase/database
centric query models.

URIQA is explicitly web authority centric, even if a given
web authority defers processing of queries to a more centralized
query service which acts as the knowledge authority for a 
number of web authorities.

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

Again, URIQA and SPARQL are complementary. 

And you still haven't covered the issue of bootstrapping/discovery.

SPARQL offers no solution to such operations.

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

Again, it's not the whole solution. If all you have is the URIref
with fragid, you are dead in the water. Unless you *know* which
SPARQL savvy service to query, and know that you will get 
authoritative/trustworthy knowledge, you get nowhere.

SPARQL is but a piece of the puzzle, as is URIQA. They work
well together.

Regards,

Patrick

Received on Wednesday, 24 November 2004 09:14:26 UTC