Re: Ontology-based portals - RDF, LDAP, Xindice (was: java@apache)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El viernes, 26 dici, 2003, a las 07:06 Europe/Madrid, Noel J. Bergman escribió: J.Pietschmann wrote: Noel J. Bergman wrote: This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. Sounds awfully close to a Maven project.xml. As you note, sounds close to a lot of different things. There should not any dependence on Maven, although Maven could populate the system for projects that are using it. However, the key thing above, and seemingly missing from Maven's Project descriptor, is ontology, so I am curious to see Henri's approach. Ontology is a useful, but damned dangerous word :-) The name of Sam Ruby's blog, as well as a lot of its content, says it all about the meta-data vs data discussions. I was involved in couple of Esprit project about knowledge acquisition and domain ontologies some time ago, and my personal conclusions on the efforts, much like Sam's is that It's just data ( http://intertwingly.net/ ) I liked a lot Stefano's comment on semanticsheets ( http://www.betaversion.org/~stefano/linotype/news/26/ ), in which he used the Library of Babel story that the web always evokes on me. Two weeks later, Jon Udell quotes him ( http://weblog.infoworld.com/udell/2003/08/08.html#a773 a RSS/RDF epiphany ): The mental model that XML promotes is basically a tree of couples. The mental model that RDF promotes is basically a collection of triples. Sounds familiar doesn't it? The Hierarchical vs. Relational war over again 30 years later? Danny Ayers says here ( http://dannyayers.com/archives/001693.html ) in response to the previous entry: structural things* * searching for a word that's not overloaded - something that would mean elements in the non-XML sense or entities and relationships I think a RDF vs LDAP vs XIndice discusion would be again a part of the same old war. Regards Santiago We would want some nice means for aggregating and dynamically managing the data, but fortunately we have a ready standard for dealing with the content: LDAP. The nice thing about standards is that there are so many to choose from. There are also RDF/RSS/DC and a variety of other XML based metadata languages (Topic Maps would fit almost as well as LDAP). Yes. However, although there are certainly plenty of XML formats from which to draw, or even to support, few might be considered a standard, and there are even fewer such standards when it comes to a data-access interface for dealing with hierarchical, attributed data. LDAP is one; an XPath/XQuery-based XML DB server would be another route. RDF (http://www.w3.org/RDF/) is a W3C specification for the ontology aspect of the Semantic Web. The RDF syntax (http://www.w3.org/TR/REC-rdf-syntax/) has a decent mapping to LDAP. This is not a new idea, you can see from: http://lists.w3.org/Archives/Public/www-rdf-interest/2000Jan/0048.html http://rdf-ldap.ucpel.tche.br/ http://www.openldap.org/lists/openldap-software/29/msg00571.html http://lists.oasis-open.org/archives/dsml/29/msg00021.html An alternative to LDAP could be Xindice (http://xml.apache.org/xindice/). At least one of the Xindice developers is subscribed to this list. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/7A+qZAeG2a2/nhoRAqnfAJ9Qay6h3Jw0gBBY9SvjthOsO+1wEgCfS140 iIvPNIhTOWxnFJ6nl7r4e9Q= =XHOW -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java@apache
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El viernes, 26 dici, 2003, a las 01:32 Europe/Madrid, Henri Yandell escribió: On Thu, 25 Dec 2003, J.Pietschmann wrote: Noel J. Bergman wrote: This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. Sounds awfully close to a Maven project.xml. This is what I've spent some moments today playing with. Building a portal.xml and a set of ontology xml's around maven project.xmls. Then a series of xsl things to make a static site. Having different views of the projects and project components looks an interesting idea (not just for java). This stroke me of Noel's proposal of keeping jakarta as a meta project, instead of an umbrella project. I.E., having jakarta as a coordinating and marketing place, where different java project would crosspollinate and coordinate together, but free of oversight concerns, which would be addressed separately by each project. While I'm not sure something like this would work, neither how would it work, I think exploring the possibility is worthwhile. Regards, Santiago Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/7BBIZAeG2a2/nhoRAiUXAJ0WirUiI69vjzyjtNfnC/SJpm1OtQCguC03 aeFthNOmtzfPPYKA9Cs3+5k= =X3xg -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [License] for jars in CVS
On Dec 24, 2003, at 5:47 PM, Danny Angus wrote: In the case of most of the licences we'd be likely to consider in this context it is usually perfectly OK to distribute Jars in a distribution because that gives you the opportunity to comply with licence conditions regarding distribution of their licence and other materials. The problem boils down to the fact that some licences, and I know that JavaMail and Activation are cases of this, do allow re-distribution as part of a complete product, but don't allow re-distribution in any other case. Similarly OS licences require that a copy of the licence be distributed along with the binary, and simply placing both in cvs doesn't compel anyone to download or read the licence. Understood. Perhaps a nice compromise is to allow projects to keep a .zip of the dependency JAR's in CVS which includes the license files, so there is no way to download just the JAR's themselves directly. It would be a simple Ant target to have this unzipped locally and used from then on out. As far as OGNL is concerned, from my lurking on the Tapestry lists I'd say that it is pretty clear that there is a close association between the projects, and if you want to continue to have OGNL in cvs I'd get Drew to send a mail to the Tapestry dev list, or the PMC confirming that they are happy for this to happen. I have e-mailed Drew to request he send an all is well message. I have yet to hear back from him, but we have a couple of reasons to rest easy on this one: Drew is a good friend of mine, so would not stir up any trouble related to this, and he gets great publicity from having OGNL embedded in Tapestry and other places. FWIW on a previous occasion that this subject came up I got a similar assurance from Mark Mathews regarding the mm.mysql jdbc drivers, he was quite happy with the way we were doing things and this seemed to be acceptable. Leastways no-one here complained. Again, I don't think we have any worries about OGNL. But your point is well taken with respect to other JAR's which disallow direct redistribution. Would the .zip solution be acceptable in these cases? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-site2/xdocs/site binindex.xml news.xml
cutting 2003/12/26 10:24:57 Modified:docs index.html docs/site binindex.html news.html xdocsindex.xml xdocs/site binindex.xml news.xml Log: Announce Lucene 1.3 release. Revision ChangesPath 1.353 +1 -1 jakarta-site2/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-site2/docs/index.html,v retrieving revision 1.352 retrieving revision 1.353 diff -u -r1.352 -r1.353 --- index.html23 Dec 2003 12:42:58 - 1.352 +++ index.html26 Dec 2003 18:24:57 - 1.353 @@ -241,9 +241,9 @@ blockquote h4a href=site/news.htmlJakarta Product news/a/h4 ul +lia href=site/news.html#20031226.126 December 2003 - b Jakarta Lucene 1.3 Final Released/b/a/li lia href=site/elsewhere.html#20031218.218 December 2003 - b Log4J moved to Apache Logging Services project/b/a/li lia href=site/news.html#20031203.13 December 2003 - b Tomcat 5.0.16 Stable released/b/a/li -lia href=site/news.html#20031125.125 November 2003 - b Jakarta Lucene 1.3 RC3 Released/b/a/li lia href=site/news.html#20031123.123 November 2003 - b Jakarta Cactus 1.5 Released/b/a/li lia href=site/news.html#20031119.119 November 2003 - b Jakarta Velocity Tools 1.1-beta1 Released/b/a/li /ul 1.388 +0 -1 jakarta-site2/docs/site/binindex.html Index: binindex.html === RCS file: /home/cvs/jakarta-site2/docs/site/binindex.html,v retrieving revision 1.387 retrieving revision 1.388 diff -u -r1.387 -r1.388 --- binindex.html 23 Dec 2003 12:34:06 - 1.387 +++ binindex.html 26 Dec 2003 18:24:57 - 1.388 @@ -926,7 +926,6 @@ ul lia href=http://cvs.apache.org/dist/jakarta/bsf/v2.3.0rc1/bin;BSF 2.3.0-rc1/a/li lia href=http://www.apache.org/dist/jakarta/commons/httpclient/binary/;Commons HttpClient 2.0 Release Candidate 2/a/li -lia href=http://cvs.apache.org/dist/jakarta/lucene/v1.3-rc2/;Lucene 1.3 Release Candidate 2/a/li lia href=http://www.apache.org/dist/jakarta/poi/dev/bin;POI 2.0 prereleases/a/li lia href=[preferred]/jakarta/tapestry/binaries/3.0-beta-3/Tapestry 3.0-beta-3/a/li /ul 1.393 +9 -1 jakarta-site2/docs/site/news.html Index: news.html === RCS file: /home/cvs/jakarta-site2/docs/site/news.html,v retrieving revision 1.392 retrieving revision 1.393 diff -u -r1.392 -r1.393 --- news.html 23 Dec 2003 18:07:14 - 1.392 +++ news.html 26 Dec 2003 18:24:57 - 1.393 @@ -195,7 +195,15 @@ /td/tr trtd blockquote -a name=20031223.1 +a name=20031226.1 +h326 December 2003 - Lucene 1.3 Final Released/h3 +/a +pA new release of Lucene is available, with many new features and +bug fixes. See a href=http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-lucene/CHANGES.txt?rev=1.65;CHANGES.txt/a +for details. Binary and source distributions are available a href=http://cvs.apache.org/dist/jakarta/lucene/v1.3-final/;here/a. +/p +hr size=1 noshade=noshade / +a name=20031223.1 h323 December 2003 - Commons Configuration Promoted out of Sandbox/h3 /a p 1.291 +1 -1 jakarta-site2/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v retrieving revision 1.290 retrieving revision 1.291 diff -u -r1.290 -r1.291 --- index.xml 23 Dec 2003 12:42:58 - 1.290 +++ index.xml 26 Dec 2003 18:24:57 - 1.291 @@ -48,9 +48,9 @@ section name=Headlines h4a href=site/news.htmlJakarta Product news/a/h4 ul +lia href=site/news.html#20031226.126 December 2003 - b Jakarta Lucene 1.3 Final Released/b/a/li lia href=site/elsewhere.html#20031218.218 December 2003 - b Log4J moved to Apache Logging Services project/b/a/li lia href=site/news.html#20031203.13 December 2003 - b Tomcat 5.0.16 Stable released/b/a/li -lia href=site/news.html#20031125.125 November 2003 - b Jakarta Lucene 1.3 RC3 Released/b/a/li lia href=site/news.html#20031123.123 November 2003 - b Jakarta Cactus 1.5 Released/b/a/li
Re: [License] for jars in CVS
Harish Krishnaswamy wrote: I am with Erik on no JARs in CVS. Unless it is a legal issue, I would certainly like to distribute all JARs with the distribution. It saves a lot of hassle and keeps uncessary traffic out of the user-list. At the expense of lots of wasted bandwidth and disk space. I agree with Robert. Think about how many copies of commons-collections.jar we would have in CVS (and on our local drives) if all projects stored all of their dependent jars in CVS. You can bundle dependent jars in the distributions without storing them in CVS. See the tomcat and struts distros and builds. I understand Erik's point about wanting to version the dependencies, but I don't think that storing dependent jars in CVS is a good general policy for Jakarta projects. As noted elsewhere on this thread, there are also legal issues to consider for non-Apache jars. Phil -Harish Erik Hatcher wrote: In jakarta-tapestry/lib/ext lives all of the licenses of the embedded 3rd party libraries. In that directory is a LICENSE.ognl.txt which contains the full license. I believe this is all that is needed to satisfy the license to redistribute the binary version. I can assure that you we will never ever have a problem with OGNL (Drew is a good friend of mine, and having the high profile use of OGNL in Tapestry and other projects like WebWork2 is great advertising for him and his genius). As for the larger issue of no JARs in CVS - I disagree. I'm pragmatic and also like to have everything in CVS needed to build a distribution (even Ant itself for my employers projects). It saves a lot of hassle to version all source code and dependencies together. Yes, we could make the Maven repository argument, but I personally prefer the complete offline usability of a CVS snapshot. When Tapestry came to Jakarta, it's dependencies were vetted extensively and several were removed from CVS - so it is still a PITA to build Tapestry from CVS (and according to Howard, his attempts to Mavenize the build have been unsuccessful to date). Erik On Dec 24, 2003, at 3:47 AM, Henri Yandell wrote: As I just happened to notice this on Incubator [AltRMI in fact]: Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? The below is, to my quick glance, a BSD licence, so approved. I'm with you on the no jars in CVS, but each to community to their own. Whether Tapestry is properly fulfilling the licence by listing their use of ognl in their documentation would be something to check on. Hen On Wed, 24 Dec 2003, Robert Leland wrote: Can we really store non Apache licensed jars in the CVS ? My personal preference is to store no jars in CVS For Example I noticed ognl stored in Tapestry CVS : / /- - //Copyright (c) 2002, Drew Davidson and Luke Blanshard // All rights reserved. // //Redistribution and use in source and binary forms, with or without // modification, are permitted provided that the following conditions are // met: // //Redistributions of source code must retain the above copyright notice, // this list of conditions and the following disclaimer. //Redistributions in binary form must reproduce the above copyright // notice, this list of conditions and the following disclaimer in the // documentation and/or other materials provided with the distribution. //Neither the name of the Drew Davidson nor the names of its contributors // may be used to endorse or promote products derived from this software // without specific prior written permission. // //THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS // AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT // LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS // FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE // COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, // INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, // BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS // OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED // AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, // OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF // THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH // DAMAGE. // - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Geir : If I understand correctly, the opinions of an individual are not the same as a motion passed by the BOD. It is my understanding the BOD has not passed any resolution that grants a PMC member any of the rights implied by the message quoted below. In fact, my understanding is that the role of PMC implies no rights at all - just extra responsibility. Is there anything concrete to suggest otherwise? Cheers, Stephen. Geir Magnusson Jr. wrote: Here is the clearest description I've found. It's by Roy Fielding, ex chair and board member of the ASF, and from all appearances, extremely knowledgeable in these matters. It was posted here : http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=2642 Indemnification is a promise by the corporation to pay the legal expenses of an *individual* if that *individual* becomes subject to criminal or civil proceedings as a result of their actions under a role identified by the corporation, as long as such person acted in good faith and in a manner that such person reasonably believed to be in, or not be opposed to, the best interests of the corporation. In other words, a member is only indemnified for their actions as a member (not much). A director or officer is only indemnified for their actions as a director or within the scope of their mandate as an officer. A PMC member is indemnified under the category of who is or was serving at the request of the corporation as an officer or director of another corporation, partnership, joint venture, trust or other enterprise and only to the extent of that enterprise (the project). A committer who is not a PMC member is not authorized by the corporation to make decisions, and hence cannot act on behalf of the corporation, and thus is not indemnified by the corporation for those actions regardless of their status as a member, director, or officer. Likewise, we should all realize and understand that the ASF's ability to indemnify an individual is strictly limited to the assets held by the ASF. Beyond that, we are on our own as far as personal liability. It is a far better defense that an outside entity cannot successfully sue an individual for damages due to a decision made by a PMC, so it is in everyone's best interests that all of the people voting on an issue be officially named as members of the PMC (or whatever entity is so defined by the bylaws). So in summary, a PMC member is indemnified for activities done on behalf of the corporation. I think that this would be limited to the official activities of the PMC - things done on behalf of the board for the ASF, such as oversight and releases - and not general day-to-day committer activities, such as technical discussion and personal code commits. Of course, that will probably need to be clarified too. However, the key thing to remember is that the indemnification is only up to the limit of the ASFs resources, which isn't much. So try to keep the litigation to a minimum :) geir -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Indemnification of the PMC
Stephen McConnell wrote: If I understand correctly, the opinions of an individual are not the same as a motion passed by the BOD. Correct. In fact, my understanding is that the role of PMC implies no rights at all - just extra responsibility. Is there anything concrete to suggest otherwise? Did you read the two messages, one from Roy, the other from Greg in his official capacity as ASF Chairman? If not, please do so. If so, and you still have some questions that you feel you must have answered, perhaps it would be best for you to addressed them directly with the Board. I don't believe that it would be appropriate for anyone else to pose an authoritative sounding answer. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
