Wendy,
The responses should not appear any differently with the new
work-information elements being introduced to the API's spec.
There are only 2 new fields being introduced and they both pertain
to CC0. The `territory` is an entirely new field, that previous
versions of the API did not support in the RDF or RDFa responses.
The `actor_href` field is also a new one that is mapped to the
dct:publisher rel field of a CC0 response. If you were already
using `attribution_url` to generate this metadata, it will hold
precedence over whatever is included in `actor_href`. In other
words, you'll still get the same results if you were already using
the dev version for CC0.
It is important to understand how each of the work-information
fields affect the resulting rdf and rdfa responses. This is
documented in greater detail at
http://api.creativecommons.org/docs/readme_staging.html#providing-work-information
We are expecting to move the current version of the API to the dev
URL in the next couple weeks. However, we would still appreciate
testing and feedback prior to its move to dev. To test that this
version of the API works correctly in your projects, update your
development versions to use the staging url and keep an eye for an
announcement on this list when we update the dev version.
Hopefully this clear things up a bit.
Regards,
John Doig
On 05/12/2010 08:14 AM, Wendy J Bossons wrote:
5FE54D00-B13A-4894-8F46-284DACA06390 AT mit.edu"
type="cite">Two questions about the new CC Rest API version . . .
How will the new work-information elements be reflected in the
service response, e.g will the rdf, rdfa and html in a license
issue change, or just a subset of those areas of the response
document? (The documentation shows a standard response from the
currently released api.
When can we begin using the staging api? We are migrating our
repository software to a more recent version, and require CCO. I
expect our upgraded software to go into production in the first
week of June.
..\Wendy
Wendy Bossons
Web Developer
MIT Libraries
Technology Research and Development
77 Masachusetts Avenue
Cambridge, MA 02139-4307
617-253-0770
Hi everybody,
I'm delighted to announce that we've recently updated
our REST API with some exciting performance
enhancements, bug fixes, and improvements to the
developer documentation!
The most up-to-date version of the CC REST API is now
rooted at http://api.creativecommons.org/rest/staging/.
To read more about this release, visit the staging
version's documentation. http://api.creativecommons.org/docs/readme_staging.html
The staging and development APIs are currently in
beta, and we are soliciting feedback and suggestions. As
such, the API may change in the future.
The staging version of the CC REST API has been entirely
rewritten to be more maintainable, faster, and stable.
Boasting points:
* Cleaner CC0 implementation
* Lightened dependencies
* Ease of extensibility
* Improved documentation
* Comprehensive and rigorous test suite
* CC "sanity" work use case!
To iterate on a couple of those points:
Improved documentation --- The main focus of improving
the REST API's documentation was to reduce the amount of
confusion surrounding how the individual work-info
elements affect an HTML+RDFa license result. The most
up-to-date documentation for this release can be found
at http://api.creativecommons.org/docs/readme_staging.html#providing-work-information,
which elaborates more on this issue.
CC0 --- In order to get CC0 into previous versions of
the REST API, a grotesque monkey-patch was required [1].
The patch resulted in longer response times for CC0
issues than the typical latency experienced with the
standard licenses' requests. This has been resolved in
the latest release, and the CC0 integration has been
tremendously improved. We have also corrected the
inconsistencies that existed between CC0 and
standard license issues in how work-info
elements were handled in the HTM+RDFa output.
Some background on why this work was needed...
Historically, the REST API's issued parametrized
license results via the license_xsl library, the same
library that powered the license chooser accessible at http://creativecommons.org/choose/.
license_xsl relies on XML/XSLT for it's core logic and
over the years has become increasingly difficult to
maintain and bloated. This made things to difficult to
scale our services as the CC organization continues to
grows -- recall how long it took for us to get around to
supporting CC0 :)
license_xsl is to be relieved of it's duties at CC by
the cc.license project sometime here in the near future.
The newly built CC API is one such example of a
license_xsl decommission. The REST API is now backed by
the cc.license library, which provides the API's core
logic for issuing licenses based upon sets of user
parameters.
Your comments, feedback and suggestions can be sent to cc-devel AT creativecommons.org
and are always very welcomed and encouraged :)
Regards,
John Doig
JED3 @ irc.freenode.net/cc
[1] "insane monkey-patch": http://code.creativecommons.org/viewsvn/api/branches/nose-test-suite-branch/support.py?r1=10185&r2=14085
<ATT00001.c>
_______________________________________________
cc-devel mailing list
cc-devel AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel
|
