expand_less
After having already gotten some ways into this, I realize some of the initial premises were a bit off the mark. Some such are 1) cardspace logic doesn't actually depend on names, they are indepentent language grounded symbol spaces that are used to bind cardspace objects and structures, but are secondary to it. A separate (sub)system linked through type logic and methods. 2) Neither names, nor content are atomic. 3) Initial insights on combining namespaces being like mounting a filesystem in a filenamespace. Now we will consider that Namespace1+Namespace2 => Namespace3 such that it is defined how the bindings of 1 and 2 mix, particularly with collisions.
We must go through types, and more generally for card systems through set based subspaces, to be able to fully identify the type and specific methods bound within cardspaces. Thus our first definition:
CardIdentity is a typed token that relates two Cards in a equivalence relation.
These tokens may be scoped to a particular group of namespaces, therefore to join namespaces as above, we would translate Identity tokens as needed. It would be well defined, and in some scopes this can be integer tokens from lower layers of the representation (i.e. active record id fields in primary card db tables), but we can know these relative scopes with precision and hide in the implementations, expose for debugging.
SimpleCards are the only cards that can be bound in a namespace, thus implicitely naming any joined names and keys.
SimpleCards must be bound to a CardIdentity to be used, and conventionally it always has one or more names.
JointCard is Card joined SimpleCard
Card is JointCard or SimpleCard
Notably asymmetric. Maybe you want this branching on the right vs. the left as here. Both may be a semantics someone wants, but we do not consider it here.
Codenames are language independent names that are bound in codespaces.
Codenames are never translated and are not within any natural language. When codenamed cards are not given language specific names, any forms of translation may be invoked because these cards and their CardIdentities are permanently bound in and to the code.
Cardnames are the natural language bindings for a card.
These are the human presentable representations of cards. As described above, only SimpleCards can be bound to names and any JointCards.
SimpleCards don't have to actually exist to have names, and thus virtual JointCards can be constructed and we don't necessarily require that all the SimpleCard parts of a given JointCard actually exist. On the other hand, implementations may need to create some of these virtual parts in order to permanently bind to correct CardIdentity and CardKeys. Which reminds me we need:
CardIcon is an alternative graphical icon bound to a card as an iconic variation.
This is speculative, and might give some additional power. Icons are potentially (if well designed) international signs with meanings translatable into languages. These probably should have codenames, and could have a special category of key that is related to the codename. Otherwise a textual name might need to be based on either an index within category (icons?) or a CardID token.
Cardkey is an identity token that represents a unique name in all its variations.
E.g. for a Date, this might be and integer day number with a speced history bound DayZero. Or numerics might take on syntax from their NameSpace. This is speculative and we are exploring the future concept for Card Decks of Namespaces.
Current thinking is that Names bind within Namspaces and we need to define the semantics of namespace stacking to resolve:
FreeNames are symbolic atoms used in expressions, CardNames in all their complexities, CodeNames and CardIdentities for reference and storage/networked representation and reference.
Decks are maps of structured content
We are describing (mostly) a deck of Cards Type of Namespace with complete definitions and specifications of the Types above.
Namespace1 + Namespace2 => Namespace3
When the added namespaces are compatible and disjoint, addition is pretty simple and natural, just add as two sets of Name(or just ID)xTypedValue pairs. Name collisions are the complexity when not disjoint. When this occurs a semantics, a rule for choice can be used to resolve them.
Even without all the necessary formalisms and proofs, what we have here is a simple (relatively) system of named data with structures that can be expressed by decomposing and recomposing equivalent Namespace instances according to these structures in the service of defining semantic relations within the structures.
Functions defined with respect to these types and structures give very expressing high level languages that build on these relations. Content has only been mentioned in passing, and the essential semantic bit is that some content types are capable of representing references to names and cards. The important part here is not the reference syntax nor that of embedding within the content, but that they can be enumerated, indexed and processed recursively in views.
Content is what all this complexity is about. We define two related categories that represent special namespaces in how code is defined, Formatters and Views.
It's something like each Formatter has a name (codename, cards are not needed or implemented at present) and any number of named (again, these are in effect codenames) views can be defined in one or more formatters. There are some views defined for all formatters, and potentially overriden via the logic of adding namespaces. These view names are actually accessible in syntax as the name of views in references (nests) and the view parameter from URL query parameters. These someday will need translatable cards to give them proper inclusion in namespaces.
Image Notes
Just added raw sketches for now. First one has the Card categories and the parts. Trying to represent the basic structures and partitioning of Cards as a category. There are different methods to identify cards represented here, and these will all relate to their identity within Decks, or sets of cards that are expanded in the second image. Note the partition of all cards strictly into Simple, with no parts and a name, and Joints that are composed of two (existing) cards, and by definition get a name by joining the part names with a syntax charcter (conventionally + in Decko).
The other partition is an real/virtual. Simple Cards must also be real, but because of rules, a card doesn't need to exist to have (virtual) content. The typical case is the join of some real card with a tag, and matching a *structure rule the supplies the cards virtual content. Real cards will have a CardIdentity. Only real cards can be partitioned from a Deck and used in operations to compose virtual content.
In [[+i2]], we have some images for Decks. Operations, references and Sets that reference subsets or partitions of a Deck state, and we show a couple of examples of how a given Cards are functional parameters are mapped to partitions. It shows how the parts of a Set Card are like arguments to the pattern; there are 0, 1 and 2 parameter patterns in Decko implementations, but there could be more as needed. Here the parameters are parts of the card, and in the search language CQL (Card Query Language), there are likewise references to Cards to, for example, match a particular type by referencing the Cardtype card, or cards whose right part matches the tag card.
Next line is showing how paths in code are related to the cards. Only cards with Codenames can be referenced in code, and within the 'sets' paths the base path is just a reverse of the Set Cards: .../key/p1code/p2code/name.rb This is Ruby, but any OO language can support something like this to overload modular codes onto the relavent object variants.
Below, is the idea that it would be nice to have the code in Cardname space, and they would be joined onto the sets just like Settings are to make Rules. Only instead of a Setting, we would have a view and possibly a Formatter. In the actual code, there are many views and sometimes helper methods (on Cards) defined in each file and the path locates these files in the Ruby module/class namespaces.
{{+images|type:pointer;view:titled|view;open;size:full;type:image}}{{+images|type:pointer;view:titled|view;bar;size:large;type:image}}
We must go through types, and more generally for card systems through set based subspaces, to be able to fully identify the type and specific methods bound within cardspaces. Thus our first definition:
CardIdentity is a typed token that relates two Cards in a equivalence relation.
These tokens may be scoped to a particular group of namespaces, therefore to join namespaces as above, we would translate Identity tokens as needed. It would be well defined, and in some scopes this can be integer tokens from lower layers of the representation (i.e. active record id fields in primary card db tables), but we can know these relative scopes with precision and hide in the implementations, expose for debugging.
SimpleCards are the only cards that can be bound in a namespace, thus implicitely naming any joined names and keys.
SimpleCards must be bound to a CardIdentity to be used, and conventionally it always has one or more names.
JointCard is Card joined SimpleCard
Card is JointCard or SimpleCard
Notably asymmetric. Maybe you want this branching on the right vs. the left as here. Both may be a semantics someone wants, but we do not consider it here.
Codenames are language independent names that are bound in codespaces.
Codenames are never translated and are not within any natural language. When codenamed cards are not given language specific names, any forms of translation may be invoked because these cards and their CardIdentities are permanently bound in and to the code.
Cardnames are the natural language bindings for a card.
These are the human presentable representations of cards. As described above, only SimpleCards can be bound to names and any JointCards.
SimpleCards don't have to actually exist to have names, and thus virtual JointCards can be constructed and we don't necessarily require that all the SimpleCard parts of a given JointCard actually exist. On the other hand, implementations may need to create some of these virtual parts in order to permanently bind to correct CardIdentity and CardKeys. Which reminds me we need:
CardIcon is an alternative graphical icon bound to a card as an iconic variation.
This is speculative, and might give some additional power. Icons are potentially (if well designed) international signs with meanings translatable into languages. These probably should have codenames, and could have a special category of key that is related to the codename. Otherwise a textual name might need to be based on either an index within category (icons?) or a CardID token.
Cardkey is an identity token that represents a unique name in all its variations.
E.g. for a Date, this might be and integer day number with a speced history bound DayZero. Or numerics might take on syntax from their NameSpace. This is speculative and we are exploring the future concept for Card Decks of Namespaces.
Current thinking is that Names bind within Namspaces and we need to define the semantics of namespace stacking to resolve:
FreeNames are symbolic atoms used in expressions, CardNames in all their complexities, CodeNames and CardIdentities for reference and storage/networked representation and reference.
Decks are maps of structured content
We are describing (mostly) a deck of Cards Type of Namespace with complete definitions and specifications of the Types above.
Namespace1 + Namespace2 => Namespace3
When the added namespaces are compatible and disjoint, addition is pretty simple and natural, just add as two sets of Name(or just ID)xTypedValue pairs. Name collisions are the complexity when not disjoint. When this occurs a semantics, a rule for choice can be used to resolve them.
Even without all the necessary formalisms and proofs, what we have here is a simple (relatively) system of named data with structures that can be expressed by decomposing and recomposing equivalent Namespace instances according to these structures in the service of defining semantic relations within the structures.
Functions defined with respect to these types and structures give very expressing high level languages that build on these relations. Content has only been mentioned in passing, and the essential semantic bit is that some content types are capable of representing references to names and cards. The important part here is not the reference syntax nor that of embedding within the content, but that they can be enumerated, indexed and processed recursively in views.
Content is what all this complexity is about. We define two related categories that represent special namespaces in how code is defined, Formatters and Views.
It's something like each Formatter has a name (codename, cards are not needed or implemented at present) and any number of named (again, these are in effect codenames) views can be defined in one or more formatters. There are some views defined for all formatters, and potentially overriden via the logic of adding namespaces. These view names are actually accessible in syntax as the name of views in references (nests) and the view parameter from URL query parameters. These someday will need translatable cards to give them proper inclusion in namespaces.
Image Notes
Just added raw sketches for now. First one has the Card categories and the parts. Trying to represent the basic structures and partitioning of Cards as a category. There are different methods to identify cards represented here, and these will all relate to their identity within Decks, or sets of cards that are expanded in the second image. Note the partition of all cards strictly into Simple, with no parts and a name, and Joints that are composed of two (existing) cards, and by definition get a name by joining the part names with a syntax charcter (conventionally + in Decko).
The other partition is an real/virtual. Simple Cards must also be real, but because of rules, a card doesn't need to exist to have (virtual) content. The typical case is the join of some real card with a tag, and matching a *structure rule the supplies the cards virtual content. Real cards will have a CardIdentity. Only real cards can be partitioned from a Deck and used in operations to compose virtual content.
In [[+i2]], we have some images for Decks. Operations, references and Sets that reference subsets or partitions of a Deck state, and we show a couple of examples of how a given Cards are functional parameters are mapped to partitions. It shows how the parts of a Set Card are like arguments to the pattern; there are 0, 1 and 2 parameter patterns in Decko implementations, but there could be more as needed. Here the parameters are parts of the card, and in the search language CQL (Card Query Language), there are likewise references to Cards to, for example, match a particular type by referencing the Cardtype card, or cards whose right part matches the tag card.
Next line is showing how paths in code are related to the cards. Only cards with Codenames can be referenced in code, and within the 'sets' paths the base path is just a reverse of the Set Cards: .../key/p1code/p2code/name.rb This is Ruby, but any OO language can support something like this to overload modular codes onto the relavent object variants.
Below, is the idea that it would be nice to have the code in Cardname space, and they would be joined onto the sets just like Settings are to make Rules. Only instead of a Setting, we would have a view and possibly a Formatter. In the actual code, there are many views and sometimes helper methods (on Cards) defined in each file and the path locates these files in the Ruby module/class namespaces.