RE: URIQA questions

> -----Original Message-----
> From: ext Benja Fallenstein [mailto:b.fallenstein@gmx.de]
> Sent: 07 July, 2003 23:58
> To: Stickler Patrick (NMP/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: Re: URIQA questions
> 
> 
> 
> Ok. So URIQA makes the following design decisions:
> 
> - It does not provide all authoritative information about a resource; 
> instead, it provides an somewhat arbitrary, but well-defined 
> subset that 
> is judged to be reasonable in many cases.

I think we disagree in what "about a resource" means.

No, it does not provide all triples in which the resource
participates, only where the resource is the subject.

And the selection of what is provided in a concise bounded
description is hardly arbitrary. 

> - It doesn't provide a way to query a server for anything 
> else than this 
> subset of the authoritative information about a URI under the 
> server's 
> authority.

Correct. It does not attempt to specify a general query API.

For the core URIQA model, the only argument is a single URI.

> - In particular, it doesn't provide a way to query the server for 
> additional information that may be necessary to understand the 
> abovementioned subset of a URI's authoritative information.

Yes and no. It does not provide a way for one to obtain
descriptions of resources from a server for which it is not
the authoritative server; but it does expect that, ideally,
all authoritative servers will understand URIQA requests
and provide descriptions of the resources denoted by URIs
hosted by those servers.

> I think I understand these design decisions. I was misled by 
> my original 
> assumptions about the goals of URIQA.
> 
> Thanks for your clarifications.

You're most welcome. 

Cheers,

Patrick


> - Benja
> 
> Patrick.Stickler@nokia.com wrote:
> > 
> >>-----Original Message-----
> >>From: ext Benja Fallenstein [mailto:b.fallenstein@gmx.de]
> >>Sent: 06 July, 2003 02:30
> >>To: Stickler Patrick (NMP/Tampere)
> >>Cc: rdf-i
> >>Subject: URIQA questions
> >>
> >>
> >>
> >>Dear Patrick,
> >>
> >>reading the URIQA spec at
> >>
> >>http://216.239.39.100/search?q=cache:HHP1uPSr1EUJ:sw.nokia.com
> >>/URIQA.html+uriqa&hl=en&ie=UTF-8
> >>
> >>(for some reason I cannot access sw.nokia.com at the moment), 
> > 
> > 
> > Our firewalls got upgraded last weekend and for some reason the
> > routing to that particular server got munged. It's being fixed.
> > Sorry.
> > 
> > 
> >>I'm left 
> >>wondering about two points. I would expect to be able to use 
> >>the URIQA 
> >>interface to query any information I need about a resource from its 
> >>authoriative server, 
> > 
> > 
> > Well, any authoritative information, at least. Not necessarily
> > any information that is available everywhere on the SW on ever
> > server.
> > 
> > 
> >>but if I'm not missing something, this 
> >>would not be 
> >>possible.
> >>
> >>
> >>First, the directionality in concise bounded resource 
> >>descriptions seems 
> >>an arbitrary restriction that means I cannot query many, 
> but not all 
> >>statements about a resource. 
> > 
> > 
> > A concise bounded restriction is entirely resource-centric. It's
> > not meant to replace or compete with more general query services
> > or functionality, even those operating on the same knowledge
> > base.
> > 
> > It is a lowest common denominator which can be broadly and 
> > effectively implemented by all semantic web enabled servers,
> > regardless of what additional functionality those servers might
> > offer.
> > 
> > We can't expect every web server on the planet to implement an
> > identical high level query API. Even if such a standard API
> > exists (and there are folks working on it) we can't expect every
> > web server to provide it, yet the URIQA model is both simple
> > enough yet powerful enough to provide a common, standardized
> > core of functionality for resource discovery that will enable
> > SW agents to obtain authoritative knowledge about resources
> > based solely on their URIs.
> > 
> > 
> >>Unless the vocabulary in use has been 
> >>designed to be used with URIQA, I may be missing out on something 
> >>important. For example, consider this graph:
> >>
> >>     <http://example.org/>   homePageOf   
> >><http://example.org/institute>.
> >>     <http://example.org/institute>   rdf:label   "The Foo 
> >>insititute" .
> >>     <http://example.org/institute>   founded     "2003-03-17" .
> >>
> >>If I start from http://example.org/, all is fine; I can find the 
> >>institute URI and then query its own description to get the 
> name and 
> >>founding date.
> >>
> >>But if I start at http://example.org/institute, I have no way 
> >>of finding 
> >>out about its home page, even though the semweb server 
> knows about it 
> >>and this can certainly be considered crucial information 
> >>regarding the 
> >>institute.
> > 
> > 
> > With most SW and knowledge representation operations, 
> ontology counts
> > for alot.
> > 
> > 
> >>There could of course be an inverse hasHomePage property, 
> but why add 
> >>this if it isn't necessary, except for URIQA?
> > 
> > 
> > Well, this of course presumes that you know about the 
> property homePageOf.
> > 
> > 
> > 
> >>It would seem much better to make the concise bounded 
> description go 
> >>both forward and backward-- i.e., also include statements in 
> >>which the 
> >>queried URI is an *object*, and so on.
> > 
> > 
> > A concise bounded description is intended to be an optimal amount
> > of knowledge for efficient interchange. If you include such 
> a reverse
> > lookup, the result graphs can quickly grow to be huge, depending
> > on the resource. 
> > 
> > E.g., if you want a description about a URI denoting a 
> classificatory
> > term, in order to get its labels, description, etc., including all
> > statements where it is the object could make the results jump from
> > a dozen or so statements to millions of statements, particularly
> > if inference is used (which is to be expected in many/most cases).
> > 
> > E.g. if subclass inference is employed, and one were to submit
> > a query for rdf:Resource, one would get a statement for every
> > resource that exists in the knowledge base (in addition to the
> > rest of the relevant statements) since it can be infered that
> > 
> >   Ax ( x rdf:type rdf:Resource )
> > 
> > etc.
> > 
> > Even if inference is not employed, the resulting graphs can be
> > very large (unexpectedly large) and could easily overload smaller
> > agents.
> > 
> > 
> > 
> >>Second, the concise bounded description may include URIs not 
> >>under the 
> >>authority of the same web server, and yet the knowledge this 
> >>server has 
> >>about that URI may be crucial in interpreting the meaning of the 
> >>statements served by the server. We can query this 
> >>information using the 
> >>URIQA servlet, but the reason for the HTTP extension to 
> exist in the 
> >>first place is that we may not know the location of the 
> authoriative 
> >>servlet in advance-- yet the HTTP extension doesn't seem to 
> offer any 
> >>way to discover it.
> > 
> > 
> > Sure you do, if the URI includes a web authority component, such as
> > an http: URI.
> > 
> > If you have http://example.com/foo and you execute a GET with
> > URI-Resolution-Mode: Description (per the URIQA model) and the
> > resulting description references http://anotherexample.com/bar
> > then you can execute another GET with URI-Resolution-Mode:
> > Description to get the description of the second resource, etc.
> > ad nauseum until you have all the information you need.
> > 
> > Note that the real core of URIQA is not the Servlet API that is
> > defined for the reference implementation, but the extensions to
> > the Web architecture that allow one to query a semantic web
> > enabled server based in the URI alone.
> > 
> > 
> >>As an example, consider this graph:
> >>
> >>     <http://example.org>   ex:hasCreator   _:x .
> >>
> >>     _:x   foaf:name       "Jane Tripleson" .
> >>     _:x   foaf:mailbox    <mailto:triples@example.org> .
> >>
> >>This is straight-forward enough, but consider this graph:
> >>
> >>     <http://example.org> ex:hasCreator
> >>     <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi> .
> >>
> >>     <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi>
> >>         foaf:name   "Jane Tripleson" .
> >>
> >>     <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi>
> >>         foaf:mailbox   <mailto:triples@example.org> .
> >>
> >>(A urn-5 is just a random number which is long enough to be 
> >>unique, see 
> >>http://www.iana.org/assignments/urn-informal/urn-5 .)
> >>
> >>This graph is perfectly valid-- but using URIQA, as far as I 
> >>can see I 
> >>can only retrieve a triple that means exactly nothing to me, 
> >>without a 
> >>way to find out more.
> > 
> > 
> > Well, something like DDDS along with HTTP+URIQA would be needed
> > if you are working with URNs.
> > 
> > Alternately, and what I and others recommend, you would use PURLs.
> > 
> > The combination of PURLs with URIQA make for a powerful solution
> > that IMO nearly eliminates any need for the urn: naming scheme
> > (with the single exception of those who need/want URIs that are
> > entirely independent of any identifiable organization)
> > 
> > If you were to use, instead of 
> urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi,
> > something akin to 
> http://purl.example.com/urn-5/gK0wObL42bRyFllUsU+8cPL5cQBi
> > then you could simply do
> > 
> > GET 
> http://purl.example.com/urn-5/gK0wObL42bRyFllUsU+8cPL5cQBi HTTP/1.1
> > URI-Resolution-Mode: Description
> > 
> > to get a description of the resource, which could also include
> > statements about which representations that URI would redirect to,
> > etc. in addition to all other authoritative knowledge about the
> > resource.
> > 
> > Services could be founded for the creation and maintanance of PURLs
> > and their associated metadata, which have (nearly) all of 
> the desirable
> > qualities of URNs but exploit the web architecture, with semantic
> > web extensions such as URIQA, to the fullest.
> > 
> > 
> >>Ok, you could use
> >>
> >>     GET urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi HTTP/1.1
> >>     Host: something
> >>
> >>using Host: to get this through proxies, but this would seem 
> >>to violate 
> >>the HTTP spec--
> >>
> >>     The Host field value MUST represent the naming authority
> >>     of the origin server or gateway given by the original URL.
> >>
> >>Besides, this wouldn't help with URIs containing fragids.
> > 
> > 
> > Don't get me started about fragids ;-)
> > 
> > 
> >>IMHO URIQA should simply provide the URI of its servlet in its HTTP 
> >>responses. (If this were also included in the response to 
> >>OPTIONS, the 
> >>use of URI-Resolution-Mode could even be completely avoided, using 
> >>OPTIONS to find the servlet URI, then using the web service 
> >>interface; 
> >>it seems to me that if URIQA clients supported this, 
> servers could be 
> >>more easily configured for URIQA-- just add one header to 
> the OPTIONS 
> >>response and plug in a normal servlet or CGI.)
> > 
> > 
> > This would, though, result in SW agents having to make 
> multiple calls
> > to the server for every single request for information.
> > 
> > SW agents should be able to surf the semantic web, from description
> > to description, just as easily as web agents can surf the 
> traditional
> > web, from representation to representation.
> > 
> > This requires analogous behavior defined for semantic web enabled
> > servers by the architecture. The header 
> URI-Resolution-Mode: provides
> > this in an elegant manner, by simply indicating to the 
> server whether it
> > should resolve requests in terms of descriptions or representations.
> > 
> > Otherwise, interaction between agents and servers is 
> roughly identical.
> > 
> > SW agents should not be made second-class citizens of the 
> web by having
> > to make two system calls where other traditional agents 
> only need make
> > one.
> > 
> > Cheers,
> > 
> > Patrick
> > 
> > --
> > Patrick Stickler
> > Nokia, Finland
> > patrick.stickler@nokia.com
> >  
> > 
> > 
> 
> 
>

Received on Tuesday, 8 July 2003 04:08:21 UTC