On May 9, 2005, at 6:48 AM, jasonwhat wrote:

http://drupal.org/node/21940#comment-38421 In this post I talk about some of the various modules out there that let users create data about themselves, data on other users, and relationships. What seems clear to me is there is development going on in CS and Drupal and Civicgroups of several similar user managemnt and organanization tools. I brought this issue up here http://civicspacelabs.org/home/node/ 12285 and realize that maybe the CivicCRM is the to omnipotent api that will unify all several modules. If I'm correct, the CivicCRM won't just have it's own data fields, like the current contact module in CS, but will share with modules like profile once they are updated to work with it.

Actually you don't want to normalize on CivCRM. Thanks for opening that giant can of worms ;-) We need to normalize on a common set of labels for our community member data. But first let's talk about the types of data. The three types of data we want to capture are reference data, relationship data, and activity data. The reference data must be qualified because as you noted it could be coming from any kind of social software application. You can think of reference data as name, number, address, etc. Unfortunately, it could also come from buddylists, petitions, or volunteer lists. That reference data must be qualified for the source which the reference data came from. I have been meaning to identify a common set of labels for community member data but haven't got around to it. I believe that CivCRM has done a good job with their data model. But they are focused on the non-profit sector and as a result it's possible that their model doesn't include reference data that you might consider critical such as blog, or xfn. There model is flexible and can handle these changes. The point is that CivCRM has a public data model and how they map internally is up to them, but as long as other member data applications can normalize to an agreed set of labels in the community we should not have a problem. This is very important exercise and should happen soon. Once we have a Drupal blessing, a non-profit blessing, a political blessing, and a social software blessing of our reference labels we can do something very important. We can create a set of master textual descriptions of data types known as conformed dimensions. With conformed dimensions we can query multiple data sources, or data marts. Querying across multiple sources is known as drilling across or a multi-pass query. Overall this is refered to as a data bus- architecture. Most folks in Drupal land assume that they will always have a single database. But anyone in the political or non-profit field will tell you that decentralized data sources is a fact of life that you just have to get used to. A data bus architecture is how you design your data infrastructure to be able to be accessible. This might seem like overkill but sometime in the next several weeks CRM will be merged with Drupal. When that happens leaders of communities are going to start asking questions about the relationship between content in the CMS and people represented in the CRM. Those questions will be unpredictable and we need the flexibility designed in to be able to answer those questions. Over time, new applications will be developed that involve social information, as you have noted is already happening. How we integrate those applications with Drupal is going to be of incredible importance to leaders who would benefit greatly by being able to ask complex questions about their communities. If we do less than a great job those questions will not be able to be answered. A good place to start would be to research SugarCRM, CivCRM, and SalesForce.com's non-profit data models. The goals would be to set a reference and relationship labeling standard that all application developer could adhere to. If they did meet that standard then it would greatly facilitate the integration of data sources into a data bus architecture. There are literally hundreds of world class engineers who have tackled these problems internally inside corporations. Just as all the Unix expertise poured out of companies into Linux there is an opportunity for all this data integration expertise to pour out into getting CRM and CMS integration done right. They are just waiting in the wings watching to see what happens. I hope you take up this challenge. Cheers, Kieran

If CivicCRM seems like the place to unify all this then I think there needs to be a more visible way to get these module maintainers and developers involved now. I do believe there is a mailing list for this, but I mean a more visible acceptance from developers that the CivicCRM is what they should be looking towards, and coding towards as much as that is possible. I might be stating the obvious here, but my fear is that modules like "contact directory" http://drupal.org/node/15863 will continue to be developed duplicating the fothcoming CivicCRM. Or maybe the module is great and will ultimately be an important aspect of the CRM, but if so it would nice to have that conversation started now, rather than later. With all the posts about extending profile, or searching profiles, referrals and invites, and organic grouping, it would be nice for these developers to join in the CivicCRM discussion and development, rather than starting their own.

I see that CivicCRM was discussed at FOSDEM, but I don't know if a more general "user management" discussion has taken place or not. I'm not sure if it needs to, but just throwing these thoughts out to the wolves.

--------------------------------------------------------------------- To unsubscribe, e-mail: civicspace-dev-unsubscribe@civicspacelabs.org For additional commands, e-mail: civicspace-dev- help@civicspacelabs.org