From jackrabbit-dev-return-654-apmail-incubator-jackrabbit-dev-archive=www.apache.org@incubator.apache.org Mon Feb 07 22:12:41 2005 Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 84995 invoked from network); 7 Feb 2005 22:12:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 7 Feb 2005 22:12:41 -0000 Received: (qmail 38812 invoked by uid 500); 7 Feb 2005 22:12:40 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 38799 invoked by uid 99); 7 Feb 2005 22:12:40 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from Unknown (HELO blossom.betaversion.org) (62.140.213.100) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 07 Feb 2005 14:12:39 -0800 Received: by blossom.betaversion.org (Postfix, from userid 101) id 0FB2E96D28; Mon, 7 Feb 2005 22:08:10 +0000 (GMT) X-AntiVirus-Version: ClamAV 0.81/700 X-AntiSpam-Version: SpamAssassin 3.0.2 X-AntiSpam-Status: No (score=0.0/limit=7.5) Received: from [18.42.3.133] (DSPACE-12.MIT.EDU [18.42.3.133]) by blossom.betaversion.org (Postfix) with ESMTP id 6170496D21; Mon, 7 Feb 2005 22:08:07 +0000 (GMT) Message-ID: <4207E7D3.7080404@apache.org> Date: Mon, 07 Feb 2005 17:12:35 -0500 From: Stefano Mazzocchi Organization: Apache Software Foundation User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jackrabbit-dev@incubator.apache.org Cc: Eric Miller Subject: Re: Jackrabbit with RDF facilities References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Charles Severance wrote: > [snip] > > I tried to resist adding to this RDF thread but could not :) know that feeling very well :-) > A very small group in Sakai has been thinking about RDF and a Repository for > a long time (gives us a headache at times). I know how that feels too ;-) > I won't go on at boring length here, but my high level view is that there is > a basic role for RDF as "part of" JCR, but also a more interesting role of > RDF as a "peer to" and "compliment to" JCR. There are things which RDF can > naturally represent which are not natural fits for JCR. Very much agreed. > In one sentence, if JCR may be the flexible "file system" of the future, RDF > may be the flexible "relational database" of the future. But both > statements remain to be proven in real applications at real performance > levels. And it seems premature to even imagine that a standard could really > nail the requirements in the area at this point. Careful. I was not talking about 'adding RDF functionality to JCR', I strongly feel this is not only premature but dangerous at this point, we really want to get this spec out of the door (has been in the making practically forever!), all I was talking about was to add RDF functionality to "jackrabbit" as a testbed that might yield enough requirements to influence the next version of the JCR spec (whenever that comes). Also, if the RDF import/export/search are wrappers around existing JCR stores, you don't even have interoperability problems, they would work just like the RMI proxy thing. -- Stefano.