Great questions, Lori. Thanks for prompting these clarifications.
We're using Drupal as a foundation and are going to be contracting with a Drupal developer to integrate existing Drupal modules with any custom field design, taxonomy creation, and plug-in development required to meet the goals. One of the conditions we'll put on the development contract is that we can release the code behind the registry as open source itself. My current thinking is that once the core work done we'll put the code up on Google Code or GitHub or a similar code hosting service.
Descriptive elements, being factual, wouldn't be subject to licensing. We'll insist that comments and ratings be licensed to the registry under a Creative Commons Attribution-ShareAlike License (same as used by Wikipedia) by their authors. The specifications will say that RSS feeds will be possible based on Drupal taxonomy classes (and iCal entries for the Event entities). I'd like to go so far as to develop an RDF data model and publish entities, attributes and relationships as RDFa, but that may not happen in the first development go-around. Editing data can come from any user logged into the system, and there will be a public stream of changes so malicious edits can be caught and reversed.
Two things come to mind in supporting project specific lists of users and providers. We can talk about direct, read-only (or perhaps even read-write) APIs into the database itself. Or, as we'll probably do for DSpace, embed a special case that redirects requests for users and providers to the DuraSpace listings. And if there is special information that the Evergreen group would like to capture, we can talk about modifying the data model to include it; now is definitely the best time to be doing that before a database gets instantiated.
In short, I'm definitely open to the conversation.
Peter
On Jul 26, 2011, at 10:15 AM, Lori Bowen Ayre wrote:
>
> Hi Peter,
>
> I'm working with the Evergreen community and we had discussed setting up an Evergreen community directory that would contain a lot of the information you are after in this application. We are evaluating whether we'd rather throw our energy into what you are doing here so would like to hear more about ownership, access, licensing and availability of the application and the data that you are collecting.
>
> I know you say the "registry will be free for viewing and editing (all libraries, not just LYRASIS members, and any provider offering services for open source software in libraries)" but could you tell us who will have access to what, and who can edit what, and what kind of license you will have on the application itself?
>
> For example, what if we wanted to use the information collected in your database about Evergreen users and service providers...could we export that subset of data? On a regular basis (e.g. RSS feed?) Could we copy your Drupal installation (and retheme it for our use on the Evergreen site?) What if we wanted to capture some additional information about our Evergreen community that others weren't interested in...would there be some flexibility there?
>
> Just trying to get a handle on the possibilities you are open to considering or have already considered.
>
> Lori Ayre
> Evergreen Oversight Board
>
>
>
> On Fri, Jul 15, 2011 at 11:42 AM, Peter Murray <[log in to unmask]> wrote:
> Colleagues --
>
> As part of the Mellon Foundation grant funding the start-up of LYRASIS Technology Services, LTS is establishing a registry to provide in-depth comparative, evaluative, and version information about open source products. This registry will be free for viewing and editing (all libraries, not just LYRASIS members, and any provider offering services for open source software in libraries). Drupal will be the underlying content system, and it will be hosted by LYRASIS.
>
> I'm seeking input on a data model that is intended to answer these questions:
>
> • What open source options exist to meet a particular need of my library?
> • What are the strengths and weaknesses of an open source package?
> • My library has developers with skills in specific technologies. What open source packages mesh well with the skills my library has in-house?
> • Where can my library go to get training, documentation, hosting, and/or contract software development for a specific open source package?
> • Are any peers using this open source software?
> • Where is there more information about this open source software package?
>
> The E-R diagram and narrative surrounding it are on the Code4Lib wiki:
>
> http://wiki.code4lib.org/index.php/Registry_E-R_Diagram
>
> Comments on the data model can be made as changes to the wiki document, replies posted here, or e-mail sent directly to me. In addition to comments on the data model, I'm particularly interested in answers to these questions (also listed at the bottom of the wiki page):
>
> 1. The model does not provide for a relationship between a person and a software package. Would such a relationship be useful? E.g., individuals self-identifying as affiliated with an open source software package.
>
> 2. The initial planning process did not account for the inclusion of packages that were not themselves end products. Should code libraries and support programs be included as packages in the registry? The model could conceivably be adjusted in two ways to account for this. The simplest would only require the addition of new PackageType enumerations (e.g. “code library”); this would not allow for searching of packages that use code libraries (e.g., answering the question “What repositories use the djatoka JPEG2000 viewer system?”) Another simple change would be to add “code library” to the TechType enumeration; the code library would not have the benefit of links to other relationships and entities. A more complicated change would do both but there would be no relationship between the code library as a Package and as a Technology. Are there better ways to add code libraries to the model?
>
> 3. Some who have reviewed the concept for the registry suggested other attributes. Should these be added? (And what is missing?)
> • Package – Translations
> • Package – Intended audience (e.g. developers, patrons/desktop, patrons/web, library-staff/desktop, library-staff/web)
> • Version – Code maturity (e.g., alpha, beta, release candidate, formal release)
>
> 4. To answer the question “Are any peers using this open source software?” is it necessary to have an enumeration of library types? Public library, school library, university library, community college library, special library, museum (others?)
>
> 5. Is the location of Institutions and Providers desired? One reason it might be desirable is to do a geography-based search (e.g. training providers within a 60-mile radius).
>
>
> Feel free to add to the list of questions. I'm looking forward to your thoughts.
>
>
> Peter
--
Peter Murray [log in to unmask] tel:+1-678-235-2955
Ass't Director, Technology Services Development http://dltj.org/about/
LYRASIS -- Great Libraries. Strong Communities. Innovative Answers.
The Disruptive Library Technology Jester http://dltj.org/
Attrib-Noncomm-Share http://creativecommons.org/licenses/by-nc-sa/2.5/
|
