 |
 |
As some points for comparison, you might look at two exisintg and similar systems for registering software... First, a software tools database that is maintained for the environmental sciences community: http://ebmtoolsdatabase.org/ An example of one of my tool entries in this system is here: http://ebmtoolsdatabase.org/tool/kepler-scientific-workflow-system-0 The system is easy to use, has some nice descriptions of the software, and is user-maintained. Maybe some of their use cases and yours overlap? I'm not sure which CMS they use, but I found it easy to edit entries myself. Second, the open source site Ohloh has some nice features for characterizing a project, such as languages used, licenses, etc. Here's the page for the same Kepler system in Ohloh: https://www.ohloh.net/p/kepler Ohloh is nice because much of its information is harvested directly from links to the open source code repositories for the project, which allows it to show some nice trends in the software project's life. Hope these are helpful to you in designing your system. Matt On Tue, Aug 9, 2011 at 10:21 AM, Jonathan Rochkind <[log in to unmask]> wrote: > I agree with Brice think you might be over-thinking/over-**architecting > it, although over-thinking is one of my sins too and I'm not always sure how > to get out of it. > > But am I correct that you're going to be relying on user-submitted content > in large part? Then it's important to keep it simple, so it's easy for users > to add content without having to go through a milliion steps and understand > a complicated data model. If you can keep it simple in a way that is > flexible (the 'tags' idea for instance), you also may find users using it in > ways that you didn't anticipate, but which are still useful. > > > On 8/9/2011 12:47 PM, Brice Stacey wrote: > >> I'd be curious to know if this project itself would be open source. >> >> Second, I'm intrigued because I've never seen a UML diagram so close >> before in the wild and it's fascinating to discover the jokes are true (I >> kid, I kid...). Let's get serious and pull out your Refactoring book by >> Fowler and turn to page 336... you can "Extract superclass" to get >> Provider/Institution/Person to inherit from Entity. Then "Merge Hierarchy" >> to tear it down into a single Entity class and add a self-referencing >> association for employs. ProviderType should be renamed to Services and be >> made an association allowing 0..* services. At that point, the DB design is >> pretty straight forward and the architecture astronauts can come back down >> to earth. >> >> Seriously though, I think that technically, you might be over thinking >> this. If you replace Package with Blog, Release with Post, Technology with >> Tag, Provider/Institution/Person with User, Keep Comment as Comment, and >> ignore Event for now.... It's just a simple collection of blogs with posts >> with tags and users that have roles and can leave comments. >> >> Lastly, you may want to look into Drupal's project module. I think that's >> what they use to run their module directory. It seems like it would be a >> good starting point and may work out of the box. >> >> It's a bold project. The library needs it and it's something no single >> institution would ever pay to have done, so I'm glad to see there is a grant >> for it. >> >> Brice Stacey >> Digital Library Services >> University of Massachusetts Boston >> [log in to unmask] >> 617-287-5921 >> >> >> On 15 July 2011 19:42, Peter Murray<[log in to unmask]**org<[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<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/<http://creativecommons.org/licenses/by-nc-sa/2.5/> >>> >>> >>>