Notes from Open Source Discovery Portal Camp - Revision history

Edward Vielmetti: /* solr marc */

2009-02-26T01:13:03Z

‎solr marc

Edward Vielmetti: /* Non-catalog content / digital repositories */

2009-02-26T00:54:44Z

‎Non-catalog content / digital repositories

Edward Vielmetti: /* Jangle */

2009-02-26T00:50:08Z

‎Jangle

Edward Vielmetti: /* Jangle */

2009-02-25T23:43:26Z

‎Jangle

Edward Vielmetti: /* Jangle */ [http://www.jangle.org/ Jangle]

2009-02-25T23:33:56Z

‎Jangle: [http://www.jangle.org/ Jangle]

Edward Vielmetti: /* Notes from Open Source Discovery Portal Camp */

2009-02-25T21:09:40Z

‎Notes from Open Source Discovery Portal Camp

Edward Vielmetti: [http://blacklight.rubyforge.org/ Blacklight

2009-02-25T20:34:12Z

[http://blacklight.rubyforge.org/ Blacklight

Edward Vielmetti: give VuFind its own project page

2009-02-25T18:29:40Z

give VuFind its own project page

Edward Vielmetti at 18:28, 25 February 2009

2009-02-25T18:28:36Z

Wickr: Protected "Notes from Open Source Discovery Portal Camp" [edit=autoconfirmed:move=autoconfirmed]

2008-12-04T03:55:56Z

Protected "Notes from Open Source Discovery Portal Camp" [edit=autoconfirmed:move=autoconfirmed]

@@ Line 33: / Line 33: @@
 Q: How well is solr marc handling bad data these days?
-Bob: I've been adding to marc4j more permissive reading and error correction. It's also reporting errors as it finds them, to make it easier to find bad records. Request for writing to log files instead of standard out. How to handle records with bad leaders? Naomi has some marc test data. We need more test driven development.
+Bob: I've been adding to [[marc4j]] more permissive reading and error correction. It's also reporting errors as it finds them, to make it easier to find bad records. Request for writing to log files instead of standard out. How to handle records with bad leaders? Naomi has some marc test data. We need more test driven development.
 Naomi is offering code for parsing OCLC numbers and LC numbers, she'll be working with Bob next week to get that into solrmarc.

@@ Line 19: / Line 19: @@
 === Non-catalog content / digital repositories ===
-Could we adapt SolrMARC to also include SolrOAI? Yes, Bob, Naomi and Andrew all have ideas about how this could work. Sounds like this is the kernel of our kernel. Solr already has a lot of functionality to allow for this. Do we want a couple of plugins, one for solr and one for OAI? Or do we want an app that handles both?
+Could we adapt [[SolrMARC]] to also include [[SolrOAI]]? Yes, Bob, Naomi and Andrew all have ideas about how this could work. Sounds like this is the kernel of our kernel. [[Solr]] already has a lot of functionality to allow for this. Do we want a couple of plugins, one for solr and one for [[OAI]]? Or do we want an app that handles both?
 Lots of little data silos aren't going to work, we need everything in a local catalog. But that doesn't mean we should all try to be google. We still need well-defined collection development policies.
-What about social data? SoPAC is neat, and has an independent layer for saving social data.
+What about social data? [[SoPAC]] is neat, and has an independent layer for saving social data.
-We also talked about Blacklight and the ways it brings in various data sources and handles behavior for different kinds of objects, e.g., [http://musicbrainz.org/ MusicBrainz] data for music items.
+We also talked about [[Blacklight]] and the ways it brings in various data sources and handles behavior for different kinds of objects, e.g., [http://musicbrainz.org/ MusicBrainz] data for music items.
 (interested in further development: Bob, Dennis, Peter, Naomi, Bess)

@@ Line 13: / Line 13: @@
 Eric Morgan: Jangle is a step in the right direction. DLF came up with a list of API features they want, and then Ross came along and said here's a simple RESTful implementation of a lot of that API, based on [[ATOM]] publishing protocol. We need a number of agreed upon shapes of URLs that do things like tell me the status of this book, authority information for a person. To what degree do we want to use something like Jangle in vufind? There aren't a lot of choices right now, and this seems like a good project to explore further.
-What about XC? There's a lot of frustration around this project, because they say they are open source but haven't actually made any of their source available. How do we get them to participate with the larger community? There's a growing community of developers around these issues, and XC should be involved. Eric says someone should have explicitly invited them.
+What about [[XC]]? There's a lot of frustration around this project, because they say they are open source but haven't actually made any of their source available. How do we get them to participate with the larger community? There's a growing community of developers around these issues, and XC should be involved. Eric says someone should have explicitly invited them.
 (interested in further development: Bess, Andrew, Gabe)

@@ Line 7: / Line 7: @@
 Andrew started by giving us a brief introduction to [[Jangle]], a standard approach to building a toolset for interacting with the ILS. It was kickstarted by the DLF ILS API set. The idea is to create a standard way of interacting with the ILS. Jangle is the first implementation of this, and is planned as the "reference implementation." It's an open source standard approach, and will give us a lot of flexibility.
-Gabe points out that the DLF standard and the Jangle standard aren't the same thing exactly, but people seem to agree it's still a good start at standardization. Andrew asks, how do we contribute the VuFind drivers to Jangle? Is there an NCIP driver for Jangle? [http://www.extensiblecatalog.org/ Xtensible Catalog] is using NCIP, for example. One problem with this, though, is that many vendors don't implement NCIP.
+Gabe points out that the DLF standard and the Jangle standard aren't the same thing exactly, but people seem to agree it's still a good start at standardization. Andrew asks, how do we contribute the VuFind drivers to Jangle? Is there an [[NCIP]] driver for Jangle? [http://www.extensiblecatalog.org/ Xtensible Catalog] is using NCIP, for example. One problem with this, though, is that many vendors don't implement NCIP.
 Ross Singer is the main developer for Jangle, and he wrote an article about it for the latest code4lib journal. Everyone's homework is to go read that article, available [http://journal.code4lib.org/articles/109 here]. Many institutions are hacking their own ILS, it would be more efficient if we all share this code through something like Jangle, which could then be used by VuFind, Blacklight, [http://code.google.com/p/fac-back-opac/ Helios], or any other project that could talk to Jangle.
-Eric Morgan: Jangle is a step in the right direction. DLF came up with a list of API features they want, and then Ross came along and said here's a simple RESTful implementation of a lot of that API, based on ATOM publishing protocol. We need a number of agreed upon shapes of URLs that do things like tell me the status of this book, authority information for a person. To what degree do we want to use something like Jangle in vufind? There aren't a lot of choices right now, and this seems like a good project to explore further.
+Eric Morgan: Jangle is a step in the right direction. DLF came up with a list of API features they want, and then Ross came along and said here's a simple RESTful implementation of a lot of that API, based on [[ATOM]] publishing protocol. We need a number of agreed upon shapes of URLs that do things like tell me the status of this book, authority information for a person. To what degree do we want to use something like Jangle in vufind? There aren't a lot of choices right now, and this seems like a good project to explore further.
 What about XC? There's a lot of frustration around this project, because they say they are open source but haven't actually made any of their source available. How do we get them to participate with the larger community? There's a growing community of developers around these issues, and XC should be involved. Eric says someone should have explicitly invited them.

@@ Line 5: / Line 5: @@
 === Jangle ===
-Andrew started by giving us a brief introduction to [http://www.jangle.org/ Jangle], a standard approach to building a toolset for interacting with the ILS. It was kickstarted by the DLF ILS API set. The idea is to create a standard way of interacting with the ILS. Jangle is the first implementation of this, and is planned as the "reference implementation." It's an open source standard approach, and will give us a lot of flexibility.
+Andrew started by giving us a brief introduction to [[Jangle]], a standard approach to building a toolset for interacting with the ILS. It was kickstarted by the DLF ILS API set. The idea is to create a standard way of interacting with the ILS. Jangle is the first implementation of this, and is planned as the "reference implementation." It's an open source standard approach, and will give us a lot of flexibility.
 Gabe points out that the DLF standard and the Jangle standard aren't the same thing exactly, but people seem to agree it's still a good start at standardization. Andrew asks, how do we contribute the VuFind drivers to Jangle? Is there an NCIP driver for Jangle? [http://www.extensiblecatalog.org/ Xtensible Catalog] is using NCIP, for example. One problem with this, though, is that many vendors don't implement NCIP.

@@ Line 1: / Line 1: @@
 == Notes from Open Source Discovery Portal Camp ==
-On 6 November 2008, there was a meeting at the Palinet offices in Philadelphia to discuss the future of open source discovery portals. The [[VuFind]] and [[Blacklight]] projects had already started cooperating by sharing indexing code in the form of [http://code.google.com/p/solrmarc/ SolrMarc], and as a community we wanted to explore whether there were other ways we could be cooperating, and what our development priorities should be. We discussed the following topics and some people identified themselves as particularly interested in following up on specific topics and doing further work in a given area. Bess took notes, which are pasted here, but please feel free to expand upon these with your own memories of the conversation.
+On 6 November 2008, there was a meeting at the Palinet offices in Philadelphia to discuss the future of open source discovery portals. The [[VuFind]] and [[Blacklight]] projects had already started cooperating by sharing indexing code in the form of [[Solrmarc]], and as a community we wanted to explore whether there were other ways we could be cooperating, and what our development priorities should be. We discussed the following topics and some people identified themselves as particularly interested in following up on specific topics and doing further work in a given area. Bess took notes, which are pasted here, but please feel free to expand upon these with your own memories of the conversation.
 === Jangle ===

← Older revision		Revision as of 18:28, 25 February 2009
Line 97:		Line 97:
	=== How do we organize - How do we reach out to libraries and formalize a committment? ===		=== How do we organize - How do we reach out to libraries and formalize a committment? ===
	John, Dennis, Joe, Andrew, Mark, Daniel		John, Dennis, Joe, Andrew, Mark, Daniel
		+
		+	[[Category: Meeting agendas]]

← Older revision	Revision as of 03:55, 4 December 2008
(No difference)