Paul Sandoz <[EMAIL PROTECTED]> writes:
>       
> >>      When a searchable address book is selected
> >>      the 'search bar' should be displayed.
> >
> >I'm not quite sure what you mean by this.
> >
> 
>       Hmm... that a search tool bar should become
>       visible if not already so, so that a user
>       can enter the search query.

OK, that makes sense.

> >>    o The RDF directory data source needs a query
> >>      command that takes as an argument the search
> >>      critera defined as a boolean expression tree.
> >>      
> >>      - The data source will be responsible for 
> >>        for passing the search arguments to the query
> >>        interface on the RDF directory resource conponent
> >>        and listening to the results which are then
> >>        asserted. Thus it is asynchronous in operation.
> >
> >So if I understand you correctly, this is really an optimization: that
> >is, a generic helper class could do the entire boolean expression
> >processing on _any_ RDF datasource.  But this allows datasources which
> >understand expressions themselves (eg LDAP) to do it much quicker.
> >Right?
> >
>       
>       I suppose it could, but i do not understand fully
>       what you mean.
>       
>       The 'generic helper' would have to understand one or
>       more of uris, statements and hierarchical relations of
>       on the datasource.

I'm not sure why it needs to understand hierarchical relations.  Can
you clarify?

>       However, i think it could be done quite easily for
>       the js LDAP datasouce because of its search based
>       nature.
>                       
>       It is not just an optimization because the query
>       can change the 'normal' hierarchical relationship
>       of an RDF graph. For example it should be possible
>       to do a query on the Address Book Container, this
>       flattens and contracts.

How can a query change the hierarchy in an RDF graph?  I'm really
confused now.  

>       <offtopic>
>       In general it would be interesting if an SQL type
>       query could be performed on an RDF datasources.
>       http://www.intellidimension.com/RDFGateway/gateway.asp
>       </offtopic>     

That is cool!  On a related tangent :-), someone (whom I've been
derelict in getting review or help for :-( ) has written a mozilla
datasource which talks to a PostgresSQL database.

> >>        The query command should unassert previously
> >>        returned cards.
> >
> >Why is this necessary?  Won't the newly created listener not know
> >about any previously returned cards?
> >
> 
>       Query 1 returns set A of cards
>       Query 2 returns set B of cards.
>       A n B = 0
>       
>       How does affect an RDF datasource. Is the
>       result of two queries returning sets A and B of
>       cards respectively A u B statements?
>       
>       I don't know enough about this really.

RDF assertions are statements.  As far as I know, if you're listening
to a datasource, you need to parse the assertions you get and see if
they're ones that you care about.  Since multiple queries may be
happening simultaneously, I don't believe you're guaranteed that the
assertions you see are necessarily related to your query.  It sort of
sounds as though you and I are talking about asking the datasource
different types of questions.  I guess I'm assuming that the
datasource object may be shared and will represent the state of the
universe, not private and representing the state of the query.  But
maybe I'm off-base.

> >>      - A general linear search query component is 
> >>        available for directories that do not support
> >>        the query interface. This means that existing
> >>        local address books may also be searched.
> >
> >If this only exists to deal with the exist local addressbook, wouldn't 
> >it make more sense to simply write an instance of the query interface
> >for the local addressbook that does more clever stuff with
> >datastructures in order to avoid doing a linear search?  Note that I'm 
> >completely naive about how mork & the local address book work, so this 
> >may not be practical.
> >
> 
>       Yep that right. I think of it as a helper for
>       directories that have not yet implemented
>       specific query functionality.
>       
>       It would definitely be more efficient to go to
>       the mdb and mork level, but yuck!
>       I am suspect on mork's level of efficiency and
>       unsure of its query capability.

I assume ducarroz would know more about this, since he wrote the
original autocomplete-against-mork code.

>       What would be really cool in a set of data base
>       connection interfaces (like JDBC or SDBC (star open office))
>       and an implementation to MySQL.
>       (interestingly enough people have been talking
>       about an OpenLDAP back end to MySQL, the 
>       implications of which start to make me dizzy with
>       what can be connection to what!)

*chuckle*

Dan

-- 

Reply via email to