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

There could of course be an inverse hasHomePage property, but why add 
this if it isn't necessary, except for URIQA?

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.


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.

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.

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.

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

- Benja

Received on Saturday, 5 July 2003 19:31:28 UTC