Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> >> 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
OK, I think I see what you mean now. How about this: instead of
having a single set of QueryChildCard attributes on the moz-abdirectory://
URL, I think the right thing to do is to define a way to represent
each query as a URI, and then assert the QueryChildCard properties on
the relevant URI. This way you can have an arbitrary number of
separate, concurrent searches under the moz-abdirectory:// namespace.
This is exactly the way the LDAP datasource works. You could
probably even borrow most of your URL syntax from the syntax of LDAP
search URLs (RFC 2255).
Given that writing the code to generate and parse such URIs is
probably a bunch of work, for the time being you could probably just
use opaque URI handles such as:
moz-abdirectory://searches/search-1
moz-abdirectory://searches/search-2
...
Thoughts?
>
> 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.
Yes, that's exactly what I meant.
> 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..)
Agreed; this is very cool. As far as generic use of RDF, some very
interesting stuff to look at is the Dublin Core metadata work.
<http://dublincore.org/resources/faq/> Once upon a time, there was a
theory that we should replace the ad-hoc NC-rdf vocabulary used by
much of the browser with something Dublin Core-based, to allow for
better interoperability. Last time I looked at this, that seemed like
it might be not terribly practical, because to express a bunch of the
semantics in the NC-rdf vocabulary well would require using the
Qualified Dublin Core, and this adds a non-trivial amount of
complexity.
> >> >> 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.
I think the right solution here is to use multiple subjects rather
than multiple predicates, as described above.
Dan
--
