I was just answering some questions from Beatrice -- our developer at Trento -- about the ZUNI PuSH system that they are fast completing. We were talking about the filtering feature and how complex or simple it should be. Naturally, I said it should be simple mostly because I think simple search features are more powerful. Simplicity accommodates a vastly larger diversity of queries, and their intentions, than do complex search systems (contrary to theory). However, I made a point to Beatrice which got me thinking. I said that we "should keep in mind that this process provides the subscriber with a filtered feed for them to process. That means that we do not have to, and even probably should not, provide" a complex filter. The point of the system, I went on briefly to say, is that the subscriber can do what they like with the data as they are PuSHed (sent) the filtered feed data. In this way, what we are doing is "much more like and API than an APP", I said.
So this is what got me thinking. We have been treating this system as though it were an App (a Web Application), which it partially is. However, it is an App that allows you to work with feed data as though it were an API (an Application Programming Interface). What APIs do is to allow for an App (App_1) to communicate with another App or system, or many other Apps or systems, so that data from these Apps or systems can be used, modified and reapplied in the App_1. APIs also allow for data to be passed from the App_1 back to the other Apps or systems. APIs are everywhere on the web, but APIs act in the background, behind a front-end of an App that the user engages with, so users don't usually know they are there.
The ZUNI PuSH system, however, is a bit of a hybrid. Though it is a front end App for people to publish and/or subscribe and filter feeds -- in this way nothing unusual, it actually sends the subscriber the feed data from the filtered feed like an API for the subscriber to process. In this way, the ZUNI PuSH system is like an API.
This may seem like a "technicality", and it is in one sense, but it is actually critical to understanding what it is we are trying to do. The fact that it is both an App and an API shows how this approach is fundamentally different from other access systems such as readers, portals or catalogues. These traditional access systems see information as something that is accessed and referred to. The ZUNI PuSH system sees information more as it is used in mashups -- as something that is used, transformed and recontextualised by the user. The ZUNI PuSH system sees information as a resource, not as a product, and this is a critical difference with far reaching implications.
Saturday, March 17, 2012
Thursday, July 21, 2011
What is wrong with PubSubHubBub.
I have been having a great set of skype meetings with our team in Trento (Fabio, Marcos and Beatrice) about the Publish and Subscribe system. We are making excellent progress and have the system fleshed out already. However, from the beginning we have all been aware of some limitation of the usual publish and subscribe models for both RSS/ATOM and PubSubHubBub. We are working with Trento because of three limitations in particular: Size of feeds, lack of security and need to filter output. Today, in anticipation of our meeting Beatrice posted her list of PubSubHubBub limitations which I think are the best to date from anywhere. With her permission, I am posting them here. By the by, for these reasons, we are not using the Google Code PubSubHubBub implementation, but will be using Apache ActiveMQ (http://activemq.apache.org/getting-started.html).
PubSubHubbub limitations
by Beatrice Valeri (xinecs87@gmail.com), Trento University Computer Science, Italy
PubSubHubbub is a protocol for pushing updates of atom feeds. It is not useful for the UCLA Push project because it is thought for very simple things and it doesn’t cover many of the requirements.
1. When a new subscriber arrives, he should receive also all messages written before his arrival. This is not completely supported by PubSubHubbub. If the subscriber subscribes before the feed is published, then, after the feed is published, the subscriber receives all messages written before publishing and all the following updates. Once the feed is published, new subscribers receives only the updates.
2. There is no security on the hub. Anyone can subscribe and publish.
3. Subscribers have no way to subscribe only on some messages from a feed. Filtering have to be done by the subscriber after messages are received.
4. PubSubHubbub is not able to manage feeds that are already big at the moment of publishing. When a feed is published, the hub reads it completely and parses it. If the feed is too big, the hub is not able to parse it.
Feeds have to be broken into pieces and each piece has to be published.
5. The subscriber has to know the feed url in order to subscribe to it. This is not a real pub-sub system since subscriber has to be aware of publishers and has to subscribe again if a new interesting feed is published.
6. With PubSubHubbub, a feed can be published only if there is already a subscriber waiting for it. This is not what we want.
PubSubHubbub limitations
by Beatrice Valeri (xinecs87@gmail.com), Trento University Computer Science, Italy
PubSubHubbub is a protocol for pushing updates of atom feeds. It is not useful for the UCLA Push project because it is thought for very simple things and it doesn’t cover many of the requirements.
1. When a new subscriber arrives, he should receive also all messages written before his arrival. This is not completely supported by PubSubHubbub. If the subscriber subscribes before the feed is published, then, after the feed is published, the subscriber receives all messages written before publishing and all the following updates. Once the feed is published, new subscribers receives only the updates.
2. There is no security on the hub. Anyone can subscribe and publish.
3. Subscribers have no way to subscribe only on some messages from a feed. Filtering have to be done by the subscriber after messages are received.
4. PubSubHubbub is not able to manage feeds that are already big at the moment of publishing. When a feed is published, the hub reads it completely and parses it. If the feed is too big, the hub is not able to parse it.
Feeds have to be broken into pieces and each piece has to be published.
5. The subscriber has to know the feed url in order to subscribe to it. This is not a real pub-sub system since subscriber has to be aware of publishers and has to subscribe again if a new interesting feed is published.
6. With PubSubHubbub, a feed can be published only if there is already a subscriber waiting for it. This is not what we want.
Sunday, May 8, 2011
Why we are not interested in Portals - 2
From my last post, I have worked up a model of a Portal implementation so we can now compare our model with that of a Portal. Of course, there is a lot more functionality in your average Portal than I have modeled, but the point remains as this model fits the fundamental structure of the vast majority of Portals.
If we look at the Portal model we see that all of the information flow is from the User to the Portal. There is no information moving back to the User, except that they are looking at on the Portal. The control of the presentation, organization and interface is with the Portal and stays with the Portal. Even the comments don't move back to core Institutional database, but remains within the Portal. As the Portal is almost always under the control of the Institution anyway, this means that information not only moves from the Users to the Institution (no change there), but also the control of the way the information is managed, presented, accessed and ordered remains with the Institution as well (again, no change there).
If we look at our model, there are three fundamental differences. First, the information that goes to the hub, is not organized, presented nor ordered there, but simply PuSHed from there to the Subscribers' servers. It is at the Subscribers' servers that the information is organized, presented and ordered many times over, and in the local context. There is also the key difference that comments are not simply attached to a Portal instance, but are available to return into the Institution as part of the object's primary record. Most fundamental of all, though, is that our model is reversible. Any Subscriber in our model can become a Publisher, and any Publisher a Subscriber. Knowledge developed through the local use of Institutional information, can be PuSHed back to the Institution to enhance their documentation of the object. A Portal cannot be reversed as it is not a distribution system, but a broadcast system.
If we look at the Portal model we see that all of the information flow is from the User to the Portal. There is no information moving back to the User, except that they are looking at on the Portal. The control of the presentation, organization and interface is with the Portal and stays with the Portal. Even the comments don't move back to core Institutional database, but remains within the Portal. As the Portal is almost always under the control of the Institution anyway, this means that information not only moves from the Users to the Institution (no change there), but also the control of the way the information is managed, presented, accessed and ordered remains with the Institution as well (again, no change there).
If we look at our model, there are three fundamental differences. First, the information that goes to the hub, is not organized, presented nor ordered there, but simply PuSHed from there to the Subscribers' servers. It is at the Subscribers' servers that the information is organized, presented and ordered many times over, and in the local context. There is also the key difference that comments are not simply attached to a Portal instance, but are available to return into the Institution as part of the object's primary record. Most fundamental of all, though, is that our model is reversible. Any Subscriber in our model can become a Publisher, and any Publisher a Subscriber. Knowledge developed through the local use of Institutional information, can be PuSHed back to the Institution to enhance their documentation of the object. A Portal cannot be reversed as it is not a distribution system, but a broadcast system.
Sunday, May 1, 2011
Why we are not interested in Portals.
I thought we would lay down the gauntlet now, even though we are a bit of a way off demonstrating our work. I have uploaded two models for our systems. The first is a User Model, which is a demonstrative diagram for a general audience that shows what our system will intend to do. The second is an Object Model, using UML, which is more for developers. The two more or less depict the same system, though. I should emphasize, for those developers reading this, that the Object Model is not a full Class Model, but more of a "conceptual" Object Model.
What I want to show, however, is not simply what we intend to do, but to also explain why this is different from a Web Portal. In a recent discussion between the IT Officer for Anthropology at the American Museum of Natural History (New York), Jim and I, it became clear that what we are doing could easily be confused with a Portal. Or, worse in my mind, that it could be assumed that there would be little difference between what we are doing and a Portal. In fact, I think that what we are doing is fundamentally different, and even opposed, to what Portals do. Here is why.
If you will pardon me drawing a definition from Wikipedia, a Web Portal is "a web site that function as a point of access to information on the World Wide Web. A portal presents information from diverse sources in a unified way." (Wikipedia, emphasis added). Wikipedia goes on to say that a Portal "provide[s] a way for enterprises to provide a consistent look and feel with access control and procedures for multiple applications and databases, which otherwise would have been different entities altogether." This is the key difference to what we are trying to do and what Web Portals are trying to do. Whereas a Web Portal takes a diverse set of resources, centralizes them and gives them a single "enterprise" identity, what we are trying to do is the opposite. We are trying to do is to take a diverse set of resources, distribute them as filtered sets to diverse expert communities, so that these filtered sets of resources can be localized and used in completely different ways.
The difference between a Web Portal and our approach is not simply superficial, but goes right down to our understanding of what Knowledge is. Where the assumption about knowledge in a Web Portal, and most "knowledge systems," is that knowledge is an accumulated resource, a set of commodities that gain their power as knowledge through their packaging or their organizing, we accept a different, less colonial, view of knowledge. We see knowledge not as a set of proscriptively ordered and presented resources, but as a personal, local and community achievement. Knowledge, for us, is something you do, and do skillfully, not something you acquire, proffer or stockpile.
So the difference may seem subtle, even trivial, but is in fact fundamental. A Web Portal seeks to share information resources between individuals and communities through a unified, proscribed and centralized system -- an enterprise system much like a museum or archive. However, what we trying to do is to share information resources between individuals and communities by distributing those resources into the diverse local systems so that they can be directly used to build local knowledge. While a Web Portal is, by its very nature, a system that creates a unified identity for information, and information use, through its "enterprise" identity, our system seeks to fundamentally undermine this universalizing and commodifying approach to knowledge by radically replacing unity and centralization with diversity and localization.
What I want to show, however, is not simply what we intend to do, but to also explain why this is different from a Web Portal. In a recent discussion between the IT Officer for Anthropology at the American Museum of Natural History (New York), Jim and I, it became clear that what we are doing could easily be confused with a Portal. Or, worse in my mind, that it could be assumed that there would be little difference between what we are doing and a Portal. In fact, I think that what we are doing is fundamentally different, and even opposed, to what Portals do. Here is why.
If you will pardon me drawing a definition from Wikipedia, a Web Portal is "a web site that function as a point of access to information on the World Wide Web. A portal presents information from diverse sources in a unified way." (Wikipedia, emphasis added). Wikipedia goes on to say that a Portal "provide[s] a way for enterprises to provide a consistent look and feel with access control and procedures for multiple applications and databases, which otherwise would have been different entities altogether." This is the key difference to what we are trying to do and what Web Portals are trying to do. Whereas a Web Portal takes a diverse set of resources, centralizes them and gives them a single "enterprise" identity, what we are trying to do is the opposite. We are trying to do is to take a diverse set of resources, distribute them as filtered sets to diverse expert communities, so that these filtered sets of resources can be localized and used in completely different ways.
The difference between a Web Portal and our approach is not simply superficial, but goes right down to our understanding of what Knowledge is. Where the assumption about knowledge in a Web Portal, and most "knowledge systems," is that knowledge is an accumulated resource, a set of commodities that gain their power as knowledge through their packaging or their organizing, we accept a different, less colonial, view of knowledge. We see knowledge not as a set of proscriptively ordered and presented resources, but as a personal, local and community achievement. Knowledge, for us, is something you do, and do skillfully, not something you acquire, proffer or stockpile.
So the difference may seem subtle, even trivial, but is in fact fundamental. A Web Portal seeks to share information resources between individuals and communities through a unified, proscribed and centralized system -- an enterprise system much like a museum or archive. However, what we trying to do is to share information resources between individuals and communities by distributing those resources into the diverse local systems so that they can be directly used to build local knowledge. While a Web Portal is, by its very nature, a system that creates a unified identity for information, and information use, through its "enterprise" identity, our system seeks to fundamentally undermine this universalizing and commodifying approach to knowledge by radically replacing unity and centralization with diversity and localization.
Thursday, March 10, 2011
Cost-Share Admin Details
I am posting a copy of the letter that Ramesh sent out to each of the project partners that describes the details of tracking each institution's cost-sharing commitments. Feel free to reference this for preparing upcoming cost-share letters. -KB
"I am writing to clarify a few administrative details you should be aware of regarding tracking and documenting the cost sharing that each of you as partners committed to during the original submission of the federally funded IMLS grant for which I serve as the Principal Investigator at UCLA. First, let me say I appreciate your work and financial cost sharing, which has contributed to a successful completion of work performed during the first year of the project. Your partnership has been critical to this!
It is important that your financial office track the dollar values for each type of cost share (people, purchases, etc.) since UCLA as a public institution of higher education is required to follow federal guidelines to substantiate cost share committed by each organization/institution. To achieve this goal, we will request at the end of each year a cost share report from each of you that accounts for how you met the total cost share commitment for your organization/institution with a brief description of how the cost related to the project. Please share this information with your respective financial offices.
Sample ($10,000 cost share)
- J. Smith (dbase manager) = $50,000 Annual Salary x 10% effort (or equivalent hours, if hourly) + $1,000 benefits = $6,000
- Software Purchase for data analysis = $2,500
- Materials and supplies for survey development/instruments = $1,500
Total = $10,000
The authorized organizational leader signs a letter containing the elements of the sample above specific to their cost share certifying that the cost share commitment was met as described in the original proposal. Detailed payroll and/or non-payroll documentation is then maintained by the partner should any additional questions arise in the future. The documentation should be maintained by the partner for a period of five (5) years after the final end date of the grant. We appreciate your diligence and cooperation to document the cost share in the most straight forward manner with minimal time investment beyond what you already do to meet your own financial standards.
Should you have any questions about the contents required for the cost share report, please contact Tracy Nguyen-Phan at (310) 825-4426.
thanks,
Ramesh Srinivasan"
"I am writing to clarify a few administrative details you should be aware of regarding tracking and documenting the cost sharing that each of you as partners committed to during the original submission of the federally funded IMLS grant for which I serve as the Principal Investigator at UCLA. First, let me say I appreciate your work and financial cost sharing, which has contributed to a successful completion of work performed during the first year of the project. Your partnership has been critical to this!
It is important that your financial office track the dollar values for each type of cost share (people, purchases, etc.) since UCLA as a public institution of higher education is required to follow federal guidelines to substantiate cost share committed by each organization/institution. To achieve this goal, we will request at the end of each year a cost share report from each of you that accounts for how you met the total cost share commitment for your organization/institution with a brief description of how the cost related to the project. Please share this information with your respective financial offices.
Sample ($10,000 cost share)
- J. Smith (dbase manager) = $50,000 Annual Salary x 10% effort (or equivalent hours, if hourly) + $1,000 benefits = $6,000
- Software Purchase for data analysis = $2,500
- Materials and supplies for survey development/instruments = $1,500
Total = $10,000
The authorized organizational leader signs a letter containing the elements of the sample above specific to their cost share certifying that the cost share commitment was met as described in the original proposal. Detailed payroll and/or non-payroll documentation is then maintained by the partner should any additional questions arise in the future. The documentation should be maintained by the partner for a period of five (5) years after the final end date of the grant. We appreciate your diligence and cooperation to document the cost share in the most straight forward manner with minimal time investment beyond what you already do to meet your own financial standards.
Should you have any questions about the contents required for the cost share report, please contact Tracy Nguyen-Phan at (310) 825-4426.
thanks,
Ramesh Srinivasan"
Saturday, January 15, 2011
Interview with Jussi Parikka
Hi all, I was recently interviewed by Jussi Parikka (media archaeologist and digital theorist). We talked about the past, present and future of archives. Might be of interest. You can find the interview here.
Thursday, December 23, 2010
More notes from meeting 11-30-10 - system details & focus group ideas
This is a continuation of my sketchy notes from our mini-meeting at Zuni on November 30, 2010. We spent much of the afternoon in a discussion about sharing protocols and other details of the Zuni local system, and the protocols that will drive the links between the different local systems. Lastly, we had a discussion of the focus groups for evaluating the system.
We brainstormed about user profiles, and the kinds of information that might work to identify different users and drive the protocols of access. After coming up with a lengthy list, it seemed like a pretty invasive & complex amount of information to gather from users -- might discourage people from signing up.
- Probably only 1-2% of objects need that level of careful restriction
-- just mark it 'unavailable without assistance'
--- can only access it at AAMHC with help
-- for right now, just set sensitive things aside
we can run a permission set out of FileMaker
another idea - restricting access to local IP addresses
- Robin also emphasized that we need a word that doesn't subjugate the new stuff to the existing catalog
- we discussed different kinds of updates that might emerge, and whether we should distinguish between different updates.
Categories we brainstormed: (which could also emerge from the actual work)
- correctives / corrections
- events
- new / additional information
- research
- relations / genealogies
- disputes / discussions
- idea - part of the system evaluation could be from the self-ID of additions - does a pattern emerge?
- impact could be just access, or it could be making flexible systems, or user-generated content
- how do we roll out the system?
-- events in the community
-- getting adults on board
-- permanent kiosks at IHS, etc
Photos / videos / audio - what if young people don't know the protocols about taking photos or video?
Focus groups - guiding questions
themes of what we're interested in
- experience of the system
- access to patrimony
- community dialogue
question ideas (for anonymous q's in system)
How easy is this system to use? (answered on a scale of easy to hard)
Tell us about it...
How much do you feel you've learned from the system?
We brainstormed about user profiles, and the kinds of information that might work to identify different users and drive the protocols of access. After coming up with a lengthy list, it seemed like a pretty invasive & complex amount of information to gather from users -- might discourage people from signing up.
- Probably only 1-2% of objects need that level of careful restriction
-- just mark it 'unavailable without assistance'
--- can only access it at AAMHC with help
-- for right now, just set sensitive things aside
we can run a permission set out of FileMaker
another idea - restricting access to local IP addresses
- Robin also emphasized that we need a word that doesn't subjugate the new stuff to the existing catalog
- we discussed different kinds of updates that might emerge, and whether we should distinguish between different updates.
Categories we brainstormed: (which could also emerge from the actual work)
- correctives / corrections
- events
- new / additional information
- research
- relations / genealogies
- disputes / discussions
- idea - part of the system evaluation could be from the self-ID of additions - does a pattern emerge?
- impact could be just access, or it could be making flexible systems, or user-generated content
- how do we roll out the system?
-- events in the community
-- getting adults on board
-- permanent kiosks at IHS, etc
Photos / videos / audio - what if young people don't know the protocols about taking photos or video?
Focus groups - guiding questions
themes of what we're interested in
- experience of the system
- access to patrimony
- community dialogue
question ideas (for anonymous q's in system)
How easy is this system to use? (answered on a scale of easy to hard)
Tell us about it...
How much do you feel you've learned from the system?
Wednesday, December 22, 2010
Notes from meeting at Zuni 11-30-10
What follows are my sketchy notes from our mini-meeting at Zuni on Nov. 30th, with Ramesh, Robin, Daf Harries, Jim, Octavious, Curtis and myself. We also had a couple of guests as well - Cynthia Chavez-Lamar from the School of Advanced Research in Santa Fe, and Miranda Velarde-Lewis, a Zuni grad student in museum studies at UW.
- Ramesh noted that as far as how he sees it, it's really important for us to look at how the system inspires a social motivation for contributing media & mashups -- what can we put in place to make sure that happens?
- a lot is happening in terms of collaborative catalogs with unofficial partners (like School of Advanced Research) -- not necessarily online
-- for example, at SAR, the whole staff is really engaged - coming back to check and proofread what was added to the catalog.
- Jim recently spoke at AAA (Am. Anthro. Association meetings) - he says that he raised a lot of eyebrows when he said "we are the source community for your museums, so you are satellite of our museums - extensions of our community"
- Cynthia told a story about two aprons in different collections (one from the Zuni Day School collection, the other from DAM) - wouldn't it be nice to point one to another
- Jim said that when we say it's about power, we want the system to mirror the way knowledge is organized within the community
-- we might be taking risks, but if we don't do it, someone else will (and they might make stuff up, or be wrong)
- not just 'setting the record straight' but having a continued, ongoing sovereignty over the collection - governance
-- Zuni decide what gets shared back, what goes back
-- under your name, under your control
- The question was raised - How do we deal with technocracy? -- don't create one
-- setting it up so we don't have to say 'you can only work with us if you have this kind of system'
-- doesn't require local systems to do anything a particular way
--- museums have different needs & audiences
-- our goal is just the in-between links
- Most of what exists elsewhere are portals
-- when source community information comes in, it's placed subordinate to core museum info and how it is classified
- How they incorporate information coming back is up to the museum, its culture, etc.
-- we would hope they change it at a deep level
- Reciprocal Research Network - it's perceived as inclusive, but really they are placing shared info on the side
- no protocols, no sense of what's appropriate or not
- the museum is always the editorial filter - we say that's not their place to decide what voice comes through
- don't create a system that's so rigid that there's no room for innovation & creativity
-- local uses - re-empowerment
Moving on to the technical side of things -- there are two parts
1) each endpoint is being treated as a 'local system' - governed locally
-- the Zuni prototype exists - the FileMaker Pro DB
2) open-source sharing system - local controls and formats stay local
- the key insight here - any institution sharing information is publishing a database of its own info
-- not necessarily the same thing as the whole catalog - some bits are left out
- CouchDB is a mechanism by which you can synchronize two published databases
[ two slides from Daf's presentation that describes how the CouchDB system will be used to link all our local systems]
- using CouchDB is better than what we were thinking previously (pubsubhubbub) -- in that, all kinds of formatting and coordination would be required -- data going into a central hub
-- the other problem - requires a hub somewhere external, outside of the control of local systems
* what we build is going to be the piece in between (say) FileMaker and CouchDB *
- we're using CouchDB (which exists already) and building the in-between bit
-- key thing - your CouchDB database is still inside of your control
- idea to build in indicators to send flags about updated records - fixing mistakes or making changes
ex: user might check a box saying "Notify museum about this change - they should know about this"
* indicator to be added - indicating similar or related objects at other partner museums
- Open question: how the partner museums are going to subscribe to each other, not just to Zuni DB
-- we haven't really discussed this yet
- Cynthia said that it would be very useful if when AAMHC updates (say) a stew bowl, other institutions with similar objects are notified
- some institutions (say, SAR) might want ALL updates, while others might not
- instead of a portal pulling it all together, we're creating something more like a web of collections
- this may not change the ways that libraries, museums, archives think about sharing everything - "knowledge is free"
-- but it might make them more uncomfortable about the idea
- answering the question "How do we know what they say is any good?"
-- range of expertise - different kinds
Subtle difference - really powerful thing - not just about sending messages out and receiving them
- it's about the data actually coming here to Zuni, to be modified / reused / critiqued
- will open eyes of museums - looking at items in an entirely different way
- the advantage of digital here - data - is that data can move around much easier
-- creating a collection for comparison that doesn't exist in the physical world
- as we expand the partnerships further, the good news is that the threshold for entry is pretty low and the relationship isn't automatically two-way
-- we can stipulate that cultural advisors have to visit before museum can subscribe to AAMHC
- building a series of linking interfaces
-- for Argus, mySQL, Oracle, FileMaker, etc
- but there's still the issue of how institutions handle updates within their data structure
* we will need to write up the parameters for participation for new partners *
-- "here's what you need to decide internally for your data structure & updates"
Thinking hard about categories and what is interesting - what we'll want to do with the info
Later in the day, we talked over many details & decisions that we need to make to implement the system, which I'll cover in another post.
- Ramesh noted that as far as how he sees it, it's really important for us to look at how the system inspires a social motivation for contributing media & mashups -- what can we put in place to make sure that happens?
- a lot is happening in terms of collaborative catalogs with unofficial partners (like School of Advanced Research) -- not necessarily online
-- for example, at SAR, the whole staff is really engaged - coming back to check and proofread what was added to the catalog.
- Jim recently spoke at AAA (Am. Anthro. Association meetings) - he says that he raised a lot of eyebrows when he said "we are the source community for your museums, so you are satellite of our museums - extensions of our community"
- Cynthia told a story about two aprons in different collections (one from the Zuni Day School collection, the other from DAM) - wouldn't it be nice to point one to another
- Jim said that when we say it's about power, we want the system to mirror the way knowledge is organized within the community
-- we might be taking risks, but if we don't do it, someone else will (and they might make stuff up, or be wrong)
- not just 'setting the record straight' but having a continued, ongoing sovereignty over the collection - governance
-- Zuni decide what gets shared back, what goes back
-- under your name, under your control
- The question was raised - How do we deal with technocracy? -- don't create one
-- setting it up so we don't have to say 'you can only work with us if you have this kind of system'
-- doesn't require local systems to do anything a particular way
--- museums have different needs & audiences
-- our goal is just the in-between links
- Most of what exists elsewhere are portals
-- when source community information comes in, it's placed subordinate to core museum info and how it is classified
- How they incorporate information coming back is up to the museum, its culture, etc.
-- we would hope they change it at a deep level
- Reciprocal Research Network - it's perceived as inclusive, but really they are placing shared info on the side
- no protocols, no sense of what's appropriate or not
- the museum is always the editorial filter - we say that's not their place to decide what voice comes through
- don't create a system that's so rigid that there's no room for innovation & creativity
-- local uses - re-empowerment
Moving on to the technical side of things -- there are two parts
1) each endpoint is being treated as a 'local system' - governed locally
-- the Zuni prototype exists - the FileMaker Pro DB
2) open-source sharing system - local controls and formats stay local
- the key insight here - any institution sharing information is publishing a database of its own info
-- not necessarily the same thing as the whole catalog - some bits are left out
- CouchDB is a mechanism by which you can synchronize two published databases
[ two slides from Daf's presentation that describes how the CouchDB system will be used to link all our local systems]- using CouchDB is better than what we were thinking previously (pubsubhubbub) -- in that, all kinds of formatting and coordination would be required -- data going into a central hub
-- the other problem - requires a hub somewhere external, outside of the control of local systems
* what we build is going to be the piece in between (say) FileMaker and CouchDB *
- we're using CouchDB (which exists already) and building the in-between bit
-- key thing - your CouchDB database is still inside of your control
- idea to build in indicators to send flags about updated records - fixing mistakes or making changes
ex: user might check a box saying "Notify museum about this change - they should know about this"
* indicator to be added - indicating similar or related objects at other partner museums
- Open question: how the partner museums are going to subscribe to each other, not just to Zuni DB
-- we haven't really discussed this yet
- Cynthia said that it would be very useful if when AAMHC updates (say) a stew bowl, other institutions with similar objects are notified
- some institutions (say, SAR) might want ALL updates, while others might not
- instead of a portal pulling it all together, we're creating something more like a web of collections
- this may not change the ways that libraries, museums, archives think about sharing everything - "knowledge is free"
-- but it might make them more uncomfortable about the idea
- answering the question "How do we know what they say is any good?"
-- range of expertise - different kinds
Subtle difference - really powerful thing - not just about sending messages out and receiving them
- it's about the data actually coming here to Zuni, to be modified / reused / critiqued
- will open eyes of museums - looking at items in an entirely different way
- the advantage of digital here - data - is that data can move around much easier
-- creating a collection for comparison that doesn't exist in the physical world
- as we expand the partnerships further, the good news is that the threshold for entry is pretty low and the relationship isn't automatically two-way
-- we can stipulate that cultural advisors have to visit before museum can subscribe to AAMHC
- building a series of linking interfaces
-- for Argus, mySQL, Oracle, FileMaker, etc
- but there's still the issue of how institutions handle updates within their data structure
* we will need to write up the parameters for participation for new partners *
-- "here's what you need to decide internally for your data structure & updates"
Thinking hard about categories and what is interesting - what we'll want to do with the info
Later in the day, we talked over many details & decisions that we need to make to implement the system, which I'll cover in another post.
CCC project updates - Nov and Dec
Hello everyone,
Without meaning to, I let two months go by without an update -- my apologies. Especially since lots of good things have been going on!
Top on the list was a very successful mini-meeting that we had at the beginning of December. Robin came over from the UK to spend a week at AAMHC working with Curtis to get a system in place to begin sharing with people at Zuni. Ramesh and I came out for a little while to see how things were progressing, and we were joined by Daf Harries, who is going to be our hired consultant to develop the mechanism to transfer data between the museum systems. He will be using an open-source program called CouchDB to make it happen.
As I understand it, CouchDB will create a duplicate database of the Zuni objects in each museum's collections, and since all of the partners will have their own local CouchDB databases, sharing information between them will be easy. Daf will develop individualized software to move data between each partner's CMS (Argus for example) and that institution's CouchDB system. And, each institution will be able to decide how they will handle updates coming in - whether they want to review them, have them automatically update their own catalogs, that kind of thing. As far as we can tell, this is the best solution to the interoperability problem that's been one of our biggest challenges. Daf created a presentation that explains how this is going to work a little bit better, and I've attached it to this message. More on this to come as things progress...
I am putting together my notes from this meeting to post on the project blog, so you all are welcome to take a look once those are up.
In other news, we have been hearing very positive things regarding the NSF proposal that Ramesh submitted several months ago. This proposal would cover an expansion of our project to include additional communities of 'experts' who will be making contributions to the system -- archaeologists and museum curators. Even better, this proposal would be able to fund more equipment like servers and computers at AAMHC. We haven't gotten a 100% yes that we're getting funded, but they have asked us for things like IRB certification, which indicates things are moving in that direction.
Something that came to my attention during the meeting was that Robin hasn't received the digitized images from DMNS -- Chip, I recall that those were either finished or nearly finished. Would you mind following up on that, and making sure that Robin receives those images, so he can get them into the system at Zuni? Thanks!
We also weren't sure whether we are expecting object images from Museum of Northern Arizona -- Robert, were we going to get images for the system from MNA? I can't recall...
And one last thing - we need to submit letters to IMLS that certifies each partner's contributions to the cost share. Our grant admin Tracy has been reaching out to the business reps at each of the museums, and she hasn't received a reply. I'll be sending out individual emails to each partner to facilitate this, so please look for that to come soon.
As always, please let me know if you have questions or concerns. Happy holidays to everyone!
Sincerely,
Katherine
Without meaning to, I let two months go by without an update -- my apologies. Especially since lots of good things have been going on!
Top on the list was a very successful mini-meeting that we had at the beginning of December. Robin came over from the UK to spend a week at AAMHC working with Curtis to get a system in place to begin sharing with people at Zuni. Ramesh and I came out for a little while to see how things were progressing, and we were joined by Daf Harries, who is going to be our hired consultant to develop the mechanism to transfer data between the museum systems. He will be using an open-source program called CouchDB to make it happen.
As I understand it, CouchDB will create a duplicate database of the Zuni objects in each museum's collections, and since all of the partners will have their own local CouchDB databases, sharing information between them will be easy. Daf will develop individualized software to move data between each partner's CMS (Argus for example) and that institution's CouchDB system. And, each institution will be able to decide how they will handle updates coming in - whether they want to review them, have them automatically update their own catalogs, that kind of thing. As far as we can tell, this is the best solution to the interoperability problem that's been one of our biggest challenges. Daf created a presentation that explains how this is going to work a little bit better, and I've attached it to this message. More on this to come as things progress...
I am putting together my notes from this meeting to post on the project blog, so you all are welcome to take a look once those are up.
In other news, we have been hearing very positive things regarding the NSF proposal that Ramesh submitted several months ago. This proposal would cover an expansion of our project to include additional communities of 'experts' who will be making contributions to the system -- archaeologists and museum curators. Even better, this proposal would be able to fund more equipment like servers and computers at AAMHC. We haven't gotten a 100% yes that we're getting funded, but they have asked us for things like IRB certification, which indicates things are moving in that direction.
Something that came to my attention during the meeting was that Robin hasn't received the digitized images from DMNS -- Chip, I recall that those were either finished or nearly finished. Would you mind following up on that, and making sure that Robin receives those images, so he can get them into the system at Zuni? Thanks!
We also weren't sure whether we are expecting object images from Museum of Northern Arizona -- Robert, were we going to get images for the system from MNA? I can't recall...
And one last thing - we need to submit letters to IMLS that certifies each partner's contributions to the cost share. Our grant admin Tracy has been reaching out to the business reps at each of the museums, and she hasn't received a reply. I'll be sending out individual emails to each partner to facilitate this, so please look for that to come soon.
As always, please let me know if you have questions or concerns. Happy holidays to everyone!
Sincerely,
Katherine
Wednesday, December 15, 2010
Intellectual Property and the Safeguarding of Traditional Culture
I just came across this publication from WIPO (World Intellectual Property Organisation) and thought that it highlights areas of museum resources that we have not exactly been ignoring, but have not really considered very much. These include the vast number of photos, archives and/or other documentation held by many museums. I recommend that everyone have a read of this. You can download the report here:
http://www.wipo.int/freepublications/en/archive.jsp?cat=&year=2010&title=intellectual+property+traditional+cultures
Robin
http://www.wipo.int/freepublications/en/archive.jsp?cat=&year=2010&title=intellectual+property+traditional+cultures
Robin
Sunday, November 14, 2010
Some web history
I came across some in-house papers that have never been published from when we were doing some very early work on the Web in the mid-1990s. I was fascinated by how much the ideas overlapped with what we are doing now, so I decided to publish them on my blog. Have a look if you are interested. Only the first is up so far, Toys For Boys, but I will be putting the others up too.
Best
Best
Thursday, November 4, 2010
Interim Performance Report - October 31, 2010
IMLS Interim Performance Report Narrative
Creating Collaborative Catalogs: Using Digital Technologies to Expand Museum Collections with Indigenous Knowledge
Grant number: LG-24-09-0106-09
October 31, 2010
PI: Ramesh Srinivasan, UCLA – srinivasan@ucla.edu
Creating Collaborative Catalogs: Using Digital Technologies to Expand Museum Collections with Indigenous Knowledge
Grant number: LG-24-09-0106-09
October 31, 2010
PI: Ramesh Srinivasan, UCLA – srinivasan@ucla.edu
We have made much progress on the four major goals we have had in this first 12 months of the project period, and we have accomplished much in the six months since our last performance report.
1. Planning, selection of collections, digitization (October '09-August '10)
During the last six months, we have accomplished much in the outstanding areas of collections digitization for our project. In the time since our last performance report, the Denver Museum of Nature and Science has completed the imaging and digitization of 667 selected objects, including historic photos, that remained to be done, and these images will be populated into the Collaborative Catalog system very soon. The MAA is about 60% of the way through digitizing the historic archives from the 1920s excavations at Kechiba:wa which they expect to complete before the end of the year.
2. Collaborative Catalog design and build (November '09 - October '10)
Since our last report, we have made some progress in terms of the design and build of our collaborative catalog.
One bit of luck that we have had in terms of system development is that Questor Systems (the makers of the Argus catalog that several of our partner museums are using) has recently been purchased by SydneyPlus. This is a promising development for our project, since Questor had previously been unenthusiastic about supporting the interoperable data-handling that we were asking for, which made for a challenging time in developing the collaborative catalog. The new owners of the Argus system are still talking about making an add-on for the upcoming Argus that will allow for the data to be fed out via the ATOM protocol (which is a good thing for our project since this kind of feed is both easy to use and can be read by many local databases). ATOM feeds will also best accommodate our pubsubhubbub interfaces. We are in an ongoing conversation with SydneyPlus to see if they can prioritize this aspect of their system development, but for the moment it is a low priority for them.
However, with the appointment of our developers for linking systems (Dafydd Harries and Tony Garnock-Jones) we are moving forward with developing systems that will not rely only on ATOM feeds but on a separately managed dataset. This means that we will be able to share data regardless of the database systems used by the individual museums. This is necessary as now the DMNS and a peripheral partner, the Maxwell Museum, are abandoning ARGUS for other systems. The current goal is to develop a linking system that will allow linking to whatever database or CMS is at either end for maximum scalability.
3. Data transfer (partners to AAMHC) (March '10 - June '10)
We have achieved a significant milestone in terms of our data transfer goal. The preliminary data transfer has been completed. We are still waiting for all of the related images to all get populated in the database, but since this is linked to the almost-completed digitization goal discussed above, this step will get completed very soon. We have a rich repository of data, although some work remains to be done towards tying in the images with the data. Our goal is to include as many images as possible, since images are such an important indicator of the physical existence of objects. All our research so far into what users want in the collaborative catalog underscores the importance of images.
4. Catalog launch, use, and evaluation (Present – June '12)
In the current version of the Collaborative Catalog, we are still working towards populating the database with every record. Instead, in the prototype of the catalog that is currently in use, the collection limited to a portion of the total collection (images and records related to the Zuni Day School), in order to test the interface and work through any problems. This sub-set of the collection also relates to an upcoming exhibition being launched at AAMHC.
According to our partners at AAMHC, the work that we have done so far on the Creating Collaborative Catalogs project has been very helpful for how the AAMHC has approached the Zuni Day School collection, both in terms of cataloging and in developing interpretive material. The process and attitude towards collections has shifted: each catalog record is viewed as a first step in the process, rather than the final voice about this image or drawing. Because we know that these records will be added to and expanded, the process of cataloging and preliminary data entry for minimally documented collections is fundamentally different. Our colleagues report that they are looking forward to what other people will add to these records.
Our partners at the AAMHC also report another important development which can be attributed to the work on the Creating Collaborative Catalogs project. They report that this project is changing the way they are working with outside experts, helping to reestablish a level of confidence and assurance in working with outsiders which has been eroded over time. Not only do they trust the people to appropriately handle the materials being entrusted to their care, they are assured that the system we develop will be created appropriately.
Something else that we have done is use this smaller subset of the collection to test a model for facilitating comments from community elders via the help of four community curators. These community curators have used the system to each select ten images, and along with the help of a questionnaire, each interview ten people, primarily older Zunis, to gather their responses about three images of their choice. Eventually, we want community members to comment directly into the system, but our experience here reminds us that facilitating comments from elders that have English as a second language is a big challenge, but nevertheless one that we can overcome.
Some questions that we asked:
"Of the ten images you see, pick three and describe what you see."
"What did these pictures make you think about?"
"Has looking at these pictures make you think differently about your work or home life? If so, how?"
"Have the pictures made you think about how you talk with or work with your children?"
"Were you a student at the Zuni Day School? If yes, when? What did you like or not like about being a ZDS student?"
"Do you think the zuni day school pictures would be beneficial for students attending zuni schools?"
During the next phase of system development, we will be sharing the system with our Zuni cultural advisors, from whom we will be gathering feedback about the system interface and usability as well as system architecture and protocols of access. We expect to go through several iterations of design and gathering of feedback with our cultural advisors. Dr. Boast will be spending a week in Zuni this December to work with the Zuni cultural advisors to further refine and develop the prototype system.
In terms of the project evaluation aspect of our project, we are planning a partial team meeting to take place at the end of November, where we will hold the first of our focus groups about the Collaborative Catalog. We have developed a guide for conducting focus groups to assist our project team at Zuni in holding the focus groups, and the UCLA team will observe the first focus group to make sure the process goes smoothly. Our goal is to launch the catalog and have users interacting with it prior to the first of these focus groups, so we expect the catalog to go live very, very soon.
5. Other project milestones
Another project milestone worth noting is our gaining approval of our human subjects protocol from UCLA's Institutional Review Board. Because we will be conducting focus groups, and because all of the research will be conducted by AAMHC staff at Zuni under the auspices of UCLA's IRB (which presented several bureaucratic hurdles in itself), it took nearly seven months to obtain approval for our human subjects protocol. But now that we are approved to begin conducting focus groups with participants, and we have a clear date established for our first focus group sessions, we will begin the project evaluation phase at the end of November.
Thursday, September 23, 2010
A discussion of the theory behind our project
Earlier this year, Ramesh gave a presentation at a conference at NYU where he discussed some of the bigger theoretical ideas behind our project.
He starts discussing the Zuni project around minute 14. Interesting stuff!
Srinivasan from Robert Gregson on Vimeo.
He starts discussing the Zuni project around minute 14. Interesting stuff!
Thursday, August 12, 2010
Liquid Publication for the Sciences (?)
Yesterday I got a notification of a project headed by Fabio Casati, of the University of Trento in Italy, which could be of interest to us. It is a Framework 7 project (an EU funded project) which, according to their website, "proposes a paradigm shift in the way scientific knowledge is created, disseminated, evaluated and maintained. This shift is enabled by the notion of Liquid Publications, which are evolutionary, collaborative, and composable scientific contributions. Many Liquid Publication concepts are based on a parallel between scientific knowledge artifacts and software artifacts, and hence on lessons learned in (agile, collaborative, open source) software development, as well as on lessons learned from Web 2.0 in terms of collaborative evaluation of knowledge artifacts."
I am not yet sure, as it is not certain what exactly they mean by this, but such an idea could have consequences for our future work. I will contact Casati and see what this is all about and report back.
Best, R.
I am not yet sure, as it is not certain what exactly they mean by this, but such an idea could have consequences for our future work. I will contact Casati and see what this is all about and report back.
Best, R.
Wednesday, August 11, 2010
Paper 1 is FINALLY published!
After two years of being 'in press', our first paper to be completed and submitted has finally come out!
This is possibly our most important paper, and features an informational graphic that I created (and of which I am quite proud):
"As museums begin to revisit their definition of ‘‘expert’’ in light of theories about the local character of knowledge, questions emerge about how museums can reconsider their documentation of knowledge about objects. How can a museum present different and possibly conflicting perspectives in such a way that the tension between them is preserved? This article expands upon a collaborative research project between the Museum of Anthropology and Archaeology at Cambridge University, University of California, Los Angeles (UCLA), and the A:shiwi A:wan Museum and Heritage Center to compare descriptions of museum objects by multiple expert communities. We found that narratives and objects in use are key omissions in traditional museum documentation, offering us several possibilities to expand our concept of digital objects. Digital objects will allow members of indigenous source communities to contribute descriptive information about objects to support local cultural revitalization efforts and also to influence how objects are represented in distant cultural institutions."
This is possibly our most important paper, and features an informational graphic that I created (and of which I am quite proud):
Wednesday, August 4, 2010
paper brainstorming - typology of digital collections - more thoughts
So I've had a chance to do some brainstorming about this 'digital collections typology' -- thinking about the variables that we can use to compare the different projects that use digital technologies to share their collections with stakeholder communities.
The first one that emerged was How is source community knowledge regarded?
On one end of the spectrum there are projects that use the language of sharing: knowledge is given, collected, enhances collections information. The majority of the projects I've seen fall in this camp, I think.
On the other end of the spectrum, there are projects that recognize that knowledge is not monolithic: there is dialogue and sometimes disagreement, there are multiple perspectives about objects -- the incommensurability that we keep talking about in some of our earlier papers.
Another variable that we might use is How are users regarded?
Are they active agents in producing information? or passive consumers of information?
-- a related issue to this one is how easy is it for a user to contribute to the catalog? Is it as easy as filling in a field and pressing 'submit'? or are there more steps involved in becoming someone the museum thinks worthy of contributing to the collection information?
There were several other issues that I thought of, but they did not seem to fall on a spectrum or axis:
-- local use of information -- how is the information used locally? do the projects acknowledge that collections information can be used in unexpected ways within source communities? do they facilitate this local 'life' of information?
-- identification of individual contributors -- whether the 'community knowledge' comes from named individuals, or if it's added in without identifying who it came from.
I'm sure other issues will emerge, and I will refine (and possibly combine) some of these variables, but that's what I have for now.
The first one that emerged was How is source community knowledge regarded?
On one end of the spectrum there are projects that use the language of sharing: knowledge is given, collected, enhances collections information. The majority of the projects I've seen fall in this camp, I think.
On the other end of the spectrum, there are projects that recognize that knowledge is not monolithic: there is dialogue and sometimes disagreement, there are multiple perspectives about objects -- the incommensurability that we keep talking about in some of our earlier papers.
Another variable that we might use is How are users regarded?
Are they active agents in producing information? or passive consumers of information?
-- a related issue to this one is how easy is it for a user to contribute to the catalog? Is it as easy as filling in a field and pressing 'submit'? or are there more steps involved in becoming someone the museum thinks worthy of contributing to the collection information?
There were several other issues that I thought of, but they did not seem to fall on a spectrum or axis:
-- local use of information -- how is the information used locally? do the projects acknowledge that collections information can be used in unexpected ways within source communities? do they facilitate this local 'life' of information?
-- identification of individual contributors -- whether the 'community knowledge' comes from named individuals, or if it's added in without identifying who it came from.
I'm sure other issues will emerge, and I will refine (and possibly combine) some of these variables, but that's what I have for now.
Thursday, June 24, 2010
monthly status reports ?
I've been thinking recently that it might be a good idea to implement a more regular system of keeping in touch and updating each other on the status of project tasks -- something like a check-in / status update. Towards that end, I would like to start doing a monthly email where each of the project partners is given a chance to report on the status of things on their end. Just so we're in better touch with each other, on a more regular basis, since we've all been busy this spring, and a bit more out of touch than I would like.
I'm hoping to also post some of those more informal updates here on the project blog, so that it becomes a resource that we can refer to later. I encourage you all to subscribe to be notified of blog updates -- I've been starting to update it more frequently, with interesting info both about our project, and similar projects underway at other institutions. You can enter your email where it says "Subscribe via email" at the top left of the page.
To kick off the conversation, the following is a list of tasks that are still in process, and I'd love folks to chime in where they have something to include.
Current tasks:
- catalog data transfer to Robin (should be finished already, or near to finished)
- DMNS photography/digitization -- how are things going on that, Chip?
- working towards the catalog launch -- Robin, what remains to be done, and can any of us help? And Jim, is there anything you need on your end?
- catalog evaluation -- I'll be starting to finalize the questions and instructions for Jim and the team at Zuni for running the focus groups. I'm also STILL working with UCLA's IRB to get the human subjects paperwork all taken care of.
Thanks for staying in touch, everyone! Hope you all are well.
Wednesday, June 23, 2010
paper brainstorming - typology of digital collections
Ramesh and I had a conversation last week where we talked about digital museums/collections -- an area of research that I've been working on recently (and posting about on this blog: here, here, and here). Eventually this will be developed into a paper, and I wanted to put some of our ideas up here on the blog for everyone's discussion and consideration.
The important thing is to situate our project relative to other digital institutional collections-based projects that are working with communities. Looking at the institutions, and the systems. Not necessarily all indigenous communities, but it wouldn't be a bad thing if all our examples had that in common.
Eventually this will be developed into a paper that is a justification for our project relative to what's out there. With a title that's something like "Enabling Voice in Digital Collections" (have to define what we mean by voice, and how different systems enable voice). The key would be to extract that model/ those variables and placing different projects along an axis/axes. Possibly we can include some evaluative data from our project, but maybe not (depending on whether it ends up being relevant).
- Once I've looked through a bunch of examples, Ramesh wants me to build a typology of sorts, based around how these digital collections work with new media and allow other ways of interaction with communities.
- Creating it so that it's not just a list, but a landscape of what's out there in terms of these digital collections (not digital museums, because we're not talking about online exhibits, but rather online catalogs).
- Articulating their relationship with one another and with our project
- Based around certain variables : ie. use of blogging, semantic tagging, other sociotechnical issues
- thinking about different axes - mapping those examples, then presenting in context, and comparing/contrasting with where our project stands
- also addressing a larger set of questions about how information institutions open up and represent other voices, and the sociotechnical issues that come up
The important thing is to situate our project relative to other digital institutional collections-based projects that are working with communities. Looking at the institutions, and the systems. Not necessarily all indigenous communities, but it wouldn't be a bad thing if all our examples had that in common.
Eventually this will be developed into a paper that is a justification for our project relative to what's out there. With a title that's something like "Enabling Voice in Digital Collections" (have to define what we mean by voice, and how different systems enable voice). The key would be to extract that model/ those variables and placing different projects along an axis/axes. Possibly we can include some evaluative data from our project, but maybe not (depending on whether it ends up being relevant).
Thursday, June 10, 2010
Things to think about : questions from IMLS
Ramesh was just telling us about his recent meeting with the team from IMLS that came to Los Angeles for the recent AAM meeting. They had some important questions/points to consider, and I wanted to put them here for us to start thinking about and possibly responding to.
A. First of all, they wanted to know more about the system -- what it is going to look like, whether there will be a web page or something for public access (and by public I assume they mean everybody, not just 'public' (in-person) access at a terminal at AAMHC). Also, they were curious what the Zuni interface would look like. I think that we're getting to a point where we might start having something to show off (right Robin?) -- at the very least we have the working Filemaker Pro database that Robin and Curtis have been tinkering with, based on the catalog that the DAM sent to AAMHC last year. I think Robin will have to say more about this.
B. Something else they mentioned was the UIUC (University of Illinois Urbana Champaign) Digital Collections and Content portal.
I've seen this site before, possibly when we were working on the grant application? It seems that IMLS is encouraging their funded digital projects to participate in this portal, in essence placing all of their digital 'eggs' in one basket. Which I am not sure is exactly what we are going for -- it appears to be a big giant portal that allows access to all these nifty collections, but you still have to go through the portal to get at the collections. As laudable a goal that the interoperability of collections metadata is (with larger and larger portals), sticking it all in one place like this is just one method for making technology work better between museums and source communities.
In reference to this UIUC portal, Robin made the point, "what we are trying to do is to make real event driven data sharing." Meaning that rather than having to go through one of these portals to get at interesting information, that information is being pushed towards you (triggered by an 'event' such as an upload or annotation to a catalog record). Again, this event-driven data sharing issue goes back to the idea behind WebHooks, which I talked about in an earlier post.
C. Also, they are wanting to know more about how this project can be sustainably adopted at Zuni, and how our project can easily scale to other museums and other indigenous communities. I think the important point to make here is to focus on the 'information push' aspect of what we're doing. The biggest thing we're doing here is not that we're building a local database at Zuni with catalog records from all the different partner museums, but that we're essentially connecting that local database with the catalogs of the partner museums in a way that data can get pushed back and forth -- this connecting piece is the thing that we hope will scale to other museums and other communities. Reinventing the museum catalog as something that many communities have something to contribute to -- curatorial experts and source communities both.
So in essence, what we have to offer to other museums & source communities are two sides of the same coin -- on the one side, an ethical/social/political stance that wants to open up the way that information is accumulated and shared in museum catalogs; and on the other side, a concrete technological way of making that happen.
A. First of all, they wanted to know more about the system -- what it is going to look like, whether there will be a web page or something for public access (and by public I assume they mean everybody, not just 'public' (in-person) access at a terminal at AAMHC). Also, they were curious what the Zuni interface would look like. I think that we're getting to a point where we might start having something to show off (right Robin?) -- at the very least we have the working Filemaker Pro database that Robin and Curtis have been tinkering with, based on the catalog that the DAM sent to AAMHC last year. I think Robin will have to say more about this.
B. Something else they mentioned was the UIUC (University of Illinois Urbana Champaign) Digital Collections and Content portal.
I've seen this site before, possibly when we were working on the grant application? It seems that IMLS is encouraging their funded digital projects to participate in this portal, in essence placing all of their digital 'eggs' in one basket. Which I am not sure is exactly what we are going for -- it appears to be a big giant portal that allows access to all these nifty collections, but you still have to go through the portal to get at the collections. As laudable a goal that the interoperability of collections metadata is (with larger and larger portals), sticking it all in one place like this is just one method for making technology work better between museums and source communities.In reference to this UIUC portal, Robin made the point, "what we are trying to do is to make real event driven data sharing." Meaning that rather than having to go through one of these portals to get at interesting information, that information is being pushed towards you (triggered by an 'event' such as an upload or annotation to a catalog record). Again, this event-driven data sharing issue goes back to the idea behind WebHooks, which I talked about in an earlier post.
C. Also, they are wanting to know more about how this project can be sustainably adopted at Zuni, and how our project can easily scale to other museums and other indigenous communities. I think the important point to make here is to focus on the 'information push' aspect of what we're doing. The biggest thing we're doing here is not that we're building a local database at Zuni with catalog records from all the different partner museums, but that we're essentially connecting that local database with the catalogs of the partner museums in a way that data can get pushed back and forth -- this connecting piece is the thing that we hope will scale to other museums and other communities. Reinventing the museum catalog as something that many communities have something to contribute to -- curatorial experts and source communities both.
So in essence, what we have to offer to other museums & source communities are two sides of the same coin -- on the one side, an ethical/social/political stance that wants to open up the way that information is accumulated and shared in museum catalogs; and on the other side, a concrete technological way of making that happen.
Wednesday, June 9, 2010
ECHO project
I'm following up with a few more interesting projects from the Museum 3.0 discussion I mentioned in the last post.
From their presentation at Museums and the Web 2008:
"ECHO (Education through Cultural and Historical Organizations) is a federally funded partnership of six cultural institutions in Hawai'i, Alaska, Mississippi and Massachusetts linking Native and non-Native communities, and re-connecting Native people with collections of Native American art, objects and history."
The current list of institutions involved are the Alaska Native Heritage Center, the Bishop Museum in Hawaii, the Mississippi Band of Choctaw Indians, North Slope Borough, and the Peabody Essex Museum -- quite a geographically dispersed group!
The focus of the project's collaborative websites seems to be more oriented towards highly-polished, content-heavy web-presentations, rather than relying on emergent, Web 2.0-style systems to produce content. What they have achieved in terms of institutional collaboration is laudable, but upon closer examination that's one of the only similarities this effort has with our project. The thrust of what they are doing seems to be more focused on the collaboration between institutions rather than how institutional collaborations can also involve communities directly, getting them to produce content and participate in catalog creation.
Most relevant to our project is the ECHOspace website, which is a shared catalog portal of the different partner's collections. Again, though, users are not seen as agents of participation, but rather just consumers of the information.
Closer to what we're aiming for is another related website, Artscape, which was created by one of the ECHO partners, the Peabody Museum. According to the Archives & Museum Informatics presentation,
"it includes two innovations addressing needs most clearly voiced, in PEM’s experience, by Native museum professionals and communities. First, the structure of the database is open, allowing, for example, for multiple documents, images, audio or video files to be attached to a single object, and allowing for commentary from multiple viewpoints – consulting curators or cultural experts, for example – to be attached to a single object record."
I like the user interface on this museum's site, with three different areas permanently on the screen -- the upper area is for a user's personal collection, the middle area is for searching and looking closely at catalog entries, and the lower area is for reviewing search results via thumbnails and titles and dates when the user mouses-over. Despite the nice interface, and the claim above, the ability for a user to participate is limited to this 'personal collection' thing -- no way to annotate or contribute to entries. It is not clear what happens when "cultural experts" have something to contribute or correct in the catalog.
From their presentation at Museums and the Web 2008:
"ECHO (Education through Cultural and Historical Organizations) is a federally funded partnership of six cultural institutions in Hawai'i, Alaska, Mississippi and Massachusetts linking Native and non-Native communities, and re-connecting Native people with collections of Native American art, objects and history."
The current list of institutions involved are the Alaska Native Heritage Center, the Bishop Museum in Hawaii, the Mississippi Band of Choctaw Indians, North Slope Borough, and the Peabody Essex Museum -- quite a geographically dispersed group!
The focus of the project's collaborative websites seems to be more oriented towards highly-polished, content-heavy web-presentations, rather than relying on emergent, Web 2.0-style systems to produce content. What they have achieved in terms of institutional collaboration is laudable, but upon closer examination that's one of the only similarities this effort has with our project. The thrust of what they are doing seems to be more focused on the collaboration between institutions rather than how institutional collaborations can also involve communities directly, getting them to produce content and participate in catalog creation.
Most relevant to our project is the ECHOspace website, which is a shared catalog portal of the different partner's collections. Again, though, users are not seen as agents of participation, but rather just consumers of the information.
Closer to what we're aiming for is another related website, Artscape, which was created by one of the ECHO partners, the Peabody Museum. According to the Archives & Museum Informatics presentation,
"it includes two innovations addressing needs most clearly voiced, in PEM’s experience, by Native museum professionals and communities. First, the structure of the database is open, allowing, for example, for multiple documents, images, audio or video files to be attached to a single object, and allowing for commentary from multiple viewpoints – consulting curators or cultural experts, for example – to be attached to a single object record."
I like the user interface on this museum's site, with three different areas permanently on the screen -- the upper area is for a user's personal collection, the middle area is for searching and looking closely at catalog entries, and the lower area is for reviewing search results via thumbnails and titles and dates when the user mouses-over. Despite the nice interface, and the claim above, the ability for a user to participate is limited to this 'personal collection' thing -- no way to annotate or contribute to entries. It is not clear what happens when "cultural experts" have something to contribute or correct in the catalog.
Subscribe to:
Posts (Atom)