expand_less
Following Peirce, the general is a continuum and no set of individuals can fully characterize the general, and yet they (generals) are real. We are abstracting an initual Card Model from the Ruby on Rails implementation of the Wiki content platform Decko (ref decko.org). That is to be considered an example of a general that conceptually includes all web content, but more specifically can be a master set of content patterns. Decko and Mediawiki (ref) probably the most popular wiki platform, and also Ward Cunnunham's exploratory work that set the standard for the rest to come. Our goal is a natural language specification of general concepts, wiki, microblog, mediastream, database and so on, that will lead to formal languages and methods.
There are already a million and one proposed universal solutions, and we will not propose another. What we propose is a common language for talking and thinkingcollectivecollectively about and with data. We want a truly high level language, natural language. American English for this author, but our language must allow for accurate translations to any language. We note here that languages, natural and formal, are also related continua as are the iconic characters now exhaustively cataloged in international coding standards (ref current internet character standards). By the continuum hypothesis, this international character set is not complete, but it is potentially complete as we can add new characters to evolve it if we need to add sets for the space aliiens we might meet in fact or fiction. In the worlds of ideas, anything we can imagine becomes potential fact of letters typed on a page on an antique typewriter, or these bits flowing into my computer and saved by server code partly written my me.
We have already dipped into syntax in naming a coding standard. As typed mathematical objects we have vectors, which could be indexable. TheDeckosimplest Cardpossible modelvector Iis describethe herebit, binary or boolean string, chunked into bytes and words in machine level representations and hardware realizations. These bytes or words are typically indexed within working memories. Any particular hardware will have to specify in detail these raw syntaxes, and system and language tools realize the actual syntaxes including binary coded raw programs or machine codes. For our purposes, we only need to know that a text string is a vector of whole number character codes from some set of icons. A bit string can be closejust a text with a two character alphabet, although in practice raw binary texts are most efficiently realized according to commons conventions.
Our concern here is only thecurrenttypes implementationof objects that occur at the level of realization, binary strings for machine codes and bitstrings, a representation of text strings as bitstrings. Plus the idea of raw pointers, indexes to locations in the store. This is the scope of what the implementation syntax will saveneed to do. Although we mention machine codes, the description of any set of operations and deeper syntax are required in concrete realizations is intentionally not at this cardlevel. whenWe will also stop short of syntax descriptions and define code attributes to be in a general syntax that would be translated easily to any modern development language for integration with other systems.
The Decko Card model Igetdescribe finishedhere typingwill eachbe partclose orto editthe current implementation that holds the versions of it.this text. This is a familiar pattern now to many, but we must note that it did not exist until Ward invented and named it Wiki. In this sense, our languages, natural and formal are always evolving the intelligence of our worlds. The communities of open source (OS) coders, designers and architects are collaborating to do this everyday. You literally cannot keep up with it. This work is addressed to the now and future generations who will step up to change the world and put us back on track to the open future. We call for the minds of the world to learn to come together in every larger and densely interconnected networks of care and support.
We won't need a financial system anything like the one we have that is literally burning down the house and gardens of the world. If we damage Gaia, we will suffer as we have already inflicted suffering upon many others in the path to economic efficiency and technological supremacy. We will need a new financial system for the transition to fund commons development of all the projects already in motion. Consider this paying back to the first generations of rebels who created the GPL (ref FSF, RMS). The founders paid it forward to us and our duty is to take it to the next levels. This is not an economic paper, and we only note the architectures of support that is needed to evolve our collective vision into realizable future. The tools of the transition financial system are part of the systems that eventually would be designed and built by these methods.
Before continuing on the technical descriptions, we state that all of our design work is human oriented and in support of health and wealth creating (social) process architectures. We can't do the big things or the other things (ref JFK speech about space program) without first caring for ourselves and others. Our world is now very complex and deeply connected and internetworked. We anticipate the emergence of new collective consciousnesses. First in smallish networks and building out. In comparison what we describe here is simple, complicated and simple. We design our systems this way because the world is complex enough as it is. Push to hard for unity and confusion and disharmony result. The world is just so many people building local towers to God's realm (ref Tower of Babel) and it has to stop. Pull together to something good enough, the perfect is the enemy of the good and this is why.
The general class is Wiki, so let us consider what is common to Wikis. The general model is named data objects in collections. The objects can be edited by users often under very open identity policies, but these are not essential. So we have:
Name -> Content Instance within a Namespace
The current State of a Namespace is a Set of (Name, Content) pairs
Name a way to reference the particular content to view and edit
Any particular wiki platform will need to further define the syntax and semantics of the constituents and we will proceed as one would with a mathematical proof or demonstration only defining and terms and concepts that we use in sufficient detail to identify the particulars, but also making the continuum of possible mappings apparent such that it can be applied flexibly to the categories described.
We start with the Card objects themselves, the (Name, Type (another Card), Content)pairs,triples. andThe withName is both the Namehuman parthandle first.and for referencing in URIs, content and code. The use of names are references is what dictates the semantics of names. Because we will use names to identify the pairs, multiple instances of the same name might get different accomodations on different platforms. Decko Cards also have another attribute, a Cardtype which is also a Card. Already we see that a Card object is not complete in itself, but always has a Cardtype to select semantics. Therefore we have Cards:
Every Card has:
A Name which reduces to a keyname equivalence class (name -> key function: Keyname)
A Card may be assigned a permanent identifier such as a numeric CardID
A Cardtype which is another Card
Names can be simple or compound, a list of simple names
Optionally, an additional permanent name to be used in code can be assigned to some cards. (make this a footnote? ->) This might be considered an artifact of the customizable code actually being separate from the other rules (Settings that can be appended to Set cards), but maybe it has more to do with multiple namespaces (data and code) and we may need to generalize the codename concept.
An Optional Content Object, Content persistence and semantics can be categorized by Sets
This is as far as we can get without putting Cards into contexts. Current implementations are single deck namespaces where the keys are unique and CardID are sequentially assigned record identifiers in the underlying database. We do not specify these details at this level as this is not a syntactic specification. We will describe multi-deck semantics in terms of these object oriented ontologies we are developing.
A Deck can be constructed by standard operations that add, update and delete cards from the set that is the current state of a deck. Note that the data representation can be mutable or immutable with the latter having a number of advantages for caching, tracking and managing change sets as is done with code objects and more with tools like git and github. With a similar data model to git's distributed change management model the implementation can support flexible workflow tools for Card content in complex networks of collaborating producers.
Deck semantics: Names (via key reduction) are unique in a given deck.
Cardtype might be used to distinguish cards with same name, but is not is reference implementation
Set Patterns are defined with name patterns.
Special cards are the indicators of patterns
These cards have zero to two (reference implemenation, could be extended) slots that specify the pattern parameters.
Zero slot keys are simple Cards that represent the sets with no slots, for example all cards *all or all cards with first character *, *star.
One slot uses the card in the slot as the Set selector, for example, ACardtype+*type is a single slot set representing all cards of a given type from the slot, ACardtype in this case.
More slots is more parameters, so a right selector with a type, or in a WikiRate extension, two types for the left and right parts of a given card.
Card Parts: When a cardname has more than one part, is not simple, it has parts, the tag or right part that can be matched with *right Sets, and a trunk of left part. The right part is always simple, therefore Cards are constructed from a trunk card by adding to the right, adding a tag.
Settings and Rules: Another special type of simple cards are Settings, that when added (as right part or tag) to a Set card trunk become a rule for the trunk card (Set) such that the Settomg is defined for that Set.
Precedence: When multiple rules match a card for a given Setting, the most specific rule is used as defined by an ordering of the Set keys.
Code Rules: view formatting and implementation details are to be organized or generated according to Sets and Set Precedence definitions. In the Ruby reference implementation this maps naturally onto a loading process for singleton classes for each Card object. Similar mechanisms are available in most object oriented languages. Defining modular code in a universal implementation language can be accomplished with modern tools as is and extended. This is the next step from this high level description. A tool should be able to extract universal code from the RoR implementation.
Multiple Decks are a critical design topic for Card Systems to grow into diverse networks of content. We want to define how Namespaces and having many Decks might function in an evolving network of heterogeneous content. Eventually, you should be able to load a specification of MediaWiki and have naming support for external MediaWiki instances. With proper linkages both to ReSTful APIs on each platform and Federation (ref Ward's FedWiki project) are expected to lead to processes of workflow production chains for a broad class of content.
We can't go much further without introducing syntax. Decko is design with Web access and APIs in mind, and in the implementation the Names are seemlessly transitioned from URI space to content links and code references to cards. Since we don't have a proposed
There are already a million and one proposed universal solutions, and we will not propose another. What we propose is a common language for talking and thinking
We have already dipped into syntax in naming a coding standard. As typed mathematical objects we have vectors, which could be indexable. The
Our concern here is only the
The Decko Card model I
We won't need a financial system anything like the one we have that is literally burning down the house and gardens of the world. If we damage Gaia, we will suffer as we have already inflicted suffering upon many others in the path to economic efficiency and technological supremacy. We will need a new financial system for the transition to fund commons development of all the projects already in motion. Consider this paying back to the first generations of rebels who created the GPL (ref FSF, RMS). The founders paid it forward to us and our duty is to take it to the next levels. This is not an economic paper, and we only note the architectures of support that is needed to evolve our collective vision into realizable future. The tools of the transition financial system are part of the systems that eventually would be designed and built by these methods.
Before continuing on the technical descriptions, we state that all of our design work is human oriented and in support of health and wealth creating (social) process architectures. We can't do the big things or the other things (ref JFK speech about space program) without first caring for ourselves and others. Our world is now very complex and deeply connected and internetworked. We anticipate the emergence of new collective consciousnesses. First in smallish networks and building out. In comparison what we describe here is simple, complicated and simple. We design our systems this way because the world is complex enough as it is. Push to hard for unity and confusion and disharmony result. The world is just so many people building local towers to God's realm (ref Tower of Babel) and it has to stop. Pull together to something good enough, the perfect is the enemy of the good and this is why.
The general class is Wiki, so let us consider what is common to Wikis. The general model is named data objects in collections. The objects can be edited by users often under very open identity policies, but these are not essential. So we have:
Name -> Content Instance within a Namespace
The current State of a Namespace is a Set of (Name, Content) pairs
Name a way to reference the particular content to view and edit
Any particular wiki platform will need to further define the syntax and semantics of the constituents and we will proceed as one would with a mathematical proof or demonstration only defining and terms and concepts that we use in sufficient detail to identify the particulars, but also making the continuum of possible mappings apparent such that it can be applied flexibly to the categories described.
We start with the Card objects themselves, the (Name, Type (another Card), Content)
Every Card has:
A Name which reduces to a keyname equivalence class (name -> key function: Keyname)
A Card may be assigned a permanent identifier such as a numeric CardID
A Cardtype which is another Card
Names can be simple or compound, a list of simple names
Optionally, an additional permanent name to be used in code can be assigned to some cards. (make this a footnote? ->) This might be considered an artifact of the customizable code actually being separate from the other rules (Settings that can be appended to Set cards), but maybe it has more to do with multiple namespaces (data and code) and we may need to generalize the codename concept.
An Optional Content Object, Content persistence and semantics can be categorized by Sets
This is as far as we can get without putting Cards into contexts. Current implementations are single deck namespaces where the keys are unique and CardID are sequentially assigned record identifiers in the underlying database. We do not specify these details at this level as this is not a syntactic specification. We will describe multi-deck semantics in terms of these object oriented ontologies we are developing.
A Deck can be constructed by standard operations that add, update and delete cards from the set that is the current state of a deck. Note that the data representation can be mutable or immutable with the latter having a number of advantages for caching, tracking and managing change sets as is done with code objects and more with tools like git and github. With a similar data model to git's distributed change management model the implementation can support flexible workflow tools for Card content in complex networks of collaborating producers.
Deck semantics: Names (via key reduction) are unique in a given deck.
Cardtype might be used to distinguish cards with same name, but is not is reference implementation
Set Patterns are defined with name patterns.
Special cards are the indicators of patterns
These cards have zero to two (reference implemenation, could be extended) slots that specify the pattern parameters.
Zero slot keys are simple Cards that represent the sets with no slots, for example all cards *all or all cards with first character *, *star.
One slot uses the card in the slot as the Set selector, for example, ACardtype+*type is a single slot set representing all cards of a given type from the slot, ACardtype in this case.
More slots is more parameters, so a right selector with a type, or in a WikiRate extension, two types for the left and right parts of a given card.
Card Parts: When a cardname has more than one part, is not simple, it has parts, the tag or right part that can be matched with *right Sets, and a trunk of left part. The right part is always simple, therefore Cards are constructed from a trunk card by adding to the right, adding a tag.
Settings and Rules: Another special type of simple cards are Settings, that when added (as right part or tag) to a Set card trunk become a rule for the trunk card (Set) such that the Settomg is defined for that Set.
Precedence: When multiple rules match a card for a given Setting, the most specific rule is used as defined by an ordering of the Set keys.
Code Rules: view formatting and implementation details are to be organized or generated according to Sets and Set Precedence definitions. In the Ruby reference implementation this maps naturally onto a loading process for singleton classes for each Card object. Similar mechanisms are available in most object oriented languages. Defining modular code in a universal implementation language can be accomplished with modern tools as is and extended. This is the next step from this high level description. A tool should be able to extract universal code from the RoR implementation.
Multiple Decks are a critical design topic for Card Systems to grow into diverse networks of content. We want to define how Namespaces and having many Decks might function in an evolving network of heterogeneous content. Eventually, you should be able to load a specification of MediaWiki and have naming support for external MediaWiki instances. With proper linkages both to ReSTful APIs on each platform and Federation (ref Ward's FedWiki project) are expected to lead to processes of workflow production chains for a broad class of content.