Emily,

Actually, thanks for cross-pollinating this to all three lists, since
I think it directly affects all three groups.

I think one of the questions that would help guide this discussion is
knowing a little more about the future of the DLF API and the role
that the task force will have in it.  You mention that the group
doesn't feel comfortable with trying to implement, but obviously they
have a stake in making sure it doesn't just fall by the wayside,
forgotten.  What, exactly, does "success" mean to the task force and
what are the plans of achieving that?  Would the ideal be to release a
more formal recommendation and hope something adopts that and
continues development?  Or would it continue to evolve independently
of other initiatives and what kind of group *should* be shepherding
that?

As far as where the development lives, I can make arguments for both
wiki.code4lib.org and jangle.org; both have advantages and
disadvantages.

I couldn't imagine people objecting to this being hosted on
wiki.code4lib.org, it's certainly not out of scope to what people are
working on there.  That being said, wiki.code4lib.org will probably
always be a hodge-podge of content from a variety of different
initiatives; most of which would have nothing to do with the DLF API.
That might be a little disconcerting to uninitiated.  It's a good
project-neutral location, however.

On the flip side, Jangle is using the DLF API as the use case to guide
the initial development.  At first blush it would seem as though it
makes sense combine the two (there will certainly be need for
communication and coordination); however, Jangle and the DLF API are
not a 1:1 match.  Jangle (at least in the current vision) wouldn't
directly supply the DLF API and it would need to be made clear that
the DLF API could be implemented *without implementing Jangle* (which,
again, might be confusing to the uninitiated).  Since both of these
projects are really working for the same eventual outcome ("help me
free my data"), there is something to be said for them being under the
same umbrella.

Regarding your other question, the hosting of this code, I think,
again, either place could work.  What we're really talking about a
registry (code for SD Unicorn, EL Aleph, Koha, etc.) with either file
attachments or contact information on how to download it (if, for
instance, it's protected by an NDA).

-Ross.

On Mon, Apr 7, 2008 at 5:59 PM, Emily Lynema <[log in to unmask]> wrote:
>
>  Many apologies for the cross-posting, but I wanted to make sure all the
>  involved parties were fully represented.
>
>  I have 2 questions that relate to the work of the ILS Discovery
>  Interface Task Force [1], the work of the jangle community [2], and the
>  code4lib community in general.
>
>  1. At the Discovery Interface Task Force breakout session at code4lib,
>  there were many folks interested in moving beyond the abstract DLF
>  recommendation document [3] to more detailed function specifications
>  that could actually be implemented with specific technologies and
>  metadata formats. While we'd love to be able to fully specify a single
>  uniform API specification, those of us on the DLF group feel we lack the
>  time, resources, nor expertise to do this without community input.
>
>  The idea of providing a wiki where anyone could contribute ideas about
>  implementing the recommended functionality (which would hopefully evolve
>  into best practices over time) was well received at code4lib. However,
>  DLF doesn't have an openly available wiki and may not be shepherding
>  this work in the future. Code4lib.org *does* have an openly available wiki.
>
>  At the same time, I see a lot of interest going into an API
>  specification for jangle. I think these projects could work together on
>  defining metadata formats and schemas that support the DLF
>  functionality. But I don't know if the jangle specification will provide
>  a direct mapping to the functions in the DLF recommendation. Jangle
>  already has an open wiki hosted by Google Code (and a Drupal installation).
>
>  In the spirit of democratic openness, I wanted to poll the community.
>  Does it make sense to start a space on the code4lib.org wiki regarding
>  implementation of the DLF recommendation? Is that an acceptable use of
>  the wiki? Or does it make more sense to point to the jangle wiki as a
>  place for discussion?
>
>  2. During the code4lib breakout session, we also discussed creating a
>  wiki where library developers could share their past work to access data
>  stored in the ILS (ex: I've written a function that retrieves live
>  holdings in SirsiDynix, I've written a function that places a hold in
>  Innovative, etc.). We would hope to move toward a point where the code
>  could actually be posted and shared in an open source fashion (no one
>  really knows about NDAs yet). Is this an acceptable use of the code4lib
>  wiki? Google Code makes sense for posting code, but seems like overkill
>  if all you need is a wiki.
>
>  Please let me know if you have any input or suggestions.
>  Thanks!
>
>  -emily lynema
>
>  [1] https://project.library.upenn.edu/confluence/display/ilsapi/Home
>
>  [2] http://jangle.org - community-driven, open source project to create
>  a uniform API specification across all ILS products as well as code for
>  individual connectors for each individual ILS system to implement that
>  API. Jangle could serve as a reference implementation / binding for the
>  DLF recommendations, or the recommended DLF functions could be
>  implemented on top of Jangle and its system connectors.
>
>  [3] For the Feb. 15 draft, see
>  Wiki:
>  https://project.library.upenn.edu/confluence/display/ilsapi/Draft+Recommendation
>  Word: http://tinyurl.com/2bzrje
>
>  --
>  Emily Lynema
>  Systems Librarian for Digital Projects
>  Information Technology, NCSU Libraries
>  919-513-8031
>  [log in to unmask]
>
>  --~--~---------~--~----~------------~-------~--~----~
>  You received this message because you are subscribed to the Google Groups "ILS Discovery Interface Task Force" group.
>  To post to this group, send email to [log in to unmask]
>  To unsubscribe from this group, send email to [log in to unmask]
>  For more options, visit this group at http://groups.google.com/group/ils-di?hl=en
>  -~----------~----~----~----~------~----~------~--~---
>
>