Wednesday, May 26, 2010

Because it's a while since I've 'blogged about

Here's an idea: SourceForge is connected with a great community of open source developers; Twitter is connected with a great community of individuals, some of whom are open source developers. One of the great value propositions for me for Twitter is that rather than following an open source project, I can follow the projects creators, and receive timely information about updates, patches and the like... as long as I am actually logged into a Twitter client when the update in question is pushed out. There is a lot of noise.

Yammer is great for organizational transparency, or so I've heard from people who are using it, but it's a walled garden - I wonder what would happen if a similar approach were taken with an open source repository like SourceForge? What if an open source status network like were hosted and synchronized with the group of individuals with SourceForge projects? Then you could follow this entire list or a segment of this list, and get updates in a timely fashion without the background noise, or aggregate this stream into the broader stream that you might normally follow.

Might inject a bit of life into the open source community as well.

Saturday, May 15, 2010

The other side of transparency

Really quick, I just wanted to jump in and say, with regards to Facebook privacy, there is another situation that I have yet to see adequately described. The situation I am seeing described is when you publish a piece of yourself, and it goes further afield than you anticipated, ie you share photos with someone with whom you had no intention of sharing.

But consider the obverse situation, when you publish a piece of yourself to your social circle, and it is withheld for some reason from a portion of this circle because of a change in privacy setting, or confusion about the impact of the privacy settings you have selected.

In many ways, this may create more distrust in the platform, when someone in your social circle feels slighted because they did not receive the expected update. Of course, this happens with email spam filters as well as social network privacy settings. In either case, it creates an atmosphere of distrust in the platform.

Friday, May 14, 2010

Tab Sweep - 2010 05 14

Dare Obasanjo on Facebook:

Facebook’s Open Graph Protocol from a Web Developer’s Perspective

danah boyd on Facebook:

Facebook and "radical transparency" (a rant)

Not surprising that Facebook is facing criticism; I appreciate danah's demonization of transparency, and the distinction she draws between being exposed and exposing oneself. One of the things I appreciate about Twitter is that the level of exposure of any conversation I have there is dictated directly by the object graph of those involved in the conversation. If I want to curse and swear, I can engage someone in a conversation with whom this is appropriate. But there is always a risk of exposure.

Dare's point is also well taken on many levels, but particularly from my viewpoint, ontologically speaking, that Facebook is leveraging RDFa and not microformats, and that RDFa is an exponentially more robust technology specifically due to the use of namespaces. And what better way to identify arbitrary URIs as social objects than by using namespaces? In issues of transparency and privacy, it seems that disambiguation, ie clarification of social context will become increasingly important.

Reread danah's rant, especially the Zuckerburg quotes referring to the artificiality of sustaining a multiple identity. My own reaction to this is equally violent, and I call BS - all relationships in a social graph are virtualizations or supplementation of something that they are not, actual relationships. They are by definition artificial and demand disambiguation.

My travels in Flex-land keep coming back to the importance of namespaces outside the strict context of XML. Their time is coming; more widespread use of RDFa and the need for disambiguated rather than radical transparency are definitely indicative of this.

Wednesday, May 05, 2010

Seminal Granularity: I <3 the </>

It's no secret, I love me some XML, whether as an exchange format like XBRL, a messaging standard like HL7 or NIEM, or a document framework like DITA or DocBook. I am not sure what appeals to me so much about data-enrichment using tags, but it has something to do with reducing entropy by adding structure and meaning. In addition, I would rather model something using the sort of extension and restriction available in NIEM than the classical inheritance strategies presented by OOP. I have heard from several sources recently that the seachange from an object-oriented to declarative paradigm is underway, and I am pleased.

But more than this, I just love the angle brackets in a way I could never feel about dot-notation, and I am not alone in this.

I am attempting to develop a notion I am calling "Seminal Granularity." This notion appeals to my background in structuralist literary theory - "seminal" and "granular" are both agricultural references, both seeds, but whereas "seminal" has patriarchal overtones, granular is more mercurial. Between the two axes there lies a tension, bringing to mind a transclusive dilemma.

Simply stated, the transclusive dilemma is this: when faced with modifying an object, do you create a reference to the object for modification, a seminal approach which binds the new object to the original; or do you create a clone of the object, a granular approach which results in modification to the new object becoming estranged from the original, releasing the object through mimesis.

A viral licensed open-source project, for instance, is by design both seminal and granular. The project itself exists as a single seed, and it allows granular modification with the caveat that modifications are returned to the original seed.

Edit: there is also an odd kind of tie in with this short story, The Ice Box.

The transclusive dilemma is a real phenomenon; you cannot do both. Seminal granularity should be about finding ways to negotiate this problem. A wave can't be a particle either, right?

Tuesday, May 04, 2010

Talking Points: Collaboration and Documentation

A few years ago I wrote about a project I developed for my then employers, which I open sourced under the name CaseBook. The intent was to single-source end-user documentation which could be be transformed into internal and client acceptance test scripts. As I developed it, the project involved XML, Schematron, XSL and XQuery, hosted in an eXist database and accessed using webDAV.

At the time, I had barely heard of DITA, the Darwin Information Typing Architecture, but the approach I took shared some ideas with what I later came to learn about DITA, using concept maps, separation of topics into tasks and steps and so forth. In the mean time, DITA has gained a lot of traction, and my SourceForge page has been hit maybe 500 times.

I have been giving a lot of thought lately to collaborative writing. As Anne Gentle has pointed out on her JustWriteClick 'blog, DITA shines in environments which have a strong collaborative or Agile approach, since both of these emphasize timely repurposing and multipurposing. One of the problems I was addressing with CaseBook was collaboration between development, documentation and testing resources. Now, in part, this was because I was working in a small team, and had responsibilities in each of these areas.

I still think there is a lot of value in facilitating collaboration between these groups, and were I to develop this project today, I would start with the DITA Open Toolkit from day one.

In addition, for the last four months, I've been working with Flex, mxml and ActionScript. One thing that intrigues me about mxml is that it is XML. For instance, what if you could generate end user, acceptance or client walkthrough documentation automatically from the mxml source? Transforming mxml to DITA seems like a useful technique.

Any thoughts?