Great, I've determined the urls have changed in the following way and is causing the problem:
We create the following file based on the associated CC URL (currently driven via the CC site within an iframe) File: http://dspace.mit.edu/bitstream/1721.1/34898/101/license_url URL; http://creativecommons.org/licenses/by-nc-sa/2.5/ And an associated rdf file that is retrieved from the above url + "rdf" resulting in the file: http://dspace.mit.edu/bitstream/1721.1/34898/103/license_rdf retrieved and altered from http://creativecommons.org/licenses/by-nc-sa/2.5/rdf which is now non-existent on your site. Now I suppose the site should work ok for the new urls internally and remotely by the dspace instance as long as your urls continue to work by just appending "rdf" to them, I see that they have changed slightly to include the language of the license. http://creativecommons.org/licenses/by/3.0/us/rdf I do think the provided/calculated CC url not including the language is the users issue and it causes the rdf portion of the license not to be created in our production system, for which I've created an alternative patch to solve the issue. Here's the output of the first viewing of the CC license selector http://creativecommons.org/license/?partner=dspace&stylesheet=http%3A% 2F%2Fdspace.mit.edu%2Fsubmit%2Fcreative-commons.css&exit_url=http%3A% 2F%2Fdspace.mit.edu%2Fsubmit%2Fcc-license.jsp%3Flicense_url%3D% 5Blicense_url%5D And the second page http://creativecommons.org/license/results-one? lang=en&language=en&partner=dspace&exit_url=http%3A%2F% 2Fdspace.mit.edu%2Fsubmit%2Fcc-license.jsp%3Flicense_url%3D% 5Blicense_url%5D&stylesheet=http%3A%2F%2Fdspace.mit.edu%2Fsubmit% 2Fcreative-commons.css&field_commercial=y&field_derivatives=y And the final result in dspace.mit.edu is an empty output on our end because of the following "proceed" url does not have a locale path http://dspace.mit.edu/submit/cc-license.jsp?license_url=http%3A// creativecommons.org/licenses/by/3.0/ this results in our application attempting to retrieve rdf at: http://creativecommons.org/licenses/by-sa/3.0/rdf rather than at http://creativecommons.org/licenses/by-sa/3.0/us/rdf Cheers, Mark On Nov 14, 2007, at 2:59 PM, Nathan R. Yergler wrote: > Ben Adida wrote: >> Mark Diggory wrote: >>> Apparently, they are no longer providing access to the RDF files >>> they >>> were previously supplying on the site. This is ultimately very >>> dismaying. We have an application that is very dependent on the >>> CreativeCommons website "not changing" over time and it has >>> proved very >>> inadequate. >> I'm sorry this happened, but be assured that we have a policy of not >> breaking any URLs, so if we did, that's a bug we can certainly >> fix. Just >> let us know and we'll get on it. >> Please let me know what URLs have gone away, and I'll make sure they >> come back. > > Let me echo Ben's sentiments. We had a bug creep into a deployment > earlier this week which caused the RDF URLs to be incorrectly > served, but the RDF should be back now. I sincerely apologize for > the trouble it caused, and we're taking steps to ensure it doesn't > happen again in the future. > > Nathan > > ----- > Nathan R. Yergler > Chief Technology Officer > Creative Commons > > http://wiki.creativecommons.org/User:Nathan_Yergler ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
