New tool in town: KnowledgeGenes.com

Yesterday I discovered a nice tool on the internet called "Knowledge Genes(r)".It is a form of knowledge management which can be shared with everybody or for specific persons or a specific organization. Today I started experimenting with the tool.

The definition of a knowledge gene
A knowledge gene is a structured representation of an action and its function described by its why and how. It can be extended with what and what-is information. In the code of knowledge (r) the possibilities of the knowledge genes(r) are described.

When to use Knowledge genes (r)
Knowledge genes(r) are process centric. The central element of a knowledge gene is an action, which consists of an optional subject, a verb and the object. The central element can be expanded with a why and a how element both of which are structured the same way as the action element. The what and what-is elements are plain text elements.

It is cleat that you can use it to structure and relate knowledge genes to make sure some information about your company or any social entity is documented.  The question that arises for me is what makes this tool special in comparison to the more classic process documenting tools. I haven't got the answer. In the other tools I know you have more options, but require specialists to create the documentation.
Knowledge genes(r) however can be created by anyone visually, which has an advantage. It is freely available "in the cloud" for individuals and for a monthly amount for enterprise users and it can even be installed locally. So it has advantages over the more traditional options. It is up to the decision makers if this tools will fit all your requirements. I am going to use it as an example tool for some actions.

General considerations on knowledge management overall
Knowledge Management is somewhat of a hype in my opinioin. I think it is impossible to manage knowledge. I like the DIKW-hierarchy and I consider knowledge as a product that only exists in the knower's mind in this case there is only knowledge management on person level and the information where the knowledge is built upon can be shared and managed.

I alse think there is needed more data/information to successfully make it possible to understand something like a knowledge gene. I miss the option to make good definitions for the subject or object and to interrelate these to other terms or a thesaurus or ontology. It would help a great deal for understanding if there can be added more metadata.

Conclusion
I think KnowledgeGenes.com is a good tool for documenting your business processes, but not for documenting knowledge. Even more I would like to see functionality in the tool where you can integrate the knowledge genes into a website or a tool where you can submit a document to the website and you get a result where all known genes will be incorporated.

The things every IT Professional should know about XML Schema design Part 2

Last time I wrote about the namespace design and its versioning issues. Today I will write about the difference between the <xsd:import> and the <xsd:include> statement.


Import versus include

There is a major difference between the include and the import statement originating from the design of the XML schema.

The <xsd:import> statement was introduced to use components from a schema file with its own namespace in the current schema. Using the <xsd:import> statement in coorporation with xmlns:abc= attribute in the xsd:schema statement referencing the schema the components of the imported schema can be used by using the namespace token.

The <xsd:include> statement was introduced to combine multiple files which all have the same namespace. Its original design was to combine the files of one namespace which spanned multiple physical files. Splitting the namespace into multiple physical files can have advantages like performance advanages or clustering functional elements together in a file for better understanding.
One of the characteristics of the include sttement is that it hides the namespace. The components of the included schema can be used as if they are part of the targetNamespace. This can introduce problems when elements have the same name. And when using include the context of the original namespace is lost. So when having a namespace design which has a functional meaning this is an absolute no-go area.
 
Summarized
The Pros of import
- Explicit usage of components of other namesapces, which enables impact analysis for changes.
- Clear usage of components even when using the same name twice.
- Requires strict design of the schema

The Pros of include
- Enables splitting of files

The cons of import
- None

The cons of include
- Namespace is lost
- The includes are incorporated in a client side component into one phisical file. This deminishes the pro of the include in the usage scenari of XML schema in services.

Combining include and import
There are scenarios when a combination of the import and include statement are applicable. It is recommended when having large XML schema files to split them. This can be done by either splitting the files and only using thos files with the include statement or by reconsidering the namespace design. When the latter choice is chosen the need for include is absolutely zero.

The things every IT Professional should know about XML Schema design Part 1

In my every day work I see a lot of XML stuff going by. Usually the quality or schema design of the validating XML Schema is not good enough to be constructive and reusable. The thing I started to wonder about was why?


There are some basic rules a good XML Schema complies to. It all starts with thinking and documenting the general schema design pattern (the five are Russian Doll, Venetian Blind, Salami Slice, Garden of Eden and Bologna). It is a simple choice to make, and there is lots of information available on the net with the pros and cons for each choice. My personal favorite is the Garden of Eden and I recommend this for everyone considering building a corporate, domain or canonical datamodel based on XML technologies.


The second thing to really think about is namespace design. Good namespace design is practical and will work for you in understanding the domain you are talking about. Some guidelines I use when making my namespace design:
1) Make it urn based, not protocol based;

• Not OK: http://www.free-your-energy.nl/
• OK: urn:nl:free-your-energy:schema:data

Rationale: Protocol based suggest that the XML Schema can be found at that address, while this is usually not the case. URN based namespaces are more expressive.
2) Use the major version in your namespace, so no dates but major versions;

• Not OK: urn:nl:free-your-energy:schema:data
• Not OK: urn:nl:free-your-energy:schema:data:20090918
• OK: urn:nl:free-your-energy:schema:data:1

Rationale: Major version in namespace will guarantee compliancy througout this major version. Anything that doesn't use a version will result in problems when making a new version or release. Dates don't tell anything.
The upcoming weeks I will elaborate in detail on XML Schema design with more tips.

My first...

Starting in july I will post weekly about my adventures and thoughts of the data and information architecture domain.

The first series of articles will be about the "common vocabulary" which I regard as a very important asset of an organisation, especially for IT architecture purpose.

The second series of articles will be about a more in-depth subject namely "the canonical data model". I know there's lots of stuff out there written on the subject, but there are still some things I would like to see clarified.

After these series I want to write on different subjects, but those are not clear in my head yet.

See you in the future,


Ric