Friday Sep 25, 2009

Enterprise 2.0, Evolved

[Read More]

Monday Sep 21, 2009

Ten Requirements for Achieving Collaboration #5: Data Portability & Referencing

We are in the midst of a series investigating collaboration. We previously wrote about the two types of collaboration - intentional and accidental. INTENTIONAL: where we get together to achieve a goal and ACCIDENTAL: where you interact with something of mine and I am never aware of your interaction While intentional collaboration is good it is not where the bulk of untapped collaborative potential lies. Accidental collaboration is. But the challenge is to intentionally facilitate accidental collaboration. For the full list of 10 requirements see the original post. Last time I wrote about requirement #4: why we must be sure to enable the humans. While it is great if humans are empowered to consume, we must keep it easy for them to do so. Therefore enter requirement #5: the importance of data portability and ability to be referenced. After all, if we go to all that work to identify and extract data from content containers then it is a simple next step to ensure that the data is located where we want it when we need it. Well here we are. If you have followed along, we have identified data residing inside of documents, we have exploded content items, we have jail-breaked data-and-relationship assertions and made it easy for people to add their own experiences and expertise to those growing data sets. That is all well and good if and only if there is a consistent way to move that data around, to relate it to other data that may be and usually is in a different schema, and finally to address and obtain that data. This is practically taken for granted with traditional relational databases and on the web. After all, the primary key uniquely identifies a record, the URL uniquely identifies a document on the web. We can get it, move it and relate it to other bits of information.
return-to-sender.jpg
But isn't it curious that we reference items differently depending on where they're located. We need to know the structure of data first before we can even think about trying to reach it. Web pages have URLs, DB Records have primary keys, filing cabinet files have a physical location, you and I have a postal address. That makes it awfully hard to combine data sets, perform meaningful comparisons or combine expertise with the confidence that we're not leaving out the most important information available simply because it is addressed differently.[Read More]
About

Enterprise 2.0 and Content Management

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today