>> >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?
>
How else can the helper class evaluate the expression?
It needs to get data from the datasource this data may
need to be further evaluated.
>> 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.
>
Hmm... so am i.
A crude example of an RDF graph of address books
is shown below:
abdirectory://
[Child] abmdbdirectory://abook.mab
[ChildCard] abmdbcard://abook.mab/Card1
[ChildCard] abmdbcard://abook.mab/Card2
[ChildCard] abmdbcard://abook.mab/Card3
[Child] abmdbdirectory://history.mab
[ChildCard] abmdbcard://history.mab/Card1
[ChildCard] abmdbcard://history.mab/Card2
[ChildCard] abmdbcard://history.mab/Card3
A query could result in:
abdirectory://
[QueryChildCard] abmdbcard://abook.mab/Card1
[QueryChildCard] abmdbcard://history.mab/Card3
I suppose you could consider it an optimization if the
abdirectory:// resource performs the query rather than a
helper traverses the RDF graph to return the same result.
But a query operation seems more than that. A really
crude example: is C just an optimization for writing in
machine code?
I think i am even more 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.
>
Yep.
Its good to see datasources being written for stuff
which is not so directly related to viewing.
There seems to be a three tier pattern in relation
to data sources:
1. Data API (C/C++ API or interfaces)
2. RDF Data Resource (interfaces)
3. RDF Data source (RDF schema)
which can give great felxibilty and choice for
a developer.
I also like the concept of the Aurora project.
This is where generic querying/searching could be
very useful. Imagine having a 'virtual folder' which
is associated with a query which dynamically updates
when new content maching the query is asserted.
(e.g. virtual mail folders, or for news casts etc..)
>> >> 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.
>
I think understand what you say.
I am unsure how the listener who initiated the query
relates to the assertions associated with the query
results.
If there is only one predicate, property, associated with
query statements, e.g. 'QueryChild' then it needs to be
ensured that these statements are related to the last query
on a subject.
Multiple queries should not result in a union.
Alternatively we could create a new predicate for
each query, QueryChild:<Query>. Where the <Query>
is an instance of or reference to the query parameters.
For the address book i am not sure which one is best.
Maybe its better to reuse the 'ChildCard' predicate?
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219
