> We've done something similar:  a simple RESTful web service that takes
> in an organization code and local identifier as input, and returns an
> xml snippet with a hashed unique opaque identifier as output.  We're not
> using this extensively yet, but our plan is to use it to generate
> handles that will in turn become fedora PIDs.  This webservice can be
> used to either create new pids, or used to generate the pid from a
> string, which can then be matched up with handles and/or existing Fedora
> objects. I can provide you with the documentation and code, if you're
> interested;  it's pretty simple.

For actually generating the identifiers, I was looking at the CDL's NOID 
project <PDF: http://www.cdlib.org/inside/diglib/ark/noid.pdf >, which is (/can 
be) a perl cgi script. It does some neat things with its generator + syntax.

> Why not use RESTful urls, rather than query string parameters?  Will the
> h264.code-shop software handle that?

The pseudostreaming takes a similar approach as the w3c media fragments spec -- 
http://www.w3.org/TR/2009/WD-media-frags-20091217/ -- which recommends either 
URI queries (which many media players implement) or URI fragments, both of 
which are probably appropriate (and better semantically?) in this application.

Chris

On 1/13/10 4:55 PM, "Scott Prater" <[email protected]> wrote:

Chris Beer wrote:
> Hi all,
>
> At WGBH, we're in the midst of rolling out a public digital library
> interface on top of Fedora (+Blacklight), after spending the last 12+ months
> working on a prototype application. As part of this process, I've tried to
> document some of the issues we've run up against with Fedora and I've taken
> a first pass at some potential patches...
>
> 1) This isn't necessarily an appropriate thing for the Fedora core, but I'm
> also not sure where else to put it to get comments on it. As a way of diving
> into the code, I've implemented a new pidgen that calls a RESTful webservice
> to request a PID. This probably isn't a new idea, but I couldn't find any
> other generators of its kind...
>
> http://gist.github.com/273584

We've done something similar:  a simple RESTful web service that takes
in an organization code and local identifier as input, and returns an
xml snippet with a hashed unique opaque identifier as output.  We're not
using this extensively yet, but our plan is to use it to generate
handles that will in turn become fedora PIDs.  This webservice can be
used to either create new pids, or used to generate the pid from a
string, which can then be matched up with handles and/or existing Fedora
objects. I can provide you with the documentation and code, if you're
interested;  it's pretty simple.

> 3) For delivering video files, we're using HTTP-based pseudostreaming
> <http://h264.code-shop.com/>, which uses GET parameters to send start + end
> times. While writing a disseminator is probably a valid option, I wonder if
> it makes sense to pass through query string parameters for Redirect
> datastreams? Is there a philosophic problem with doing that?
>
> http://gist.github.com/276585
>
> I might end up writing a disseminator anyway, but thought I'd offer this for
> discussion anyway..

Why not use RESTful urls, rather than query string parameters?  Will the
h264.code-shop software handle that?

-- Scott
--
Scott Prater
Library, Instructional, and Research Applications (LIRA)
Division of Information Technology (DoIT)
University of Wisconsin - Madison
[email protected]

------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Fedora-commons-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers

Reply via email to