W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2003


From: <Patrick.Stickler@nokia.com>
Date: Tue, 20 May 2003 10:50:47 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B01B90E03@trebe006.europe.nokia.com>
To: <piotr@ideanest.com>, <www-rdf-interest@w3.org>

> -----Original Message-----
> From: ext Piotr Kaminski [mailto:piotr@ideanest.com]
> Sent: 19 May, 2003 23:34
> To: www-rdf-interest@w3.org
> Subject: RE: URIQA!
> Patrick,
> I'm happy to see a tighter spec (and implementation) of the ideas you
> proposed on the TAG mailing list a while ago.  Two quibbles, though.
> Why restrict semantic web servers to deal in RDF only?  I 
> would think the
> usual content type negotiation techniques could be used, so 
> that URIQA could
> be applied to any semantic web languages (e.g. XTM, N3, 
> robots.txt, etc.).
> Restricting the documents to RDF seems akin to forcing all
> representation-based HTTP messages to deal only in HTML.

Sorry for being unclear. I don't restrict semantic web enabled
servers with regards to serialization.

What is returned is an RDF graph. A set of RDF statements. To
be interpreted according to the RDF model theory.

Whether that RDF graph is expressed in RDF/XML, N3, NTriples,
XTM, or any other serialization is up to the server.

It is, however, a requirement that the server support RDF/XML
encoding and that RDF/XML encoding be the default encoding if
not otherwise specified via content negoatiation.

As you can see from the demo URIQA server itself, it provides
descriptions in RDF/XML, N3, and NTriples.

> Why restrict all replies to a concise bounded description? 

Because that is what pertains to the specific resource 
denoted by the URI.
> If an agent is
> interested in information "around" a resource, right now it 
> would have to
> issue a (potentially large) number of individual requests.  

There is no reason why a server cannot provide other query
services which allow for a broader scope of knowledge

The URIQA model is meant to represent that minimal amount of
standardized, common behavior that a SW agent can hope to expect
from any semantic web enabled server. Whether a given server
offers more functionality is outside the scope of the aims
and purpose of the URIQA model.

> Adding an
> optional "expansion depth" parameter to the GET query would 
> provide a simple
> way to grab information in bigger chunks.  

Server implementers are welcome to superset the minimal URIQA
functionality with value added services and behavior. I'm 
specifically trying to keep the focus and scope of the URIQA
model constrained to the essential core behavior that is 
necessary for all semantic web enabled servers in order to
achieve a trully global and open semantic web.

In fact, I need to qualify a number of the existing parameters
to the URIQA servlet as optional.

> Also, the given 
> definition of
> concise bounded description may not translate well to other 
> languages, so if
> you go for the first idea above, the spec would need more 
> general wording.

URIQA is based on RDF because RDF has a precise model theory.
Insofar as other languages fit that model theory or can be
translated to/from RDF, then they will fit into the URIQA model.

At some point, the SW needs to standardize on a common underlying
model theory, and I think that RDF is the best choice.

Though, the concept of a concise bounded description can be
generalized to "everything that is known by the server about
the resource without expounding on things known about other
(named) resources" -- i.e. just the facts about that resource
and nothing more -- which I expect one can capture in any
KR language. The definition provided in the URIQA specs are,
I agree, RDF specific but the general idea of a concise bounded
description is not specific or bound to RDF.

> I really like the proposal overall, though.

Glad to hear it. It is, of course, a work in progress and hopefully
will benefit from the input of others such as yourself.



> 		-- P.
> --
>   Piotr Kaminski (piotr@ideanest.com)
>   It's the heart afraid of breaking that never learns to dance.
Received on Tuesday, 20 May 2003 03:51:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:45 UTC