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.

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.

  

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"

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.

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?

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.

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