Re: extensibility

On Mon, Jun 21, 2004 at 12:13:44PM -0400, Eric Prud'hommeaux wrote:
> On Mon, Jun 21, 2004 at 04:06:23PM +0100, Seaborne, Andy wrote:
> > 
> > Eric,
> > 
> > The extensibility mechanism is by naming a feature set in the query.  I
> > think having named sets of features is a good idea, rather than always
> > having just a feature-by-feature naming.  It might be useful to be able to
> > enquire of a query processor what feature sets it supports.

Just for yucks, I implemented this as a profile. So there's a profile
that you can use for querying profiles. (Sorry 'bout the long namespace)
Q:
ns pq=<http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0699.html#>
require pq:profileQuery
profileQuery(pq:profileList ?p)
collect (?p)

A:
+---------------------------------------------------------------------------------------+
|                                                                                      p|
|---------------------------------------------------------------------------------------|
|                                             <http://www.w3.org/2004/05/06-Algae/#core>|
|                                           <http://www.w3.org/2004/06/20-rules/#assert>|
|<http://lists.w3.org/Archives/Public/public-rdf-dawg/2004AprJun/0699.html#profileQuery>|
+---------------------------------------------------------------------------------------+

The code is in the latest Federate at
http://www.w3.org/1999/02/26-modules/dist/Federate-1.tar.gz

> > There seem to be two usages:
> > 
> > 1/ Want to ensure a number of queries can be executed, the early ones may
> > not need a given extension so the app wants to knowion advance it wil be OK.
> > To do this, it needs to ask before a query is submitted.
> 
> Good point. That technique could be used to identify server that can
> or will do inferencing for you.
> 
> > 2/ In any given query, it is only the fetaures actually used that matter,
> > not the whole set (if named).  In this case, can't the query processor
> > detemine which features are needed simply by parsing the request?  If so,
> > then there is some neatness in declaring features but it isn't necessary is
> > it?  Or do required features modify the query/results in some way?
> 
> My main goal was to make sure a query server would know if it
> understood a request. Two folks could invent the "assert" action (say
> one took statements in n3 and another expected p s o) and the server
> would either not know which to expect or not even know that there
> *was* another one out there.
> 
> There may be mutually exclusive extensions. Perhaps the client
> wouldn't have thought a lot about its query and not reallize that
> there were some conflicts, but I bet it would be apparent to the
> person developing the server code. These requests would get a response
> from the server indicating the conflict and the client would have to
> think harder about what they were trying to ask..
> 
> Less importantly, maybe some proxy can do something clever with a
> cursory parsing of the query without knowing the full semantics of all
> the extensions. But then, maybe not.
> 
> > -------- Original Message --------
> > > From: Eric Prud'hommeaux <>
> > > Date: 21 June 2004 08:59
> > > 
> > > I've done a bunch of thinking over the weekend about extensibility and
> > > how it interacts with streamability. I've prototyped a solution in
> > > algae. 
> > > Take a peek at the Algae doc on profiles and extensibility [1] and an
> > > extension (implemented, but poorly documented at this point) on adding
> > > rules to query [2]. It uses and demonstrates the extensibility
> > > mechanism. 
> > > 
> > > [1] http://www.w3.org/2004/05/06-Algae/#extensibility
> > > [2] http://www.w3.org/2004/06/20-rules/
> 
> -- 
> -eric
> 
> office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
>                         Shonan Fujisawa Campus, Keio University,
>                         5322 Endo, Fujisawa, Kanagawa 252-8520
>                         JAPAN
>         +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
> cell:   +1.857.222.5741 (does not work in Asia)
> 
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.



-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.