RE: URIQA questions

> -----Original Message-----
> From: ext Benja Fallenstein [mailto:b.fallenstein@gmx.de]
> Sent: 08 July, 2003 01:55
> To: Thomas B. Passin
> Cc: www-rdf-interest@w3.org
> Subject: Re: URIQA questions
> 
> 
> 
> 
> Hi,
> 
> Thomas B. Passin wrote:
> > [Benja Fallenstein]
> > 
> >>Ok. So URIQA makes the following design decisions:
> >> ...
> >>- 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.
> > 
> > But for any resource that did get returned in the concise bounded
> > description, you can ask for a concise bounded description 
> of __it__.
> 
> But only if it's in the authority of the same server. So if you have
> 
>      ex:Foo   rdfs:subClassOf   ex:Bar
>      ex:Bar   ont:warning       "Hazardrous!"
> 
> everything is fine, but if it is
> 
>      ex:Foo   rdfs:subClassOf   fy:Bar
>      fy:Bar   ont:warning       "Hazardrous!"
> 
> (in the knowledge base of the ex:... server) you cannot access the 
> latter triple (assuming that the fy:... server doesn't also 
> have it). It 
> cannot be considered authoritative knowledge about fy:Bar, 
> but it can be 
> considered authoritative about ex:Foo!

Right. If you asked for a concise bounded description of ex:Foo,
you would not get any statements about fy:Bar.

But you could ask the authoritative server about fy:Bar.

Whether ex:Foo and fy:Bar have the same authoritative server
is another issue.

However, if the authoritative server for ex:Foo also provides
a general query interface, it may also both maintain and
can provide information about fy:Bar in general queries.
Those general query results, however, would not be authoritative
concise bounded descriptions.

> Worse, if you have
> 
>      ex:Foo   rdfs:subClassOf   
> <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi>
>      <urn:urn-5:gK0wObL42bRyFllUsU+8cPL5cQBi>  ont:warning  
> "Hazardrous!"
> 
> there is no way to get the latter triple, even if it is what 
> the person 
> who minted the URN thought, since there is no authority for 
> urn-5 URIs.

Which is precisely what has motivated me to propose an
alternative way to accomplish the goals of URNs. C.f. 

http://lists.w3.org/Archives/Public/uri/2003Jul/0005.html

Using HTTP-URNs as thus defined (aka PURLs) rather than urn: URIs
would allow you to derive the fullest benefit from not only URIQA
but the general web architecture already globally deployed.

> I happen to use this, so URIQA really doesn't work for my data.

Understood. URIQA is an extension to the Web in order to
enable the Semantic Web. In both cases, HTTP is a foundational
technology. URI schemes that are not meaningful to HTTP are
ill suited not only for the Web, but also for the Semantic Web.

> > If the server knows about it, you get what you need.  If 
> the server does not
> > know about it, you would not get any information about it 
> even with a fuller
> > query. 
> 
> Hey, I gave two cases at the beginning of this thread where 
> this isn't 
> the case, and Patrick essentially said, "you cannot do this and it's 
> intentional."
> 
> 1st case: The URI I have is the object of a triple containing the 
> information I need.
> 
> 2nd case: The information I need is more than one step away 
> from the URI 
> I have, and there's another URI on the way which is in the 
> authoritative 
> domain of another server (or no server at all).
> 
> In both of these cases, a fuller query would return the 
> information alright.

Exactly.

URIQA is intended to provide a simple but powerful core
of functionality that will be deployed on every SW server
on the planet (and perhaps beyond).

As such, it cannot, and should not, try to address every 
possible (or even common) scenario.

URIQA is a hammer. If you have a screw, well... sorry.

Cheers,

Patrick

Received on Tuesday, 8 July 2003 04:01:03 UTC