Below is a posting from David McCusker who is working on the backedn of
From: Rys (David) McCusker <[EMAIL PROTECTED]>
Subject: Re: repository access protocol Re: [Design] Knowing when you've
Tim Hoffman wrote:
> Any hints as to how RDF will bu used in conjunction.
that is one of the things that makes database design hard.
Specifically, jumping through that hoop is one of the
degrees of difficulty making the problem harder to solve.
Additional degrees of difficulty include things like:
*make it network protocol centric
*make it fast and scale very large
*use existing technology
*write custom code for optimization
*let the application coders see Python interfaces
*make the local case faster than their remote case
*make a centralized authorization case work
*make the decentralized P2P good and attractive
but that's just a sample. As you can see, it's hard to
do justice to every priority. In many cases, we cannot
give full-blown support to every iota of associated
features one might think of in conjunction with one of
the priority items. So we need some restrictions.
In the case of RDF, we want to support it, and yet we
do not want to compromise any of the priorities in pursuit
of every feature folks associate with RDF usage.
so our solution is that and RDF style application can see
any of our content as if it was native to RDF. In other
words, there is a mapping from our content to RDF. So you
can get our content exported to RDF, among other things.
Even more than this, some of Chandler application code
wants to use RDF centric schema systems, with direct
expression of this met information available at runtime.
Katie has proposed a good an interesting system we will
used to represent RDF meta information through python
interfaces, by putting this information into classes,
so RDF reflection features are visible as python APIs.
However, consider some random feature of another RDF
environment or application, call his feature X. we might
not support X in Chandler -- at least, there might
be no efficient way to do it, and we won't care.
this means we do not aim to do every kind of RDF feature
well in Chandler. We only aim to let the data we support
the view in RDF terms. So there is a mapping in one direction
outward to RDF, but there is not always a mapping the other
way inward from RDF.
> ie will RDF be used to map/find/query things in the
we had not considered to using RDF specific query language
so far in discussions. The repository access protocol
will support more than one query language, and provide
means to ask which one is supported in a given server. So
in principle, a RAP server might use RDF in a query language
and advertise this in the protocol dynamically.
on the topic of query languages, we are not much further
along than committing to more than one query language
selectable dynamically at runtime.
> and would this map to RAP access patterns ?
I imagine it's possible to implement some kind of RDF
system which is implemented in terms of RAP, because RDF
is notorious for making no guarantees about performance,
so one might iterate over every data item in a database
in order to satisfy an RDF query.
>(probably not using the correct terminology here)
I'm not very particular about fashionable jargon as long
as I understand what you mean. I prefer the informal
approach to describing things anyway.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
On Fri, 2003-02-21 at 10:30, Shane Hathaway wrote:
> On 02/20/2003 09:06 PM, Tim Hoffman wrote:
> > In case your not aware Chandler OSAfoundation is basing their
> > new PIM on RDF/ZODB/Python etc...
> > if you haven't already it might be worth having a look at how they see
> > RDF fitting into the picture.
> > http://www.osafoundation.org/Chandler_rel._0.1.htm
> Wow, that's exactly what I was looking for. I guess I'll find out more
> when they open up their CVS. I hope it's soon. If they've had any
> difficulty persisting ZODB objects to RDF, I bet I could help them.
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -