URIQA and value added functionality

> -----Original Message-----
> From: ext Emmanouil Batsis [mailto:manos_lists@geekologue.com]
> Sent: 13 October, 2004 21:17
> To: Eric Hanson; Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: www-rdf-interest@w3.org
> Subject: Re: URIQA thwarted by WebDAV properties?
> 
> 
> On Tuesday 12 October 2004 14:43, you wrote:
> > When you want to search the metadata, you can use the SEARCH
> > operation.  It's extensible so you can use any search grammer
> > you want to (think XQuery/RDQL/...)
> 
> Now this is one of the two things i miss from URIQA: a way to 
> "plugin" a query 
> language and give clues for the URIQA server to identify that 
> language. 

It's important to note that just because the URIQA spec defines
a simple, efficient, minimal set of functionality, that does 
not preclude there being value added functionaly provided by
any given server.

An early design for URIQA included the ability to include a
general query as the body of the request, but that was dropped
as it was not motivated by the core requirements for URIQA.

Also, for a given server, one may have full URIQA support,
both for the URIQA methods as well as a /uriqa? servlet
portal, and then in addition to that, have a /search? or
/query?, or /sparql? portal that can accept more general queries.

And an MGET inquiry about the server could provide a description
of the server, including all available services, and the descriptions
of those services could specify their functionality (e.g. OWL-S).

Thus, in this regard, URIQA is not constraining at all.

It simply doesn't include everything plus the kitchen sink.

And the reason for that is that URIQA is intended to be "light"
and implementable with minimal effort, so that adoption and
support of URIQA functionality incurs a minimal cost, both
for deployment and at run-time.

> The 
> other is that URIQA, in it's current form, is limited in 
> responding with a 
> single CBD per response. 

Well, since the URIQA interface provides for asking about
a single resource, it does not need to provide for returning
multiple descriptions.

Note, however, that it would be easy to add additional (proprietary)
support for alternate forms of description, with CBD the default.

Likewise, one could add (proprietary) support to the /uriqa?
service portal interface to allow the 'uri=' parameter to
take a sequence of multiple whitespace separated URIs and then
use e.g. multipart MIME to group the individual descriptions
together in the response.

Also, a separate, more general query interface could provide
for multiple descriptions -- e.g. in response to a SPARQL
DESCRIBE query with multiple targets, or simply if provided
with a list of URIs to describe.

Again, this is something that URIQA is not intended to provide,
insofar as the core, "standard" functionality is concerned,
and providing such functionality will result in URIQA growing
in complexity until it rivals a fully general query solution.
Note that the Nokia Semantic Web Server includes additional
functionality not defined as part of the core URIQA solution.

The point is that not every server needs a fully general query
solution. But it is expected that most servers will benefit from
essential, basic query functionality such as defined by URIQA.

Those that need more, can provide more -- in addition to URIQA.
And in fact, for those services that also include more general
query facilities, the URIQA functionality will most likely be
implemented simply as a front-end to that broader solution.

URIQA is complementary to e.g. SPARQL. Both are important. But
not all systems will need (or want) a full SPARQL solution.
 
> I'm trying to figure out the best 
> way to implement 
> this while still playing well with URIQA and would be very 
> interested in 
> thoughts on this...

Hopefully the above comments will prove helpful.

Cheers,

Patrick

 
> Manos
> 
> 
>

Received on Thursday, 14 October 2004 05:52:02 UTC