• The PatternSmithing Alliance (http://patternsmithing.com/) is being established as a centralized organizing and guiding body for the core activities, knowledge, and applications of static pattern engineering technologies.  This site and my activities (including the book under construction) will be considered contributions to the body of work of the Alliance.
• The “ThingK” company (I am finalizing the company name so will just call it that for now) will work on several products and services that not only apply static pattern engineering technologies but also advance the field as a whole.  After research and development, I’ve seen that several viable technologies exist that can enhance people’s lives as well as the field itself – a commercial vehicle will serve the projects well throughout their lifetime to keep their growth and maintenance sustainable.
• The research and development activities on Static Pattern Engineering will still continue by interested members of the Alliance, either as a voluntary effort, projects commissioned/funded by the Alliance or government grants, and/or activities commissioned under the commercial ventures of the “ThingK” company or other participating partners.  This site will continue to track these activities that fall under the first two categories, whilst the commercial aspects will continue to drift away toward channels created by the “ThingK” company.

I wanted to make this sort of a last post that outlines the whole field (as it stands today), because  many of these aspects grew out of this research and development activity.  This blog’s posts, as well as many other posts related to these separate aspects of the field on other sites (where I’ve been busy recently), are now syndicated together at the PatternSmithing Alliance blogs at http://blogs.patternsmithing.com/.   If you are interested in monitoring the entire field and all activities —  not just the research and development aspects, I encourage you to relocate your attention there – these posts will continue to make their way there.

Also, if you are interested in the body of knowledge surrounding Static Pattern Engineering, while waiting for the publication of the first volume, you can visit the PatternSmithing Alliance wiki (link withheld until it fills up more – just created recently) which will continue to reflect the growing body of knowledge and technologies.  From the research and development side, at times the blog will preceed the wiki in terms of knowledge while at other times the wiki will preceed the blog in terms of knowledge.

To begin involvement in the activities of the field, you are encouraged to submit your information at http://patternsmithing.com/.

Finally, I want to briefly discuss the products and services of the “ThingK” company, which started as research projects here and are now in active development:

• The thingk.com web site is the site alluded to earlier surrounding the notion of ‘thingk’ as expressing a more easily graspable term for ’static pattern’.  This will be a free community web site, with a revenue model based on enhancements, that allows any person to begin working with the core tenets of static pattern engineering without any knowledge of the underlying science, research, or activities surrounding it – this was always one of my goals from the beginning.  The PatternSmithing Alliance will recommend the core standards this site will use so that user’s content will always be reusable, expandable, and exportable by them for collaboration with non-commercial interests.  This site is very central to strategy for all of the groups:
  • The research and development activities of the PatternSmithing Alliance (which this site represents) will be interested in expanding the technology and studying how user content and collaboration progresses as case studies in the state of the art of the field.
  • After creators (the users of the site) begin to see the power of persisting and ultimately creating their Thingks, the PatternSmithing Alliance may be a natural avenue for them to continue their progression into learning about the core of the field, first by simple PatternSmithing activities, and then maybe even vocationally as a PatternSmith, StaticPattern Architect, or StaticPattern Engineer.
  • The initial activities of creators (users) are hoped to lead them toward more advanced applications of Static Pattern Engineering : fluxpoints and spawned dreams.
• Whereas thingk.com is a product aimed at people already engaged in the act of creating (even if it prods them to do so) where the target is clearly identified, the DreamSpawn service works with a more nebulous concept – the dreams that begin to fascinate people but often a clearcut direction does not always manifest (sometimes for years).  By leveraging the concept of Thingks (static patterns) and the activities surrouding PatternSmithing, the service purposely guides its clients through training around the technology (and its goals) and the knowledge of PatternSmithing with the clear dedication to watching their dreams become a reality.  This is a very rational process and is only embarked on once a proper analysis and evaluation has been done.
• The FluxPoints project will eventually become a commercial product and service, but is the most advanced merging of static pattern engineering research with computer technology.  Therefore, it will be a joint venture between the research and development activity, the PatternSmithing Alliance, and the “ThingK” company for quite some time.  Essentially, it allows any Thingk (or collection of Thingks) to virtualize further by leveraging an advanced technological infrastructure for collaboration.  This ‘engine’ will be leveraged by the research and development group, the PatternSmithing Alliance, and the “ThingK” company to drive innovations and collaborations.  You can read more about it at any time at the FluxPoints blog (or via the PatternSmithing Alliance blogs which syndicate it).

Thanks.

Thingk.com will be a free community product; however, we are looking to encourage a revenue stream by offering premium tools for crafting the representation of the Thingks on the site and for patternsmithing them into the world.  I have neither the delusion that this company will be capable of inventing all of the possible ways of expressing or creating representations into the world nor the desire to corner that, so we will be looking to offer partners the ability to sell their tools on this site.  Now that brings up a few questions and all of them relate to if the site will immediately become littered with commercialism and the answer is a firm no.  That means the following things outright:

• The desire to give the web community an incredible free basic toolset for persisting, discovering, and using thingks will be fully realized — this base functionality will always be available for free.
• Opportunities to buy more powerful tools will be non-intrusive – the screen real estate will not be littered with it.  It will only be available when you really seek it out, tucked away neatly in the user interface.  Also there won’t be annoying intrusions on experience, trying to prod a user into upgrading – people are quite intelligent enough to seek out things they want.  This is not to imply that it will be difficult to find what you want or that there won’t be a good user interface once you begin seeking out premium tools.
• Users with premium tools will not have an obvious advantage over others, its just a matter of preference.  As a physical analogy, think of an art community where everyone is given a sketchpad, a basic set of pencils, brushes, and paint – the refined artist may choose to purchase an easel, premium paper, brushes, oil paint, etc; however, this doesn’t imply that either will produce better art – it is up to the artist to use the tools given or purchases along with their creativity.

The intention for DreamSpawn is to give the clients who use this service the full array of premium tools as they are made available — which brings up another point: companies and individuals who choose to do so may purchase the full array of tools available (with royalties paid to each of the partners who are represented as well).  This will be done for DreamSpawn for a reason that is explained below:

DreamSpawn is a concept I’ve been trying to tackle for years – probably since I was a teenager.  I wanted people to unlock their full potential but it would take me a long time to see the pieces of the puzzle and even more time to put them together.  I believe that once people reorient their mind toward viewing their larger dreams (which might span a large problem/solution domain) as a set of ThingKs, or thoughts on their way to becoming things, they have a whole new way of tackling the problem — this is typical analysis; however, there is a new spin on it:  By giving the dream itself (and thingks in general) value once persisted, people will begin to move forward with bringing their dreams about.

The other pieces of the puzzle attempt to solve three other problems:

• Dreams and thingks are often kept internal – and often get buried or forgotten.
• People don’t always find the right connections with other individuals and concepts – when this ‘serindipitous event’ happens in life we usually witness the great events (company foundings, product launches, etc) that we all have come to celebrate.
• We all constantly work on skills to complete our vocational work, but all too often we don’t have the general skills or specific schools to create the dreams (set of thingks) that inspire us from time to time.

These needs are addressed by thingk.com, fluxpoints.com, and patternsmithing.com – not respectively or exclusively, but overlapping in interesting ways.  DreamSpawn brings all of this together by flipping it around to one individual – giving incredible attention to that client (and forcing them in turn to give attention to their dreams) to ensure no impedances keep that from happening.  As individuals choose to invest in time, attention, and money into their dreams, I want to give them a literal arsenal of tools to obliterate potential impedances.  I want their creativity to flow and want a full support network to wipe those three bullet points above off the table for reasons why they may look back and regret not creating this or that dream.

This blog entry is not a sales pitch to get you to sign up as a dreamspawn client – in fact, we’re not ready for you – that’s why this is an announcement of the “launch” of the sister site.  This is meant to only give a larger perspective of what’s going on behind the scenes, and I’m choosing to do what future users of this site may or may not choose to do – I am persisting out publicly a set of Thingks I am actively working on to bring about as a reality.  That is, I am releasing the concepts out there to spark interest, keep myself accountable, and get the dream in front of myself and others.  Collaborators, angel investors, future partners, volunteers, and future employees, as always, are always welcome.  Contact me at http://xri.net/=joel.kotarski or on the contact form on DreamSpawn if interested (also, feedback in general is welcome).

Finally, the PatternSmithing alliance — anyone interested in joining this alliance or learning more, contact me as well.

jdk

Thingk is a union of the words think and thing, and when pronounced sounds deceptively identical to think.  I like it because it embeds a lot of semantic hints that convey what a static pattern is:

• The first word in static pattern, static, comes from Greek and Latin roots for standing, remaining, and implies persistence.  When something persists, we usually identify it (generically) as a thing.
• When you first encounter (or create) a static pattern that resonates with you, it has the effect of gathering such awareness and attention in consciousness that it seems less like a thought and more like a thing.  It usually invokes active mentation and becomes a think in Bohmian terms.  This duality, as it grows, begins to qualify it as a thingk (in the cognitive domain).
• In the physical or virtual domains, before that thingk is manifested, it is just a thought ( think ); however, as you, the creator, drive it toward manifestation, it becomes not just a thought ( think ) but also a thing that exists (stands, remains, persists) with some degree of physical persistence (depending on degree of virtuality).  Yet, behind that now existent thing is the thought(s) that resonate with the creator such that they evoke active mentation and thus are still think(s).  Thus, the manifested static pattern is a thingk spread across multiple domains (cognitive, physical, virtual).
• If you encounter a thing that you can perceive with your senses, there are thoughts that brought it to creation.  When these thoughts and the thing itself invoke resonance in a perceiver, it can be now be described as a thingk.
• When you find a talented individual with a personal connection to the work they create, you can certainly be assured that everything they create has the quality of also being a thingk.
• If you begin to approach the things you work with with the intent to turn them into thingks (or to change your work so that the things you work with have a higher rate of probably of being thingks for you), or you begin to have the intent to find thoughts that resonate enough to become thingks in consciousness and then reified thingks in the cognitive, virtual, and/or physical domains, then the nature of your creative work is transformed.

I intend to not only use this term for describing static patterns in a more easily graspable semantic framework, but also intend to use it drive the fluxpoints project further.  A fluxpoint, by criteria, will be in fact a thingk; however, I am actively working on a partner project to actively get people moving from thought => think => thingk, which will ensure a natural evolution path toward turning those thingks into FluxPoints as well as physical, virtual, and/or cognitive creations.  This will most likely be a free community web site that will allow for active work on static patterns (or thingks) with the intention of bringing them about as creations.

Until then, I still prefer to use the technical term static pattern, but after discussing this more compact and expressive reduction with people who have talked to me about SPs for years, it immediately catches on and they finally ‘get it’.  Nonetheless, this particular journal about static pattern engineering will probably continue to use the technical term – I intend to post a link to the community site once I get it going and that site will probably make scarce use of the technical term, favoring the one described in this post.

Thanks for reading.

…The virtual side of static pattern engineering is going to take further form in a new project codenamed ‘FluxPoints’. A fluxpoint will be a virtual and active representation of a static pattern (or an aggregation of static patterns) on the Internet…

[From a previous post]

Formerly called the ‘endpoints’ project, after further development of the idea I have renamed it to the FluxPoints project. The endpoints idea started as a thought experiment: provide a way for an individual or group to secure an authorative identifier for a static pattern (or aggregation of static patterns) [1] and:

• represent the evolving structure on the world wide web in multiple rendered formats depending on consumer [data]
• provide a common set of framework operations against the static pattern [behaviors]

I can modestly say this initial concept was nothing more than morphing together a few existing ideas that have developed over the last two decades. The endpoints idea was intended to take the web service endpoint concept and apply it toward static patterns at the service layer with all types of interesting convolutions of the usual infrastructure surrounding web services [2].

This first phase of thinking, which encompasses ‘releasing’ or publishing a static pattern, is still going to be part of the process (with some as yet undisclosed modifications to the way it is represented) — this notion of allowing a pattern’s representation to become static is enforced by the criteria that it:

• has an authorative and established identifier that gives it an identity
• has a physical location that hosts it [3]
• has a structure and set of behaviors that define it, otherwise it is neither active nor static

This last criterion, which defines whether the pattern [virtual] representation (not necessarily the underlying pattern itself) is static also defines whether it can be active introduces the notion of active pattern. In consciousness (the cognitive domain), a static pattern becomes active when cognition is actively operating with that pattern to produce transformations in the pattern itself or other patterns. If the sole purpose of the endpoints project was simply to reflect the products of consciousness as virtual representations, then endpoints would be a proper name; however, the purpose of static pattern engineering is to operate on and transform these patterns — in the transition states they are active patterns. With the tremendous potential of a global network, if the endpoint were designed to release the pattern in a way that allowed it to be activated by bidirectional information flow according to its orientation and exposure then there would be many opportunities for the pattern to become an active pattern (not just for consumer but for creator and aggregators). Thus, we are most interested in the flux through the endpoint — and the sole purpose of the endpoint is to serve as a FluxPoint.

I have most likely become somewhat vague in the -how- this last part will be achieved. This is for several reasons – first and foremost is because I wanted to announce the initial ideas (endpoints) but not necessarily reveal the whole progression since then. Nonetheless, I can assure you that this project will be an interesting experiment that I hope will generate very positive results, not just for the field itself but also for the people that use it. [Insert typical grandiose vision statements here]

[1] analogous to a domain name in concept but not at all in syntax

[2] for instance, web services are usually unique type definitions that usually delegate to a well-known data source while an endpoint represents a unique manifestation using a standard type definition with variable data sources (often other endpoints)

[3] in the first implementation, this will be a hosting location I will provide; however, the infrastructure will be designed from the bottom up that this location can vary for each endpoint

First, I’ve made a decision about publication of the first volume I am working on for static pattern engineering.  I have decided to publish it using Amazon’s Digital Media Platform.  Therefore, the first title will only be available electronically and will be an abridged version of the final form.  I will be actively seeking feedback from readers in this first publishing round, then I will seek alternate avenues for the expanded publishing round for the physical (and electronic) unabridged form.

Second, for the past few years I’ve been actively looking for a candidate programming language and platform for the virtual work on static pattern engineering.  I am happy to announce that I’ve finally found it – thanks to some extraordinary work at Microsoft research. They have produced the F# language which is about to reach maturity (the v1.0 release). This language will allow me to finally model some of the complexity surrounding the virtual work in an elegant form using multiple programming paradigms. My previous attempts to model some of the data structures and operations using a purely object oriented paradigm were not sufficient using anything else available. I had explored functional programming using Lisp and Scheme; however, the lack of constructs from imperative programming were also not sufficient and I couldn’t find an active project that maintained a connection to powerful frameworks (such as the .NET framework). The F# language effectively merges these paradigms as well as offering effective abstract representation, symbolic, and lexical processing which we will important for dealing with some of the core concepts in a programming language form.

Finally, the virtual side of static pattern engineering is going to take further form in a new project codenamed ‘FluxPoints’. A fluxpoint will be a virtual and active representation of a static pattern (or an aggregation of static patterns) on the Internet (in other words, the medium the static pattern will be expressed in is a ‘physical’ construct that allow it to participate on the Internet). I’d like to note that this is simply a research application of static pattern engineering, so won’t receive full attention here (only in the cases where the application helps inform the core theory); nonetheless, I am expecting some exciting developments from this project and am looking forward to it.